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

"Julian Reschke" <reschke@medicaldataservice.de> wrote:
> But I think the alternative is not "no API", but that
> everybody is inventing it's own.

A bunch of non-standard proprietary APIs is still better than a standard
bad or broken API that we have to live with forever.  Think of your
children's children...   :-)

> an implementation would need a way to indicate that a specific
queryLanguage
> is unknown anyway (null or DOMException).

Yes.  But that's not the issue.  The issue is yet another method on the
interface.  If XPath is supported, it then *must* be supported via the DOM
Node implementation.  This is just wrong, IMHO.

> What's so wrong with the Node object?

1) Node already has 24 methods on it, which is quite enough.  2) It
requires that the XPath implementation be done *by* the DOM implementation,
instead of *on* the DOM implementation.  And a bunch of other arguments
that I have made in previous emails that I will not reiterate on.

> Could you please explain why this is an issue? In DOM2, the
implementation
> has the full namespace information available for all nodes, right?

The namespace prefix resolving mechanism for the XPath does not necessarily
(and will probably not) use the namespace prefix resolution of the context
node being queried.

> In the end, we
> might need both a specific class "above" DOM which is flexible and
> performant, *and* a convenience function on Node.

If you have the first, I'm not so sure why it would be important to have
the second.  I think it would cause more problems than it would solve.

> What's the implication of Schemas for XPath queries?

Schema's will be addressed in XPath version 2.  For now, XPath isn't very
type aware.  An XPath implementation could use a Schema or DTD to optimize
queries.

-scott

Received on Wednesday, 3 May 2000 13:12:39 UTC