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

re: We need an XPath API

• From: Robin Berjon <robin@k...>
• To: David Megginson <david@m...>
• Date: Sun, 04 Mar 2001 03:30:33 +0100

At 20:33 03/03/2001 -0500, David Megginson wrote:
>Charles Reitzel writes:
>
> > Proposal: let's give XPath the SAX treatment.
>
>I'd actually recommend giving XPath the DOM treatment.  Well, not
>really DOM, but maybe a cleaner, in-memory tree.  XPaths (even hairy
>ones) are extremely small, and the same path object is likely to be
>reused many times, so I see no need to force the pain of an
>event-based interface on users (unless someone thinks we're going to
>be seeing gigabyte-long XPath expressions).

I think both can be useful. What I've got in mind is the building of custom
objects based on the content of an XPath expression. I've been down the
"XPath OM" path before by hacking an interface onto Matt Sergeant's
XML::XPath module. It can be very useful, but not as useful in some
contexts as a builder callback style interface. Converting an object model
into another is often harder than simply handling builder events. That's
why CSS has SAC and DOM2 (http://www.w3.org/TR/DOM-Level-2-Style/css.html)
interfaces. Both are useful, but anyone wishing, say, to build a custom
selector object to get elements out of his own type of tree will probably
use SAC.

Plus, a "DOM treatment" seems to imply making it a tree. The only useful
context I can see where XPath's ought to be treated as trees is in the
parse tree resulting from the XPath (but I may be totally wrong here). It
depends if you want to see foo|bar|baz treated as something "flat" (eg a
UnionList), or if you want:

<Union>
    / \
foo  <Union>
           /  \
        bar  baz

Again, I think that SAC offers a good model because it combines both.
People interested in this should have a look at it. Forget the
DocumentHandler interface which is not what you're interested in, and look
at Selector, SelectorFactory, Condition, and ConditionFactory. There's a
builder interface and an interface to selectors (which include conditions).
The latter is in a tree-like fashion (as above) which has pros and cons.

PS: for those interested, I've just released a SAC parser for Perl. It's in
alpha, and hasn't been put on CPAN yet because I couldn't find a sufficient
number of complex enough style sheets to test it with (I've only tested
with a number of simpler ones). Until it is released, you can get it from
http://www.berjon.com/perl/CSS-SAC-alpha.tar.gz. My plan is precisely to
end up using it as a test case for a selector API of the kind that has been
described in this thread.

-- robin b.
Brain damage is all in your head.

• References:
  • We need an XPath API
    • From: Charles Reitzel <creitzel@m...>
  • re: We need an XPath API
    • From: David Megginson <david@m...>

• Prev by Date: re: We need an XPath API
• Next by Date: Re: PSVI
• Previous by thread: re: We need an XPath API
• Next by thread: Re: We need an XPath API
• Index(es):
  • Date
  • Thread