Re: We need an XPath API

[Robin Berjon <robin@knowscape.com>]

At 16:29 03/03/2001 -0500, Charles Reitzel wrote:
>XPath isn't XML, so none of the XML tools work on it.  That said, it appears
>that parsing and interpreting XPath expressions is becoming more and more
>important in its own right.

That is very true, and it's not the first time that it comes up so I guess
that there's some form of real need for it.

>Proposal: let's give XPath the SAX treatment.

Yes. SAXPath. However, XPath and XML are different enough that you probably
can't just make an interface a la SAX. SAC is probably a good place to
start, it's more complex than SAX, but then there's no way to avoid that
given the number of different objects that you're dealing with.

>What should such an API do?  How should it behave?
>
>1) Small, lightweight

Fast, memory-efficient, flexible, easy to use, easy to learn, easy to
implement, be reliable, make good coffee. The usual stuff (just kidding, I
understand the emphasis).

>2) Should emit/accept XML representation 
>   of XPath expression

That's not the take I'd have. SAXPath would just define an API a la
SAC/SAX, no more. Emitting XML representation is the job of a
SAXPathHandler. Defining SelectML is a different task altogether (which you
also put as 4), if well done it should imho also work for CSS selectors,
and perhaps others too.

>3) Provide info about expression

I think the way SAC separates selectors and conditions is the way to go. It
probably makes sense in pretty much any selecting context.

>Possibles (not so small):
>1) Provide DOM traversal?

I'm not sure that's really something for this API. There already is a
Traversal interface on the DOM, it may be considered insufficient (or
certainly inefficient) for some tasks but that's something where DOM
extensions would be useful.

>2) Provide SAX-based pattern matching?

Just for a subset of XPath or for the whole thing ? Note that CSS3
selectors introduced the :subject pseudo class, which I think can be used
as an elegant way to avoid the .. axis. I haven't had time to fully immerse
myself in the proposed syntax but if I understood correctly "FOO:subject
BAR" would select FOO elements having a BAR descendant, which is
"bar/ancestor::foo". So perhaps there is a way to make XPath work in a SAX
filter. I'm not sure how much it makes the problem evolve though, I'll have
to think of it. 

If it is a workable option, then imho it doesn't fit into this API either,
instead a SAXPath sink would provide the "down-pull-only-with-subject"
XPath that a SAX handler could use. Perhaps I'm restricting your idea too
much, but I like to break down functionality into smaller independent packages.

On top of SAXPath, one could build (as you suggest too) some sort of
SelectOM, which would have specific interfaces to interact with a DOM (or a
DOMAdapter supporting only what it needs to support).

-- robin b.
Doctor:   "Ah, ah that's a catch question. With a brain your size you don't
think, right?" -- Dr. Who