W3C home > Mailing lists > Public > public-xml-id@w3.org > April 2005

Re: FW: W3C XML ID ambiguity

From: Elliotte Harold <elharo@metalab.unc.edu>
Date: Fri, 22 Apr 2005 18:18:36 -0400
Message-ID: <4269783C.3060600@metalab.unc.edu>
To: Chris Lilley <chris@w3.org>
CC: "Bassetti, Ann" <ann.bassetti@boeing.com>, public-xml-id@w3.org, "Bugbee, Larry" <larry.bugbee@boeing.com>, "Henry S. Thompson" <ht@inf.ed.ac.uk>, Liam Quin <liam@w3.org>, Bert Bos <bert@w3.org>, "Reid, Travis S" <travis.s.reid@boeing.com>, "Gerstmann, Jerry P" <jerry.p.gerstmann@boeing.com>, "Meadows, Joe" <joe.meadows@nobs.ca.boeing.com>

Chris Lilley wrote:

> It seemed therefore that you were arguing that xml:* should mean
> inherited. Now you seem to be saying that all future xml* should ot be
> xml:* whether inherited or not.

I'm saying that the assumption is already out there that xml:* 
attributes are inherited. Therefore putting any non-inheritable 
attribute into xml:* is wrong and will cause problems.

I am also arguing that the xml:* mechanism is fundamentally broken and 
should never be used again, inherited or otherwise.

In other words there are two good reasons not to use xml:* for 
non-inherited attributes, and one good reason not to use xml:* for 
inherited attributes.

I see no good reasons to use xml: for any newly defined attributes or 

> I think you overstate the case. xml:base added some badly needed
> capabilities to the language. Which arguably should have been there from
> the beginning (much more useful than things that did make it in, such as
> DTD syntax, external parsed entities, notations, etc). xml:id similarly
> should have been there from the beginning, as soon as fetching the
> external DTD subset was made optional rather than mandatory.

I have no objection to the general functionality of xml:base. However 
making it an xml:* attribute instead of xmlbase has caused problems it 
would not otherwise have.

> Without a time machine, the easiest way to fix that now is to add them,
> now.

No. The easiest way to fix the problem of identity determination in the 
absence of DTDs is to define this with xmlid. xml:id is not the easiest 
or the best solution here. That we failed to recognize the easiest, 
cleanest, least kludgey solution for past problems is no excuse for 
knowingly choosing the wrong solution for the current problem.

> Moving away from namespaces - but only for the xml namespace - just
> sounds like a short term kink to me, one that will be viewed in
> retrospect as "ah yes, namespaces were unfashionable 2004-2006 so we
> have this wart where its not actually in a namespace ..."

The wart is xml:. It does not behave like other namespaces. It cannot be 
remapped to a different prefix. It requires special handling from 
libraries. It's time to apply some Compound-W to this wart.

Remember: far more attributes are not in namespaces than are. There is 
nothing the least bit warty about an attribute that's in no namespace. 
It is simple. It's clean. It works. This fetish for namespaces must end. 
Where namespaces add no value and indeed cause active problems, they 
should not be used.

Elliotte Rusty Harold  elharo@metalab.unc.edu
XML in a Nutshell 3rd Edition Just Published!
Received on Friday, 22 April 2005 22:18:43 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:53:49 UTC