Re: Draft Note on DOM Support for XPath 2.0

On Wed, 27 Aug 2003, Gareth Reakes wrote:

> Hi,
>
> > XPath2Sequence
> >
> > and
> >
> > XPath2Value
>
>
> Is XPath2Value the same as "item" in the specs?

In which specs?  I am not sure what you are talking about.  Sorry.

Value would be yet another layer of indirection, which is why it has
been rejected in the past.

> As to what this adds to the XPath2Result method, I would say 2 things:
>
> i) The ability the set the "context node" to an item (although we then
>    need some way of constucting them)

I still do not understand why you would set the content node to an item.

To the best of my knowledge, it is not useful to execute an xpath on an
item other than a node.  At least it seems to be quite out of scope.

> ii) The ability for implementors to provide a full hierarchy if they
> desire. We have all the classes available and can provide them. It does
> not make sense for us to limit this.

I have lost context somehow.  I do not know what you are talking about.

> I don't see any more allocation for us. We would make our item implement
> whatever interface was specified and just return a pointer to the
> requested item from the sequence.

It is another item to be allocated for each thing accessed through the
interface.  That and more indirection.

> //note - very rough code
>
> Access multiple fields using the XPath2Result way
>
> Access multiple fields using the XPath2Result way
>
> XPath2Result xp2r = (XPath2Result)doc.evaluate(...);
>
> while(xp2r.iterateNext()) {
>   String a = xp2r.asString();
>   boolean b = xp2r.asBoolean();
> }
>
>
> And the item way:
>
> XPath2Result xp2r = (XPath2Result)doc.evaluate(...);
>
> while(xp2r.iterateNext()) {
>   String a = xp2r.currentItem().asString();
>   boolean b = xp2r.currentItem().asBoolean();
> }
>
>
> Sure you have 2 extra method calls per iteration(one of which could be
> saved creating a variable) but I don't think it's that big of a cost. And
> realistically, how many times are you going to access multiple fields of
> the item in either case? I think the further indirection adds clarity to
> the code.

This also clearly demonstrates the extra allocation -- the fact that you get
an item object back from the API.  It is not obvious to me how this adds
clarity or any other useful thing to the code.

> If people feel that this is still cumbersome then we could add a
> getCurrentItem to the XPath2Result interface. This may lead to some
> duplication in methods, but we could always make XPathValue (item) the
> base class for XPath2Result.

How is this different from your example in which you called currentItem()
on the result?

> > In ECMAScript, it makes it more difficult to access the
> > results in a single line, etc.  This was also previously a concern
> > with this approach.
>
> I am unfamiliar with ECMAScript and, if its not too much trouble, would
> like to see an example.

Here is a simple example -- may not be perfect, but close:

var node = doc.evaluate("expr...",doc,null,100,null).asNode();

A simple one-line expression to get a node based upon an XPath expression
from a document.

You are correct that it only gets significantly longer.  It is still possible
to do on a single line with a result that is always a sequence.  But it
involves extra allocation and iteration.

Ray

Received on Tuesday, 2 September 2003 12:57:10 UTC