[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: We need an XPath API
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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|