Slashdot Mirror

Tools like thus are just another route to the semantic web that Tim Berners-Lee and the W3C are driving towards. Half an implementation perhaps, but take a look at the W3C specifications for Annotea and have a think...

http://www.w3.org/2001/Annotea/

Oh, and then pick up a copy of Dream Machines and think about what a full implementation of Xanadu would have been like...

Tools like this and Smart Tags are part of the past and the future of the web. The one way design driven web will be seen as just a stop gap on the road to a fully interactive two way communications system.

Perhaps MS pulled Smart Tags in favour of a W3C compliant Annotea implementation ;-)

S.

One system for that is the Speech Synthesis Markup Language being developed by the W3C. This will allow you to use XML style markup for emphasis, voice type, etc.

Here's an example (not sure if it is 100% syntactically correct):

<speak> <voice gender="female"> <voice category="elder"> Free Software is about <emphasis level="strong"> freedom </emphasis>, not price! </voice> </voice> </speak>

I don't know if it is used by AT&Ts system in the article.

Also, it would be a good thing to include books that people can read to understand us. Hackers dictionary, the Hacker Ethic, etc.

I would also recommend Weaving the Web by Tim Berners-Lee. It is not very well written, but it gives insight into some very brilliant ideas that have yet to be implemented, and makes you see how little of the web's real potential that has been realized.

I'm using a text-only browser (because this computer doesn't support anything but an 80x25 text display) and I'm afraid I can't read your email address.

Might I also point out that your web site violates several of the Web Accessibility Initiatives's guidelines.

I understand that on my personal web site and have included an image with a detailed ALT tag that even blind users will be able to use. It doesn't help cognitive impaired people unfortunately, but there is a form they can use.

P.S., see also the UID on my GPG key.

Second, while your approach may have cut it back in 1996 when Matt Wright gave it away, it doesn't address many of the security issues that have crept up, some of which are listed in an article Lincoln Stein wrote for the W3C.

Third, if unedited, versions of FormMail as exampled by your site, can become a major spam producer. In large part FormMail uses that HTTP variable for your e-mail address we talked about earlier. This allows Spammers to easily abuse your form to distribute their messages. Moreover, unless you capture and forward their IP, you give then the anonymity.

Finally, why write so much stinking (and unsecure code) ? By using CGI.pm, you can address some other security issues. You can avoid having to put your 'hidden' arguments in your HTML. With the addition of a few other libraries, you can address a variety of other security issues while significantly reducing your effort.

IN other words, work SMART and HARD !

I've seen many entities out there like "Trust-e" which review privacy practices and policies for e-commerce sites, but I really don't think any of them out there is big on auditing network and systems security practices. Even if they do, those companies are hired at-will by the sites conducting e-business to give themselves more credibility.

Face it people, I really am starting to believe that statements like "This is a secure site because it uses SSL and strong encryption and ... [insert heart-warming buzzwords here]" are nowadays flat out lies for too many e-commerce sites. Those sites are not secure. They store passwords and social security numbers in clear text in databases that reside on the same machine as the web server, which prolly runs way more services than it really needs to because "hey, we can get a pretty fast server up and running in no time and for really cheap, by getting ourselves a cheap pentium and sticking red hat linux on it". "OK, well it looks like the red-hat installation went fine ... let's connect to localhost on port 80 ... ooo see the pretty Apache default page? Great! Well Sir, looks like we're good to go and ready to stick a shopping cart on this puppy!"

The danger doesn't lie in "packet sniffing" anymore. There has been such a hype over the whole "eavesdropping" over a transaction as it is being made, that it looks like this is the only thing irresponsible systems administrators ever worry about: "Well, we need a secure server that does that SSL thing. To do that we need to shell out a couple hundred bucks and apply for a Verisign ID so people don't get nagged by their browser when they hit our site. Verisign will tell people we are who we say we are."

Big deal. Am I supposed to feel good now? In light of what I've been reading for the past few years ... I'll say NO.

The danger truly lies in HOW and WHERE sensitive consumer data is being stored. *This* is what matters and what should get thoroughly audited.

If a site possesses an SSL certificate from Verisign, it should be illegal for the owners of this site to request a consumer's highly-sensitive,permanent and personal data like a Social Security Number (credit card numbers don't apply here as those can easily be changed), unless their SSL certificate also comes with some kind of SEAL of approval from some government-sponsored network and systems security auditing.

I do realize I'm going a little far with government involvment, but we're talking about protecting data issued to every citizen by the government in the first place. You're talking about people's lives: their ability to buy a house, open a 401k account, even get work! I have been victim of identity theft in the past after my mail was stolen, fortunately it didn't go too far as I think they didn't get their hands on my SSN, but it truly poisoned my life for a while. I came back from christmas vacation only to find someone had gone on a shopping spree courtesy of me with several of my credit cards and realized they had applied for and shopped with a couple others in my name! Yes some credit-yielding entities don't even ask for your SSN to open an account.

If government involvment isn't the solution, then users should somehow get educated and notified with a message along the lines of "Although this site encrypts all its transactions, its network and systems security practices have not been audited by [INSERT GLOBAL ENTITY NAME HERE]-approved party and may be exposed to security holes".

Better yet, the W3C could work on amending the HTML specification to define a new type of form input field: INPUT type="secure-ssn" name="userssn", which browsers would ONLY display if a site's SSL Certificate contains information stating that this site's security practices were audited and approved. If that is the case, the browser could 'automagically' display the field as [][][]-[][]-[][][][] with a 'secure key' near it which could be clicked to explain what this all means, and possibly remove that field from any scripting-bound client-side Document Object Model so that data could not be evilly manipulated within sites open to cross-site scripting vulnerabilities. The browser could further insure that the value of this field could only be submitted to a form whose "action" attribute points to a secure protocol. The browser should have built-in validation of this field to compensate for its lack of access thru scripting. Browsers should not allow this field's value to be pre-populated on page load unlike other input fields so users would have to re-enter their SSN every time they see the field.

Now with that standard special-looking "social security" form input field, people could be educated to only enter their social security number in such an input field. If they do enter their SSN on any other type of form input field, then they should know they're further exposing themselves to identity theft.

These are just initial ideas, but further brainstorming should help finding a solution that would work to protect people's privacy on-line.

What do you guys think?

Although it's not remotely in the same league of complexity as PDF (or any of the Postscripts), eXtensible Form Definition Language (XFDL) is an XML-based schema set that will allow the precise placement of document components (as well as arbitrary base64 encoded bin files) within an XML document. The proper tools can be used to display and handle the forms, as well as print them (although without the extensive printer involvement of Postscript...it's going to be pure PCL).

The latest W3C note is here. Check it out, then go look at the tools out there. This sort of thing could well become the new "generic" format for portable documents.

XML Schema tries hard to provide a strong notion of type

Although that's a valid point (and I haven't written DTDs in over 2 years, in favour of schema) it's not the issue I was talking about. Look at the Infoset draft or the recent Processing Model workshop. You can barely tell the difference between reading infoset and the syntax spec, because XML just doesn't put enough distance between semantics of the content and its representation in a document.

XML doesn't "represent" anything. It never has done, it never will, and all attempts to pretend that it does will end in failure. XML (and XML Schema) is a low-level transport and manipulation platform, but it doesn't have the ability to do any form of abstract representation. Its structure and implied semantic meaning are so closely fastened together that it's impossible to squeeze a gap between them. "Representation" is the act of stretching this gap, between structure and implied meaning, so as to infer a higher level meaning.

The problem is fundamental to XML, and won't be fixed by tools at this level. There's no abstraction in XML; any attempt to indicate semantics also drags along its structural baggage, because that's the only way XML-Schema allows you to work. No number of "sideways" solutions to this; namespacing to allow parallel co-existence, BizTalk to allow sharing of schemas, will fix this - XML just doesn't offer any "upwards" in a semantic direction.

To separate two authors with the same name you need more information to make a key.

Again, I agree with you in general, but that's not quite the issue I was thinking of. Clearly we need more structure to distinguish them, although in fact we don;t need any more information (RDF can do this entirely within the document structure, with no need to start "allocating author indexes" or similar).

The symptom of this problem, in the XML world, though is an over-dependence on flat text comparisons. It's like search engines that only compare at the text level and can't tell "goat sex" from animal husbandry or a Slashdot Troll. Because XML has nothing useful beyond the text node, that's what gets used. If it's easy to do it all just by comparing author names, then that's what lazy coders do. Disambiguation between resources like this needs a simple and lightweight mechanism, because if it isn't, no-one will use it. RDF manages it with rdf:resource and rdf:about attributes. In XML then you'd have to build some identifying system at the application level (so a generic parser can't understand it) and impose its use on your data. No wonder people stick with just using the names and ignoring truly identifying relationships with resources.

ID & IDREF are just broken. If you want to do it that way, build a proper architecture for doing it and join the RDF WG.

...the 300 page monster that is XML Schema.

Tell me about it 8-(

Compare the XML Schema spec, the SMIL spec, and the even more gargantuan MPEG-7 spec. Now take a look at DAML and see that complexity can be described, without needing a spec like a phone book.

XML Schema tries hard to provide a strong notion of type

Although that's a valid point (and I haven't written DTDs in over 2 years, in favour of schema) it's not the issue I was talking about. Look at the Infoset draft or the recent Processing Model workshop. You can barely tell the difference between reading infoset and the syntax spec, because XML just doesn't put enough distance between semantics of the content and its representation in a document.

XML doesn't "represent" anything. It never has done, it never will, and all attempts to pretend that it does will end in failure. XML (and XML Schema) is a low-level transport and manipulation platform, but it doesn't have the ability to do any form of abstract representation. Its structure and implied semantic meaning are so closely fastened together that it's impossible to squeeze a gap between them. "Representation" is the act of stretching this gap, between structure and implied meaning, so as to infer a higher level meaning.

The problem is fundamental to XML, and won't be fixed by tools at this level. There's no abstraction in XML; any attempt to indicate semantics also drags along its structural baggage, because that's the only way XML-Schema allows you to work. No number of "sideways" solutions to this; namespacing to allow parallel co-existence, BizTalk to allow sharing of schemas, will fix this - XML just doesn't offer any "upwards" in a semantic direction.

To separate two authors with the same name you need more information to make a key.

Again, I agree with you in general, but that's not quite the issue I was thinking of. Clearly we need more structure to distinguish them, although in fact we don;t need any more information (RDF can do this entirely within the document structure, with no need to start "allocating author indexes" or similar).

The symptom of this problem, in the XML world, though is an over-dependence on flat text comparisons. It's like search engines that only compare at the text level and can't tell "goat sex" from animal husbandry or a Slashdot Troll. Because XML has nothing useful beyond the text node, that's what gets used. If it's easy to do it all just by comparing author names, then that's what lazy coders do. Disambiguation between resources like this needs a simple and lightweight mechanism, because if it isn't, no-one will use it. RDF manages it with rdf:resource and rdf:about attributes. In XML then you'd have to build some identifying system at the application level (so a generic parser can't understand it) and impose its use on your data. No wonder people stick with just using the names and ignoring truly identifying relationships with resources.

ID & IDREF are just broken. If you want to do it that way, build a proper architecture for doing it and join the RDF WG.

...the 300 page monster that is XML Schema.

Tell me about it 8-(

Compare the XML Schema spec, the SMIL spec, and the even more gargantuan MPEG-7 spec. Now take a look at DAML and see that complexity can be described, without needing a spec like a phone book.

Sure. The point is that XML is only a file format. The data it represents is vaguely semi-structured. Of course, one needs a query/update language on top of that (and some other good stuff) on top of that to make a database---there have been many proposed. In the relational world there is no standard file format. One could represent relational data in XML pretty trivially, though.

- XML Schema is also very poor on data modelling, because it has no separation between a structural schema (which element goes inside the other) and a semantic schema (what each element means, when placed inside another)

DTDs are problematic because they just provide a grammar for the structure of an XML document. XML Schema tries hard to provide a strong notion of type. For example, I could define a type called Person and let several tags, say manager and employee both have that type.

- How do you represent shared resource in XML; such as an author of several modules ?

Sort-of. It's hard to represent graphs in XML. Unlike semi-structured data, which is a graph, XML is, at its core, a tree description language. One can define graphs with IDs and IDREFS, but it's a pain.

- How do you distinguish such an author for another author with the same name ?

This seems like a key problem---you'd have the same issue in the relational world. To separate two authors with the same name you need more information to make a key.

The biggest problem I see for XML as a data description language is that it's way too complicated for what it does. To represent semi-structured data, which is what we seem to want here, all you need is a simple graph description language. XML, however, does this with three types of edges (subelement, attribute, and IDREF) and has other features (eg., mixed content) that are hard to figure out what to do with from a database perspective. (From a document description point of view things like mixed content make a lot of sense.)

The other problem, one induced partly from the inherent complexity of XML, is that the standards that are growing up are horrendeously complicated. For example, the 300 page monster that is XML Schema.

It's worse than that. It can't be valid because it doesn't even have a DTD.

But this document is not even well-formed XML. In other words, it is not XML at all. It's plain text with some tags.

For details on what it means for an XML document to be well-formed or valid, see the spec at the W3C

Someone could leverage XML RDBMS like DBXML which is based on the "XML:DB" standard.

If enough people are interested, I could try downloading dmoz myself and "massage" it into some dbxml store on my own system and build a web-based interface to query it, I've just been really busy with other stuff lately though.

If you happen to read this and are interested, shoot me an email at valmont@wildstar.net and we can take it from there.

Oh baby, my favourite rant. Nested tables. Lack of ALT tags. Mmmm mmm. Go dob them in to the WAI!

RFC959 was issued in 1985 but refers to older documents such as Telnet (RFC854)...
Note this extract from the latter:
"It is envisioned that the protocol may also be used for terminal-terminal communication ("linking") and process-process communication (distributed computation)."
Not quite sure lawyers would be happy with this point, though.
--

NuSphere is completely within their right to produce proprietary extensions for GPL'd software provided it is not in breach of the GPL. However, it is not great 'netiquette'.

Looking at mysql.org, there is a notice pointing to MySQL AB at the bottom of the front page. However, it is written thus:

If you are looking for the MySQL AB company, click here. If you came here looking for NuSphere, click here.

The W3C suggests that "click here" as Web pages will increasingly be accessed by devices without mice or things that can be clicked (touch displays, text readers etc.) By making "click here" a hyperlink to MySQL AB rather than the text "MySQL AB" itself, it could be argued that they're trying to confuse the visitor. Of course this is only conjecture and it may just be that the Webmaster was not aware of Web standards.

However, this is not the worst part. The worst part is getting banks onto it. They are used to largish transactions, and a much must model is charging quite a bit for every transaction. It's going to be hard to tell them this won't work. I have been sending my bank e-mail about it.

What we need are truly open, global standards. Around here, several banks are working on their own models. It seems that it will result in they telling web developers to put buttons on their pages, something like "if you have an account in Bank A, click here, if you have an account in Bank B, click here" (my own bank has allready implemented such a solution). This insular behaviour won't do us any good.

Unfortunately, I just saw the W3C has closed their micropayments group. This is very unfortunate, I think. They had a draft that didn't look too bad in Final Call, and several implementations. I don't know why they closed it, I thought it was about to advance to Candidate Recommendation. I guess it might be that the guy who lead that working group was tied up in a lot of other things.

If the Free Software community can develop something, and make it a public domain standard, I think that would be good. I would prefer W3C to do it, but it seems they failed.

XHTML 1.1 incorporates Ruby.

Yes, but not Ruby the scripting language that is sort of like python, but Ruby short runs of text along side the main text.

In answer to the orginal question, Ruby doesn't have a lot to offer over other scripting languages, and not long real has any big wins over python. (it closest relative) Python no has full fleged garbage collection and the Functional programing extenstion has closures, etc.

I think you will find that this is not Ruby the scripting language, but instead the concept of ruby text, used in the formatting of eastern languages and in complex run-on formatting.

From the reference document in the XHTML recommendation: "Ruby" are short runs of text alongside the base text, typically used in East Asian documents to indicate pronunciation or to provide a short annotation. This specification defines markup for ruby, in the form of an XHTML module

See the following URL http://www.w3.org/TR/2001/REC-ruby-20010531/ for more details.

S.

XHTML 1.1 incorporates Ruby.

It has certain benefits that PCs do not have (locked hardware, unified memory, etc.)

Locked hardware is a benefit?! For whom? Certainly not for the customer. Maybe for those that love control, such as the MPAA and the RIAA, but not us, the customers.

It seems you have already been assimilated into the Borg.

Makes me long for the day when PS2 meant PS/2 and not PlayStation 2. (Maybe we shouldn't abbreviate PlayStation 2 like that, look at CSS, is it Cascading Style Sheets, Content Scrambling System or C Styled Script?).

Anyway, the PS/2 was somewhat of a closed system (IBM had been overly tight-fisted about controlling use of the MCA bus technology - it hurt them and they have learned from their mistake), but it was far more open than the PS2 game machine.

P.S. I am wondering, what benefits can game consoles have over PCs anyway? PCs have TV out for those that want connections to TVs and the frame rates are nowadays faster than human perception and the scan rate of any monitor or TV out there. Please let me know what I am missing. Granted they are cheaper than PCs sometimes, but not by all that much it seems. And anything with a hard drive is getting close to being a PC anyway... Heck, GCC can be made to run on it I heard.

Sorry - I have to disagree.

SOAP is a messaging protocol based on XML, and can be parsed in any language for which there are decent XML parsing tools: hence, the already extensive SOAP tools for Perl. It's already on the standards track with the W3C. There's already a good deal of support for SOAP in Perl.

Committing to CORBA means using a CORBA-compliant development environment, which doesn't even take into account the differences between CORBA implementations. Committing to RMI basically means you're using Java, period. Support for SOAP in a programming language, on the other hand, is only a couple of steps past a decent XML library.

Point them here.

Let me first say that I am not a m$ oppenant because of their 'shady business' practices...I oppose m$ because of the bunk products they 'ship'. I understand that patches are necessary, for security updates or whatever. But gimme a break!

Anyway...Smart Tags. This is just another fork in the 'standards' road for them. I am a web developer and I deal with thier (m$) 'standards' all the time. Like for instance, I believe it was the release of IE4 that included the undocumented feature that would complete your tags for you. In otherwords you open a table tag, but forget to close it. IE would render the page 'correctly'. Whereas netscape and mozilla (which were coded to render html according to the w3c standards at that time) would puke because the tag wasn't closed. I know I can code to w3c/html X.X standards, but that's not what companies/clients want.

Where does it stop? I get tired of having to make sites work for a couple of different browsers. I just have one question to ask m$. When did they become their own consortium and invent their own standards that everyone will have to bow to?!?.

I'm done. pce-fu,
th3 di$cipl3

And it's not such a bad thing - the face="" paramater to the font tag is invalid HTML. I guess the web in general should be red in the face?

If you really have the time, run throught the CSS1 tests at W3C CSS Level 1 Test Suite. You can then see that IE does NOT in fact support the standards as well as Microsoft would claim they do. Mozilla performs nearly flawlessly on this test with under 5 rendering errors. IE 5.5, on the other hand, had more than 40 rendering errors.

The standards have been implemented for a reason, it's to make the web a place where people can access information regardless of platform and regardless of disabilities. One company can't just come along and then change the standards so that browsers coded to the standards don't work properly (Netscape were once like that, but now with their funding of the Mozilla project they're now doing the right thing).
It's very simple to write a page to the standards that works in both Mozilla and recent versions of IE with NO browser sniffing code, you may have to ditch support for IE4 or add some code to cater for IE4 too (not difficult), but you should design pages to the standard spec, it'll then work in Mozilla, in recent versions of Windows IE (most standards are supported now) and Mac IE (which is more standards compliant than the Windows version), also not forgetting Opera.

Not having standards hurts interoperability. What if you asked me for directions and I used my own proprietary version of English, in which North and South and left and right are switched? Wouldn't that cause confusion?

From the p3p FAQ:

30. Is P3P an American technology?
While many of the member companies that worked on P3P are based in the U.S., the specification itself is meant to be international. The P3P vocabulary, for instance, was created with the input of many people both in and outside of the U.S. Nearly half of the members of the working group that worked on the vocabulary were invited experts and staff from international data commissioners' offices, many of which were from Europe. In addition, there has been considerable input from Japan.

Some privacy advocates have argued that P3P distracts from efforts to develop privacy legislation in the U.S.

This initiative is a stake in the heart of the initiative for a Privacy Bill of Rights in the United States. Despite the light coverage of this topic in the FAQ, the widespread adoption and implementation will make it impossible to constrain the access of foreign web sites to the personal information of U.S. citizens. The technological barrier to a citizen's privacy will be in place long before we succeed in guaraunteeing the privassy rights of all Americans.

Don't let Microsoft doom our future. Fight for privacy. Don't use IE6.

I would certainly pay Salon by micropayments if I had the chance. I think this is very, very important.

I wonder why the Common Markup for micropayment per-fee-links hasn't advanced to Candidate Recommendation...? It has two implementations allready, it should have been a Recommendation by now...

1. First of all, the fact that Smart Tags can be toggled by the user does nothing to help me since most users will never toggle them or even look for the setting. If they're on by default, they'll stay on. If they're off by default, they'll stay off. I doubt that Microsoft really will leave a new feature disabled from the start, it doesn't seem like them.
2. Secondly, I'm not sure of how many users would download COM objects, but then again, I've never actually tried to find out what an average user thinks of the "Run Content By XXX" security box. (Also keep in mind that it costs a fair chunk of change to sign an ActiveX control.) I also have to wonder how many users will either personally disable downloading ActiveX controls or have their "smarter computer friend" do it for them thanks to the various security flaws in the ActiveX model.
3. Embedded XML in my webpage. Lovely, that'll really make the W3C HTML Validator happy. So I suppose now my choice is "write correct HTML" or "write for Smart Tags" - of course, customizing Smart Tags isn't something I'm likely to do manually anyway. (Especially since I'm not planning on "upgrading" to XP any time soon.) Plus I have to wonder how third party browsers will handle embedded XML...
4. Smart Tags are controlled by Microsoft - and whichever OEM sold the computer. What, you really think that your average user is going to go out of their way to download new Smart Tags? Unless it's transparent, they'll be stuck with the defaults.
5. DLLs? DLLs?!? You have to be kidding me. Smart Tags are actually full blooded computer code!?! Oh, I just can't wait for the first "Smart Tag" virus to come out. Unless the download isn't transparent (see above). (And don't forget, MS has a pretty poor record of implementing security checks properly - I really have to hope that all the OEMs are smart enough to preconfigure boxes so that new users are running as normal Users. Can you imagine a host of newbies running as Administrator? *Shudder* - Wait - how do we explain to them that they can't install WinAMP anymore? *Shudder*)
6. What the hell do the default set do exactly, then? From what I saw, Smart Tags creates a little menu of options for each instance of some word that they find (or is it more complicated than that? Really don't have the time or inclanation to find out). Still sounds like MS will be controlling web content... even if I can develop my own Smart Tags I highly doubt that I can effectively get users to download them...

--

So, putting the computer in the living room is not a solution. At least, not a very good solution.

I think one solution is to teach the kids to behave responsibly. But that's only part of the solution, I do think filters must be a part of this too. But good filters, filters that simply do not exist today. I think TimBL's Semantic Web-dream will go a long way in providing the solution.

Actually, I would really like to see good filters become a reality. I maintain a site on how to use a compass, and I've got a page where I put up mnemonics people send me. One very common goes something like "True Virgins Make Dull Companions At Weddings" (there are many variations). Since I'm aiming this tutorial mainly at kids, I haven't put that one up. For one thing, the sucky filters of today would likely block me, and besides you never know how people could take offence. If I could label it, and trust that filters would handle it properly, I could make a separate page with those, problem solved.

Well, I don't have a solution to the poster's problem. I don't think there exists a solution right now. Perhaps putting it in the living room is an acceptable temporary solution, and then showing her the a bunch sites that you find acceptable for her to explore in privacy while you're at work or something.

Active involvement in the W3C and IETF; particularly, he was an author of HTTP/1.1 (RFC2616) and several HTTP-related RFCs (e.g. 2145), in addition to which he's an all-around pretty swell guy.

Jim Getty sounds like a great guy and great designer. I know a few people really respect his work. However, I wonder how much attention he pays to usability. That is one of the key problems with Open Source in general. Designs look great but are not always functional, especially to novice users. Some day, usability will be seen as being more important than raw functionality, right?

By the way, you might be interested in this set of slides. They are from Linux Expo '99 where Jim is doing a demo of Itsy. (Was that an early version of the iPaq?)

"Why can't there be a meta tag to TURN IT ON instead of turn it off. Isn't that what meta tags are for? To give browsers extra information? Retrofitting the entire internet IS NOT going to make friends. This should be more of an opt-in than an opt-out. They're assuming that by default, everyone wants to participate when the exact opposite is probably true."

"HTML lets authors specify meta data -- information about a document rather than document content -- in a variety of ways."

"Why can't there be a meta tag to TURN IT ON instead of turn it off. Isn't that what meta tags are for? To give browsers extra information? Retrofitting the entire internet IS NOT going to make friends. This should be more of an opt-in than an opt-out. They're assuming that by default, everyone wants to participate when the exact opposite is probably true."

"HTML lets authors specify meta data -- information about a document rather than document content -- in a variety of ways."

W3C has many member companies, and it manages to publish tons of standards...

W3C has many member companies, and it manages to publish tons of standards...

The main problem with Smart Tags is its commercial aspect, not the technology behind it. Keep in mind that the XLink specification which extends XML allows precisely this kind of thing; it even goes further by allowing one to annotate read only web pages by embedding your own content via an xlink. One can imagine this being done for personal use (i.e. sticky notes on the web) as well as commenting on other people's web site by linking to it from one's own. Once the legal issues are all sorted out, I imagine this will be a positive thing. See also The Annotea Project.

HTML easy?! Even Slashdot gets it wrong! The home page http://www.slashdot.org/ has some very SERIOUS HTML coding errors:

Like this little gem (as of this post) right in the main navigation area (!):

<A href=/code.shtml>code</A>

An unquoted attribute (not XHTML compliant), actually an unquoted non-numeric attribute (very bad, always), and non-XHTML compliant uppercase tags. Surely a GEEK site should get this right by now...

So if you can get these kids to code correct HTML, have them make extra money this summer working to fix Slashdot ;)

Try validating sites with validator.w3.org and see how FEW pass! See how many big name commercial sites have SERIOUS errors.

As for Java, it is very slow, NOT truly cross platform, and just restrictive and anal to try to program in.

As for teaching MAC addresses versus IP addresses, even most IT people don't even know the difference (I kid you not!).

These are ELEMENTARY SCHOOL KIDS, not TCP/IP gurus (yet ;).

I am a web developer so, if you are interested, here are some good web development resources. First, try the World Wide Web consortium for a lot of good web and XML reference/background stuff. For using java on the web, check out Sun's Java Server Pages , with lots of tutorials. Sun is now using the FREE Apache Tomcat JSP Server . There is also a free jsp server in Allaire's JRUN Server 3.1. Interestingly, the JRUN Eval. Edition server has no expiration date, on purpose. Have fun!

I'm pretty certain the parser is supposed to break when tags are malformed.... why should *ML parsers try and figure out what you meant when you left out all your /P and /LI tags?

I don't think that's correct. I believe HTML parsers are supposed to be quite lenient about screwy code. This is bad in a sense, since it leads to slop, but it does allow you to do things like browse the web using Netscape 3. ("What the heck's a style tag? I'll just ignore it.")

Also, you might check the HTML 4.01 specification at http://www.w3.org/TR/html4/intro/sgmltut.html#h-3. 2.1 ("Some HTML element types allow authors to omit end tags (e.g., the P and LI element types).").

I'm not the best person to be able to tell you, but if you're building a form that is likely to contain a lot of non-ASCII data, I think the most effective solution is to use enctype=multipart/form-data which does take a charset parameter. See this portion of the HTML spec for more detail.

Likewise, in Unicode, English, German, and Finnish all share the same codepoints and glyphs, so you can't grep for one language or another without using META headers or something similar.

For instance, if you were searching in English for "gift", this string in Unicode would be the same as the German characters for "poison" (Gift), so your search would get hits from other latin-based languages in addition to English.

It's difficult even to sort Unicode correctly without choosing some language or another, due to this overlap of characters. "Alphabetical order" is a bit different for the different European languages, even though they use the same characters.

Translation: Language collision can be avoided by exact phrase matching ("perpetual copyright" wouldn't return many matches for non-English documents) and specifying the natural language of a document either in the document or in the headers.

Actually, you can link to it! Here's the link. It's the URL of the article (http://slashdot.org/articles/01/05/05/1459212.sht ml in this case) followed by the comment number (57, as it turns out) used as a inner page reference (or whatever the W3C calls it).

When Slashdot creates it's HTML, it creates little anchors at the start of every single comment. You can actually do that in unarchived stories too... Strangly enough, when Slash archives posts, it DOESN'T change the little (#Comment ID) links to use this. I should submit a bug report about that...

I think you'll find that both British government guidelines and an EU directive means that this site is technically in breach of the law here as well.

The relevent legislation in the UK is the Part III of the 1995 Disability Discrimination Act. If I did what the UK Government regularly does online I could be fined, or worse. If the pointy-haired civil servants could just spend a day or so at the Web Accessibility Initiative then things might get better. Instead they produce specifications with wonderful advice, such as putting HTML attributes in alphabetical order.

I've contacted several Government departments about Web accessibility and have received mostly non-replies ("thanks for you comments, which have been filed") with some bogus replies ("but we'd have to make the whole site in HTML2!"). Quite sad, really.

"Anyone who slaps a 'this page is best viewed with Browser X' label on a Web page appears to be yearning for the bad old days, before the Web, when you had very little chance of reading a document written on another computer, another word processor, or another network."
-Tim Berners-Lee in Technology Review, July 1996

Using a validator during daily development of your website, whether static or dynamically generated pages, in the long run just makes it a lot easier because you catch a lot of careless errors. Imagine how hard it would be to write syntactically correct C code without using a compiler!

• Validate Your HTML here
• Validate your CSS here
• Use Validators and Load Generators to Test Your Web Applications

• http://slashdot.org
• http://www.debian.org/

Using a validator during daily development of your website, whether static or dynamically generated pages, in the long run just makes it a lot easier because you catch a lot of careless errors. Imagine how hard it would be to write syntactically correct C code without using a compiler!

• Validate Your HTML here
• Validate your CSS here
• Use Validators and Load Generators to Test Your Web Applications

• http://slashdot.org
• http://www.debian.org/

Using a validator during daily development of your website, whether static or dynamically generated pages, in the long run just makes it a lot easier because you catch a lot of careless errors. Imagine how hard it would be to write syntactically correct C code without using a compiler!

• Validate Your HTML here
• Validate your CSS here
• Use Validators and Load Generators to Test Your Web Applications

• http://slashdot.org
• http://www.debian.org/

Using a validator during daily development of your website, whether static or dynamically generated pages, in the long run just makes it a lot easier because you catch a lot of careless errors. Imagine how hard it would be to write syntactically correct C code without using a compiler!

• Validate Your HTML here
• Validate your CSS here
• Use Validators and Load Generators to Test Your Web Applications

• http://slashdot.org
• http://www.debian.org/

actually, everything works fine if you use VALID HTML and CSS!! Why can't anyone check their HTML at the W3C's Validator? The only site that I could think of that was valid was kde.org! Way to go!