Lists Home |
Date Index |
> '//*[@id=foo]' (or some other syntax with equivalent semantics)
> can accomplish everything that 'id(foo)' can. More, actually:
> it also works with documents that don't have (or have but don't
> reference) a DTD, W3C XML Schema, or other infoset-augmenting
> resource. As an added bonus, the recipient doesn't have to
> retrieve (and process!) the DTD/XSD/what-have-you.
As a negative, the ID values won't be in a hashtable after parsing, and
//*[@id='foo'] will take a very long time to execute on large documents
(especially given the descendent axis), unless you implement a
streaming-xpath processor that can catch it on the fly from SAX.
> Re: the 'xml:id' and 'xml:idattr' proposals: these sound reasonable,
> but it seems to me like an awful lot of work to specify, implement,
> and deploy just for the sake of barename fragment identifiers.
Apart from that they are definitely *not* just for the sake of XPointer
or barename fragment identifiers. The absence of an xml:id attribute is
my daily nuisance when I can't get a DTD for some of my data.
Btw xmi:idattr has the big disadvantage of getting lost when you pick a
fragment out of a document and the root element is lost...