- From: Elliotte Harold <elharo@metalab.unc.edu>
- Date: Fri, 22 Apr 2005 17:20:02 -0400
- 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! http://www.cafeconleche.org/books/xian3/ http://www.amazon.com/exec/obidos/ISBN=0596007647/cafeaulaitA/ref=nosim
Received on Friday, 22 April 2005 21:20:08 UTC