Lachlan Hunt wrote:
Semantics only become useful when there are tools that make use of them in a useful way.
On 2/8/07, Geoff Pack <[EMAIL PROTECTED]> wrote:
So <name>Joe Blogs</name> is meaningless with out a spec to tell me that 'name' means a name, while <j79hfd98y28>[EMAIL PROTECTED]&*</j79hfd98y28> is meaningful if a spec says so?
Read Lachlan's words carefully, Geoff. Using XML, you're free to define your own language with whatever tags you'd like. That doesn't mean there's any tool (e.g., web browser) that's going to be able to parse whatever tag in whatever language and apply semantic value to it. Just because I feel <headerone> or <mysupercoolheadinglevela1abeachfrontavenue> is a better way to specify a heading than <h1>, is it reasonable to expect a browser maker to cater to my linguistic whim? And by extension, to anyone's linguistic whim? Browsers don't handle any random tags, browsers work with a previously defined subset. That's just how they work. Atom feeds don't accept any old tags, either. OpenOffice.org documents, though they be XML, handle only a specific set of tags. I'm sensing a pattern.
What if I write spec that says simply: "The meanings of all my tags names are the same as the meanings defined in the Standard Oxford English Dictionary"? What if I claim my spec to be the English language? I could then further claim my document is more widely understood (and implemented?) than HTML, simply because more people understand plain English than HTML.
You might be able to get away with handling the presentation issues with CSS, but that's not going to help the semantics of your document. Human readability, unfortunately, does not translate to machine readability. If machines were completely capable of parsing natural language, we wouldn't be programming in Ruby, we'd be programming in Japanese.
(I'm playing devil's advocate here, but only to show how absurd this is.)
Yep. Love, Dan Dorman ******************************************************************* List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *******************************************************************
