RE: [dom-xpath] XPath or? (was RE: Announcing www-dom-xpath@w3.org)

> From: www-dom-xpath-request@w3.org
> [mailto:www-dom-xpath-request@w3.org]On Behalf Of Scott Boag/CAM/Lotus
> Sent: Tuesday, May 02, 2000 9:32 PM
> To: www-dom-xpath@w3.org
> Subject: Re: [dom-xpath] XPath or? (was RE: Announcing
> www-dom-xpath@w3.org)
> ...
> 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.)

That might be true. But I think the alternative is not "no API", but that
everybody is inventing it's own. XPath queries on DOMs are way to convenient
(that's why we are here, right?).

> > 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.

Maybe the method itself can not be optional, but it's easy to define how a
conforming implementation can indicate that the query actually is not
supported. For instance, if we have:

	NodeList node.selectNodes (String queryLanguage, String expression)

an implementation would need a way to indicate that a specific queryLanguage
is unknown anyway (null or DOMException). If the interface itself is
mandatory, but no specific queryLanguage support is required, the burden for
a DOM implementation is really small.

> > (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.

What's so wrong with the Node object? And I agree that a complete API
probably requires a complete class that allows caching of parsed queries and
binding of variables, but a convenience method on Node probably would handle
95% of the use cases.

> ...
>
> 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.)

Could you please explain why this is an issue? In DOM2, the implementation
has the full namespace information available for all nodes, right?
> ...
>
> 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,

I agree with this, but just because not all new APIs should be part of DOM,
this doesn't necessarily mean that XPath queries shouldn't. In the end, we
might need both a specific class "above" DOM which is flexible and
performant, *and* a convenience function on Node.

> 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

What's the implication of Schemas for XPath queries?

> be thinking in terms of modules.  I would also like to see some of these
> APIs include SAX stuff.

Julian

Received on Wednesday, 3 May 2000 09:43:52 UTC