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 17:20:02 -0400
Message-ID: <42696A82.5020209@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:

> EH> What the Boeing folks have pointed out (that xmlid is much easier to
> EH> handle in namespace-aware processors than xml:id because it doesn't 
> EH> require any special casing) is yet another reason to prefer xmlid to xml:id.
> Neither should xml:id. Its clearly in the xml namespace and is clearly
> thus reserved.

You miss the point. xml:id and xmlid are both equally reserved, but this 
is not what the Boeing folks noticed. The completely different issue 
they brought up (for the first item, to my knowledge) is that processing 
software has to tie itself in knots to handle xml:id because it must 
recognize xml:id, but only when it's in the correct namespace, and it 
must not recognize foo:id even if it is in the correct namespace. if I'm 
writing code to find xml:id attributes I have to write code that looks 
for attributes with the local name id, the prefix xml, and the namespace 
URI http://www.w3.org/XML/1998/namespace. XOM is one of the few, perhaps 
the only, API that is that careful about these things, and it is a royal 
pain in the tuckus to implement, let me assure you. The significance of 
the namespace prefix, when almost all other namespace prefixes are not 
significant, is a major  wart in the code and the model.

By contrast xmlid is very simple. It is an attribute with the name xmlid 
in no namespace. This is exactly like most other attributes. All XML 
APIs I know of handle unnamespaced attributes like this one very nicely 
without any kludges. It is much easier to write code for. It is much 
more likely that xmlid will be implemented correctly than that xml:id 
will be. xml:id requires lots of special case namespace handling. xml:id 
does not.

Practical example: consider the XPath expression //*/@xml:id. Will that 
find anything if the XPath namespace context set is empty? Do you know 
without looking at the spec? I just looked at the spec, and I still 
don't know. What about /*/@foo:id where the XPath namespace context does 
bind the prefix foo to the URI http://www.w3.org/XML/1998/namespace? 
It's not allowed to bind foo to http://www.w3.org/XML/1998/namespace in 
an XML document, but an XPath namespace context is not an XML document? 
Legal? Not legal? What kind of error?

Compare this to the situation with //*/@xmlid. There is *no* ambiguity 
here. We all know exactly what that means without having to hunt through 
specs and read between the lines. Just because xml:lang, xml:space, and 
xml:base are broken in practice in many libraries, processors, and 
specifications is no justification for introducing further breakage with 
xml:id. xmlid works. Its satisfies all the use cases. It is simple. It 
is straight-forward. It has no significant problems. The only issue is 
that the W3C seems to be committed to colons in the face of all evidence 
to the contrary. It is time to reject the cult of the colon and admit 
that there is a better way.

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

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