- From: Christian Nentwich <c.nentwich@cs.ucl.ac.uk>
- Date: Mon, 4 Feb 2002 05:43:03 -0500 (EST)
- To: Joe English <jenglish@flightlab.com>
- Cc: xml-dev@lists.xml.org, www-xml-linking-comments@w3.org, Daniel Veillard <veillard@redhat.com>
> '//*[@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... Thanks, Christian Nentwich
Received on Monday, 4 February 2002 07:29:18 UTC