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

Miles Sabin <msabin@cromwellmedia.co.uk> wrote:
> So any new XPath methods would actually
>   live on something like a NodeXPath interface rather than
>   Node itself

This would make me a little happier.  Not by much if it had to be
implemented by Node, instead of passing the methods a Node context.

> In any case, the mere number of methods on an interface
>   isn't a particularly interesting software design metric.

I respectfully disagree.  Number of methods indicates the surface area of
an interface, and is some indicator of the complexity of the object.  I
agree it is only one metric, and must be used with number of interfaces
needed, depth of inheritance, number of arguments needed, and dependencies
between interfaces.  In any case, the real metric is the pain coming from
users.

> Allowing a DOM implementation to _optionally_ implement
>   XPath itself opens up the possiblity for _significant_
>   optimizations over what can be achieved via the exisiting
>   public API.

Just because I have a method that is passed a node, doesn't mean I can't
cast to node to a given implementation, and be optimized, but otherwise
throw an exception if the given implementation isn't supported.  On the
other hand, you may have some implementations that can do queries from only
the public interfaces.  I do know of many environments that use multiple
DOM implementations, so I don't think a generic XPath query is such a bad
thing to have.  I don't think optimization is an argument at all.

Remember, Microsoft and Netscape and IBM aren't the only implementers of
the DOM interfaces.  An application developer may implement the interfaces
over his or her application structure, so that it can be generically
manipulated by processes that work on a DOM.  It should be relatively easy
to implement a DOM, but it's getting harder with each rev of the DOM spec.
DOM is not an application, it's a set of interfaces.

The DOM package should do what it's name implies: be a Document Object
Model, and it should not be a Query interface, or a Stylesheet interface,
an event interface, etc.

-scott

Received on Wednesday, 3 May 2000 13:44:55 UTC