Re: Draft Note on DOM Support for XPath 2.0

Hi,

> > Is XPath2Value the same as "item" in the specs?
> 
> In which specs?  I am not sure what you are talking about.  Sorry.

Item is one of the fundamental components in XPath2. It is what sequences 
contain. Take a look at the data model 

http://www.w3.org/TR/xpath-datamodel/#sequences

or the basics section 

http://www.w3.org/TR/2003/WD-xpath20-20030822/#id-basics

of the XPath2 spec for more information.

It seemed to me if you were accessing a particular "value" in a sequence 
this may well map to the XPath2 concept of item.


> > 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.

XPath2 is not just a node selection language . If it was then this may 
well be out of scope (and may still be, if it is decided not to harness 
the other abilities of XPath2). Off the top of my head, by passing in a 
context item you could:

provide a parameter to one of the near 200 functions,
compile an expression like (/foo/bar/ping)[.] and have the context item be 
numeric,
provide an atomic value and see if it is and instance of a type.

In addition to this, users may well want to implement more complex logic
on top of this interface. For example, something like a for loop. I do not
see why we would want to restrict each iteration of that for loop to be
only able to set the current item to a Node.

Finally it would also provide a closer binding with what is defined in the 
XPath2 context and the interface.

> > 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.

In the current interface you allow the retrieval of DOM Nodes and 4 types
(although one may be a serialization method). In XPath this may have been
reasonable given the limited number of types in the language. However, in
XPath2 you have the 44 types defined by XML Schema, the 4 additional types
defined in the data model as well as an infinite set of user defined
types. As I noted above, XPath2 is no longer just a node selection
language, it is also a language for the access, creation and manipulation
of instances of the rich set of datatypes which are defined in the static
context (or from the grammar used to validate the document in the DOM
sense).  In the same way you are able to retrieve and manipulate a
"double" in the current interface, you should be able to do the same with
all the datatypes available. Implementors will have to be able to this
internally and I see no reason not to extend that ability to users.


> 
> > 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.

That depends if the things already exist. The result of any function call/
node selection is a sequence. In C++ we would return a pointer to the
item, in Java a reference. No clone method, constructor or copy
constructor will have been called that was not already called. I can see 
possible implementations where this is not the case, I am simply pointing 
out that it is not as clear cut as your statement.

> >
> > 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.

Again, I have to disagree, it would depend on if the item already 
existed. It adds usefulness as it provides the ability for implementors 
to extend Item and provide the full hierarchy of types available without 
having to constantly add a method asXXX.


> > 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?

With the example, I call currentItem()->asNode(). The currentItem would be
an extension to your standard asXXX calls. This means that you would still
be able to go asNode(). Because of this there would be no more indirection
unless the user required/desired it.

> > > 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();
> 

OK, so with the currentItem extension, how would this get any longer? The 
method asNode would still be available to you.


I think it is a mistake to regard XPath2 in the same way as XPath1. I am 
coming round to Elliottes view that a completely separate interface may be 
required to fully harness the abilities of XPath2.


Gareth


-- 
Gareth Reakes, Head of Product Development  +44-1865-203192
DecisionSoft Limited                        http://www.decisionsoft.com
XML Development and Services

Received on Wednesday, 3 September 2003 10:52:24 UTC