[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: XPointer crisis

• To: xml-dev@l...
• Subject: Re: XPointer crisis
• From: Joe English <jenglish@f...>
• Date: Mon, 04 Feb 2002 11:49:07 -0800
• In-reply-to: <1012843017.1169.12.camel@w...>
• References: <1012843017.1169.12.camel@w...> <1012819375.1075.12.camel@w...> <20020201144101.E29819@r...> <1012587257.27106.38.camel@l...> <p05100303b8807575e600@[192.168.155.106]> <1012587257.27106.38.camel@l...> <20020201123611.D29819@r...> <5.1.0.14.0.20020201134448.029015c8@157.189.161.214> <200202012136.g11LaZj26264@d...> <200202041652.g14GqKj07104@d...>

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@f...

• References:
  • Re: XPointer crisis
    • From: Christian Nentwich <c.nentwich@c...>
  • Re: XPointer crisis
    • From: Christian Nentwich <c.nentwich@c...>
  • Re: XPointer crisis
    • From: Daniel Veillard <veillard@r...>
  • Re: XPointer crisis
    • From: "Simon St.Laurent" <simonstl@s...>
  • XPointer crisis
    • From: "David G. Durand" <david@d...>
  • Re: XPointer crisis
    • From: Daniel Veillard <veillard@r...>
  • Re: XPointer crisis
    • From: Jonathan Robie <jonathan.robie@s...>
  • Re: XPointer crisis
    • From: Joe English <jenglish@f...>
  • Re: XPointer crisis
    • From: Joe English <jenglish@f...>

• Prev by Date: Categories of Web Service messages: data-oriented vs action-oriented
• Next by Date: Re: Categories of Web Service messages: data-orientedvs action-oriented
• Previous by thread: Re: XPointer crisis
• Next by thread: Press Releases
• Index(es):
  • Date
  • Thread