[
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
|
