- From: Scott Boag/CAM/Lotus <Scott_Boag@lotus.com>
- Date: Wed, 3 May 2000 17:20:04 -0400
- To: www-dom-xpath@w3.org
> 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.
+1.
> 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".
+1. But I think we have to bound this. Which language bindings? I think
DOM only has Java and IDL? Are we looking to go beyond this? (I don't see
how we can).
> 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.
Hmm... if we are defining this in terms of the DOM, then only Node as a
context makes sense. A stream or database may hide behind Node, but I
don't think we know about that. So I'm not sure about "stream, or
database".
> 4. It must not require all DOM implementers to support this
functionality.
+1.
> 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.
-0. I don't think we should let existing proprietary extensions to the DOM
mold the design. If it easily fits, then fine.
> 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.
I don't think this is a requirement... it's too fuzzy. Rather, this is an
open issue to the requirements.
> 7. ??? help me out here!
7. Match Patterns? Though they are XSLT and not XPath, they are very
useful.
A weak +1 from me. We could probably live without it, though I suspect
most XPath engines will support match patterns. Could be another optional
interface?
8. Extensions?
+1 from me. But note that this implies return of a generic object
type, not just the five XPath types. Also, this may open a Pandora's Box
regarding extension bindings. Would it be better to save this for a later
date?
9. Something that takes a node and produces a XPath or XPointer?
+1 from me. I've had a lot of requests for this.
10. XPointer? I think this is well enough defined that it is in scope. I
think this means a function that returns a Range object. Probably some
nasty issues.
+1 from me. Is there any activity regarding an XLink API??
11. Non-node expressions? "2+2", "child::foo='blah'", etc.
+1 from me.
12. I assume variables environment support. Should be explicitly listed
as a requirement.
+1.
13. I assume namespace environment support. Should be explicitly listed
as a requirement.
+1.
Open issue: Compiled XPath object? or always specify via strings? Or
both?
Undecided from me.
(If a Compiled XPath object, then thread safety without required locking
becomes a requirement).
Open issue: Is this explicitly XPath, or is it simply an expression API
that is oriented towards XPath.
I guess +0 for me on it being an Expression API, that can return in the
least a NodeIterator. But I am somewhat undecided.
Open Issue: Database API support? (for instance, authorization functions).
-1 from me. I think this is out of scope.
Open Issue: Multiple Document support (i.e. pass a NodeList instead of a
Node as the context).
Undecided from me.
Is the idea to release this as part of DOM3, or as a separate note? (This
may have been talked about somewhere else that I am not aware of).
-scott
"Michael Champion"
<Mike.Champion@SoftwareA To: <www-dom-xpath@w3.org>
G-USA.com> cc: (bcc: Scott Boag/CAM/Lotus)
Sent by: Subject: Pulling together some threads ...
www-dom-xpath-request@w3
.org
05/03/2000 04:14 PM
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 17:20:02 UTC