[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: We need an XPath API
- From: "Thomas B. Passin" <tpassin@home.com>
- To: xml-dev@lists.xml.org
- Date: Sat, 03 Mar 2001 18:44:36 -0500
Charles Reitzel proposed an API for XPATH -
> 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.
>
> Proposal: let's give XPath the SAX treatment.
>
> What should such an API do? How should it behave?
>
> 1) Small, lightweight
> 2) Should emit/accept XML representation
> of XPath expression
> 3) Provide info about expression
> 4) Define an XML representation of XPath expressions
>
> Possibles (not so small):
> 1) Provide DOM traversal?
> 2) Provide SAX-based pattern matching?
>
Let's not stop here. Let's include XPointer. I think that would be quite
important. It may complicate things, I don't know, but there is going to be
the same need for XPointer.
I don't see 4) as being part of it at all. There should be a mechanism for
handlers, as in SAX. If you think about SAX, it basically says, "if you get
an element in the source,notify the application and included the element's
name and other info". Ditto for other xml constructs. Then it says, "here's
what the java method should look like". There's no XML representation in
there at all. This is a Good Thing.
We need some requirements engineering here. Especially, what would the API be
used for? SAX lets us use a parser without having to know how to talk to each
different one. What do we want to use our XPath/XPointer API for?
Here are some general kinds of things:
1) Parse and process the XPointer syntax. This would be useful for developers
to create XPointer applications and toolkits.
2) Return node-sets. This is more like a query capability, and would be more
useful for application writers.
3) Construct XPointer expressions based on some existing tree (fragment).
4) Construct XPointer expressions based on a schema (fragment?)
These are quite different, and it might not be feasible to accomplish all of
them. We need to work out what would be valuable. Let's remember the 80-20
proposition!
Cheers,
Tom P