Re: FW: W3C XML ID ambiguity

On Friday, April 22, 2005, 11:20:02 PM, Elliotte wrote:

EH> 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.

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

All of which applies exactly equally to xml:base and xml:space, right?

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


All of which applies exactly equally to xml:base and xml:space, right?

So no, I don't miss the point, but your point seems to have shifted.


-- 
 Chris Lilley                    mailto:chris@w3.org
 Chair, W3C SVG Working Group
 W3C Graphics Activity Lead