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