Re: XPointer crisis
Christian Nentwich wrote: > [Joe English wrote]: > > '//*[@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, Why wouldn't they be? An XML parser could still build an index from known ID-bearing attributes, and use the index when possible. There's no reason why an application *can't* take advantage of infoset-augmenting resources; I just don't think XPointer should make it necessary. > > 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. Same here. That's why ID/IDREFs have joined <!DOCTYPE ...> and <!ENTITY ...> declarations in the list of XML features that I rarely use anymore. I've found <xsl:key name="id" match="*" use="@id"/> and "key('id',...)" (or the equivalent) to be much more reliable in practice than "id(...)". --Joe English jenglish@f...
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format