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

Jonathan Robie

Here's a quote from the requirements:

     DOM


     [SNIP!]

     There's a lot of good stuff here. I agree that the method
     should not be
     defined on Node. A few issues:

     1. Input.  I think that the context of a query should be able
     to be a Node
     or a NodeList, and should be able to use nodes from multiple documents.
Damn document() is xslt!
But If needed, I can parse and build dom's for n documents surely?
No problem there. Working with xslt+xpath I have a full context,
is it reasonable to expect the same, e.g. namespace etc? I think
that is needed.

     2. Return type. We can't assume that every query returns a
     NodeList, but I
     think that it's reasonable to assume that the person who
     issues a query
     knows what it returns, and can call the function with the
     proper return
     type. If not, raise an exception.

Definate improvement on enumerator. What would an emulation of
xpath 4(or 5) object types look like in Java?

     3. Query Objects. You are right, the ability to create a query object
     allows a query to be built and optimized, then reused many times. Many
     queries, of course, are one-offs, so it's not clear to me that a Query
     Object is *always* needed. I think that having methods that take query
     strings as arguments is a Good Thing, and is probably the more
     common case,
     but Query Objects are also good. I'd probably like to see both.

Whats the use case for this efficiency? I noted Scotts reply its good
if I need to run the query 2000 times. My question is under what circs
would anyone need to do that?

   DaveP

Received on Wednesday, 3 May 2000 16:32:23 UTC