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:
> > > > 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
> But the point of this argument was that xml:id was not necessary..

Ah.  I've been arguing that barenames in XPointer aren't necessary;
xml:id would be useful and might be necessary for some *other* reason,
I just don't think it should be required as a prerequisite for
XPointer support.

> how can the parser know which attributes are ID-bearing without a DTD,
> XSD, or xml:id attribute?

It shouldn't have to know which attributes are ID-bearing.
If it does happen to know -- by way of xml:id, a DTD, XSD, or
whatever -- then it *may* use that knowledge to optimize
'//*[@attname=attval]' -- but such knowledge isn't necessary.

On the other hand, it *must* know which attributes are ID-bearing
to process 'id(foo)' at all.  So I believe that XPointer
*should not* include any constructs which are equivalent
to the XPath 'id()' function.

> Or was your intention to suggest that the application should build the
> hashtable? In that case, I would be disappointed if the parser didn't do
> it for me, because it's a very common operation and I'm lazy.

No, I think that index-building should be handled at the
parser/toolkit layer, not the application layer.  But it
should also be possible to implement XPointer on top of a
toolkit that *doesn't* have this capability.  That's all.

--Joe English



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

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