OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: [xml-dev] XPointer crisis

[ Lists Home | Date Index | Thread Index ]


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@flightlab.com




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS