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

Scott Boag wrote,
> Miles Sabin <msabin@cromwellmedia.co.uk> wrote:
> > So whose implementation will you cast to to get hold of 
> > those optimized query hooks? Yours, obviously.
>
> Right, using my optimizations.

Which won't be available to our XPath processor ... so we'd
never be able to recommend your DOM in conjunction with our
tools.

> > But what about ours? Jonathan and Mikes?; Suns? etc. etc.
>
> In the case of my XPath implementation, I would support these 
> via the public DOM interfaces (yes, it would be slower).  

Which means you won't be able to recommend our tools in
conjunction with yours.

> > And do you expect me to support _your_ implementation
>
> No, not if you don't support generic DOMs.

Well, I'd support a generic DOM, but wouldn't expect the
results to be particularly exciting performance-wise. Running
an XPath query against a DB-based DOM via the existing public
API would be painful, to put it mildly.

> > Adding an XPath query API to the DOM allows optimized XPath
> > queries to be _portable_.
>
> I don't think having a method on the Node object vs. having a
> method on an XPath object that takes a node as a context 
> makes one smidgen of difference in terms of optimization or 
> portability.  On the contrary, the method with context is 
> more portable.

I'm afraid I have to disagree. Delegating queries to DOM
implementations allows them to be resolved using internal
information which is simply not available via the public API.

Interoperability is about more than a common API: the API has 
to expose functionality in a _practically_ usable form across different
implementations. Anything else would be an invitation
to vendors to develop proprietary extensions.

> According to your argument, anything that is ever optimized 
> must be a method on the DOM.

Where there's a significant chunk of functionality which would 
be widely used and which would benefit from close integration 
with a DOM implementation, then, yes, I would advocate the 
development of an _optional_ DOM module to support it, tho' not 
necessarily overseen by the DOM WG.

This isn't a new idea. A significant part of Level 2 could, in 
principle, have been implemented externally to the DOM Level 1 
API, but with unacceptable performance implications. One of the 
main motivations for introducing optional modules was precisely 
to avoid that problem.

Cheers,


Miles

-- 
Miles Sabin                       Cromwell Media
Internet Systems Architect        5/6 Glenthorne Mews
+44 (0)20 8817 4030               London, W6 0LJ, England
msabin@cromwellmedia.com          http://www.cromwellmedia.com/

Received on Wednesday, 3 May 2000 14:39:32 UTC