- From: Gareth Reakes <gareth@decisionsoft.com>
- Date: Wed, 3 Sep 2003 15:45:38 +0100 (BST)
- To: Ray Whitmer <ray@xmission.com>
- Cc: Joseph Kesselman <keshlam@us.ibm.com>, "www-dom@w3.org" <www-dom@w3.org>
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