W3C home > Mailing lists > Public > www-dom-xpath@w3.org > May 2000

Pulling together some threads ...

From: Michael Champion <Mike.Champion@softwareag-usa.com>
Date: Wed, 3 May 2000 16:14:25 -0400
Message-ID: <0c5e01bfb53c$2e548720$a20c1e18@WORKGROUP>
To: <www-dom-xpath@w3.org>
I've certainly learned a lot from the first few days of discussions here,
although I can imagine that it's a bit overwhelming for some!

Let's consider the "requirements" for an XPath API, or perhaps a family of
APIs.  Here's my attempt at a first cut; I offer these mostly as a way of
focussing and structuring the discussion so that we don't go off into too
many directions at once.

1. It must be DOM-compatible, i.e., use DOM concepts rather than invent any
   new infrastructure (such as Nodes, lists, iterators, etc.) unless
   absolutely necessary.

2. It must be language neutral and vendor neutral.  As much as we all
   like [insert favorite language or system here], it's important
   to have as much consistency as possible across "language bindings".

3. It must allow XPath expressions to define some subset of an XML
   document, stream, or database and provide a way of iterating over
   or otherwise processing that subset.

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

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.

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!


This list (which we can discuss, refine, etc.) doesn't restrict the space of
possible outcomes very much, I'll admit, but should make clear what we all
agree on and what we may choose to "agree to disagree" on.  For example, I
can see two "flavors" of an XPath API, one that is built INTO the DOM (for
vendors such as us who have deeply imbedded XPath implementations that we
need to expose an API to) and one that is built ON TOP OF the DOM (for
vendors who want to make their XPath implementation available to any DOM
implementation).  So long as they share everything that they CAN share, I
see no problem in an W3C Note or DOM spec that allows either or both.

Comments, thoughts, flames, suggestions???
Received on Wednesday, 3 May 2000 16:14:34 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:43:07 UTC