On 2/9/07, Geoff Pack <[EMAIL PROTECTED]> wrote:
Lachlan Hunt wrote: > No, the semantics come from its definition, not its tag name. If a spec > defines an element with the tag name <j79hfd98y28> to be for marking up > a person's name, then that's what it is. The tag name is just an opaque > string that doesn't affect the semantics in any way. It just helps > authors to have meaningful and memorable tag names. > > However, if you create your own generic XML document, using tag names > like <name> and <address>, then those elements don't inherently have any > semantics at all. Although you may define your own semantics, unless > those semantics become known by others, the elements are meaningless to > everyone else, and your semantics are totally useless. > > Semantics only become useful when there are tools that make use of them > in a useful way. The semantics in HTML documents are useful because they > are widely understood and implemented. > 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? 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. (I'm playing devil's advocate here, but only to show how absurd this is.)
Welcome to web standards? -- -- Christian Montoya christianmontoya.net .. designtocss.com ******************************************************************* List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *******************************************************************
