Geoff Pack 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?
Essentially, yes. Although, there's no rule to say it has to be a formal specification (technically it doesn't even have to be written down), but it helps because it's difficult to read minds and impossible to achieve interoperability without one.
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?
Then it wouldn't be a particularly useful spec, as there would be no testable conformance criteria and many elements would have multiple meanings, which creates ambiguity. Although, it may allow a human who is reading the XML markup to make limited sense of it, it would be *impossible* to get any 2 interoperable implementations that actually do anything particularly useful with it, beyond applying a stylesheet.
I could then further claim my document is more widely understood (and implemented?) than HTML, simply because more people understand plain English than HTML.
No. -- Lachlan Hunt http://lachy.id.au/ ******************************************************************* List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *******************************************************************
