RE: Pulling together some threads ...

:1. It must be DOM-compatible

Yes.

:2. It must be language neutral and vendor neutral.  

This is must if it is going to have any standing in the w3c.


:3. It must allow XPath expressions to define some subset of an XML
:   document, stream, or database.

Hmm. Why streams and DB backends? XPath is a language for addressing into an
XML document, which it considers as a tree of nodes. The second purpose of
XPath is as a pattern matching language primarily for enabling XSLT. It is
not in the first instance a query language, though it can be used as such.
XPath is fully document-centric. Whatever data/storage model lies behind the
logical document view is an implementation issue, and not of the API proper.
The API must only manipulate XML trees, in essence a DOM.

:4. It must not require all DOM implementers to support this 
:functionality.

Yes. It should be an optional package, although I think a *lot* of people
are going to want to implement this, compared to say the CSSOM and views,
since it's incredibly useful. So it's worth spending time getting it right
(or just arguing about it : ). 

Given that the smart money says the w3c query language is going to take
roughly a year, and they seem to have plans for beefing up XPath, perhaps
what we need for the next year or so is a minimal DOM *addressing* API that
supports in some fashion an extensions hook (a la SAX) for implementers who
have specialised or advanced needs. I think we should agree on the nature of
the beast, before deciding where it should be packaged wrt to the DOM.


:5. It should provide some level of compatability or migration path
:   for users of existing XPath extensions to the DOM (e.g., those of
:   Microsoft and Oracle).  For example, we could imagine holding our
:   noses and suggesting a Node::selectNodes() interface as a minimal,
:   but compatible and convenient, interface as well as a much more
:   powerful and flexible XpathQuery or whatever interface.

Only if it's convenient/fundamental by consensus. I don't believe the API
should be driven toward current extensions prima facie.


:6. It may extend the DOM Node interface, or it may add one or more
:   new interfaces to the DOM, or it may be quite tangential to the DOM.
:
:7. ??? help me out here!

Maybe that's enough for a first go. I really don't want to be stuck with a
Rube Goldberg XPath API. 


-Bill

Received on Friday, 5 May 2000 04:20:45 UTC