- From: Scott Boag/CAM/Lotus <Scott_Boag@lotus.com>
- Date: Tue, 2 May 2000 15:31:40 -0400
- To: www-dom-xpath@w3.org
> Yes, but XPath is the closest thing we have to a standard query language for > XML, people need to do queries on XML documents, so why not an XPath API? Because when it's time to do a real query API, this may well confuse matters. It's better to not do an API, rather than do an API completely wrong. (I'm actually not taking a position on this yet... just asking the question.) > This is more or less what Microsoft > supports as a DOM extension Microsoft added this to their DOM implementation. This is different from a standard interface. > It's an optional module, so it won't contribute > to "bloat" (and anyway, one person's bloat is another's core feature). I don't see how a method on Node is (or should be) really optional. In any case, bloated it is: witness the JDOM stuff. People are becoming upset with the sheer size of the API, in my experience. > (and anyway, one person's bloat is another's core feature) The question is, why should it be on the Node object? BTW, I don't think that an XPath API is just one function. > So, what is wrong with the proposal > > NodeList getNodesByXPath(DOMString xpathExpression) 1) It implies that the DOM implementor should create this functionality, as opposed to an outside module. Modularity is good, in my opinion, and DOM is missing on this. 2) It ties getNodesByXPath to Node forever. 3) You should be able to compile the XPath, and then run it over and over again using different contexts. 4) Given the above method, what is the namespace context of the expression (i.e. where to prefixes get resolved? Should not be relative to the node being queried.) > - The result shouldn't be a NodeList Yes, right, though you need a convenience method for this, in my opinion. > - We should allow other query languages than XPath Yes. How about something like the following? package org.w3c.expression; public abstract class XExpressions { public XExpression create(String expression, NamespaceSupport nsSupport); Object evaluate(String expression, NamespaceSupport nsSupport, Node context); NodeIterator getNodes(String expression, NamespaceSupport nsSupport, Node context); Node getNode(String expression, NamespaceSupport nsSupport, Node context); public boolean supports(String feature, String version); } // NamespaceSupport needs to be defined public interface XExpression { Object evaluate(Node context); NodeIterator getNodes(Node context); TreeWalker getFilter(Node context); // ?? Node getNode(Node context); String getStringValue(Node context); double getNumberValue(Node context); boolean getBooleanValue(Node context); Range getRangeValue(Node context); // XPointer int getMatchScore(Node context); // XSLT Match Pattern } My big point is, I don't think that all new API in the W3C should become part of the DOM. There is also the matter of the XML Transformation API (please see http://trax.openxml.org/), which maybe should become a W3C API, but should not a DOM API. Also, remember that XPath can call extensions, so now you need an Extensions API. Then there's the little matter of Schemas. Etc. The DOM Pandora's Box should be closed, and the W3C should be thinking in terms of modules. I would also like to see some of these APIs include SAX stuff. -scott "Michael Champion" <Mike.Champion@SoftwareA To: <www-dom-xpath@w3.org> G-USA.com> cc: (bcc: Scott Boag/CAM/Lotus) Sent by: Subject: Re: [dom-xpath] XPath or? (was RE: Announcing www-dom-xpath-request@w3 www-dom-xpath@w3.org) .org 05/02/2000 01:57 PM ----- Original Message ----- From: "Scott Boag/CAM/Lotus" <Scott_Boag@lotus.com> To: <www-dom-xpath@w3.org> Sent: Tuesday, May 02, 2000 1:34 PM Subject: [dom-xpath] XPath or? (was RE: Announcing www-dom-xpath@w3.org) > > If it's an > XML Query API, it's way early to be discussing this. Yes, but XPath is the closest thing we have to a standard query language for XML, people need to do queries on XML documents, so why not an XPath API? > > I would really *not* like to see something like getNodes(XPath expression) > as a method on Node Good, let's get the discussion going! This is more or less what Microsoft supports as a DOM extension, people use it all the time, it seemed like a good starting point for a proposed standard API. Why don't you want to see this in the standard DOM? It's an optional module, so it won't contribute to "bloat" (and anyway, one person's bloat is another's core feature). So, what is wrong with the proposal NodeList getNodesByXPath(DOMString xpathExpression) as a standard DOM method? The objections I've heard are: - The result shouldn't be a NodeList - We should allow other query languages than XPath Discussion?
Received on Tuesday, 2 May 2000 15:31:41 UTC