Re: Document Object Model (DOM) Level 3 XPath Specification

Philippe Le Hegaret wrote:
> We thought about a result object but it creates an indirection since you need
> to get the result object and then the result value. Based on the assumption

So?  Why is this so bad?  It could be argued that the factory model of
using a Document to create nodes is useless indirection, and indeed,
that was one of the biggest arguments for JDOM.  Personally, I think
factories are the right way to go, especially for an API that needs to
be bound to multiple languages and to take into account a variety of
implementations.  Not creating this indirection pretty much FORCES a
specific type of implementation, where the indirection could allow the
implementation to take either path.

> that most of the apllications will know the result type before invoking the
> methods, we didn't change the current proposal. But, in order to address your

That's a VERY bad assumption.  It's especially bad as XPath starts to
flesh out with more types.  The implication is that an application
(let's use a GUI as an example) will require a set of options that map
to every possible result type in order to even issue a query, rather
than allowing a result set to be inferred from the type of query that is
being processed.

> use case, the current approach is to add a new method that returned the type of
> the XPath expression.

As you probably know, my requirements are exactly the same as Christian,
and they are very valid requirements.  As the author of an XML database,
the performance and functionality of my product will depend on its
ability to pre-process queries and to cache the parse trees in addition
to priming indexes for repeated queries.  The current approach requires
a query to be parsed repeatedly, even if was just issued about 10
milliseconds prior.  Granted, I could always create a hashtable that
maps a string to an internal representation, but for the sake clarity,
the other way is much better.

> Unfortunately, we didn't find enough interest across the current DOM
> implementations to add this functionality in the API. The current approach is
> not meant to cover all the use cases but to provide a simple approach [1].

Well, I've written a DOM implementation for dbXML, and this is
ABSOLUTELY an interest that I have.  I'm willing to bet that over time,
and with real usage of the API, rather than speculation, you'll find our
arguments on this list more and more often.

> IMHO, a complete version of a Query API could be addressed in the future based
> on the work of the XML Query WG.

Personally, I'd rather see it coming from the XML:DB initiative.  :)

-- 
Tom Bradford --- The dbXML Project --- http://www.dbxml.org/
We store your XML data a hell of a lot better than /dev/null

Received on Thursday, 21 June 2001 18:12:06 UTC