- From: Gareth Reakes <gareth@decisionsoft.com>
- Date: Tue, 26 Aug 2003 17:04:54 +0100 (BST)
- To: Ray Whitmer <ray@xmission.com>
- Cc: "www-dom@w3.org" <www-dom@w3.org>
Hi, We are currently implementing XPath2 as an open source module for Xerces-C. It is called Pathan2 and is available from http://software.decisionsoft.com. We intend to release an alpha this week and will include your new interface in this release. We will forward any feedback we receive to this list. We have some preliminary comments on the interface. We would be happy to provide much more detailed feedback on the problems we have encountered. i) We agree that the interface name should not be XPathResult2. Our preference is for XPath2Sequence. We feel that every XPath2 expression will return a sequence or raise an error when evaluated. ii) We feel a reverse lookup is required in the NS Resolver. In section 17.7 of the F&O spec it states: "If SV has a namespace URI, then there must be at least one prefix mapped to that URI in the in-scope namespaces in the static context...." This cannot currently be performed. We suggest adding DOMString lookupNamepacePrefix(DOMString uri) to the XPath(2)?NSResolver interface Also, the user should be able to add new namespace bindings to the NS Resolver created starting from the DOM node. This is because: a) the XPath query s/he is going to issue can make use of a specific prefix to refer to a URI (the alternative would be to find out what is the prefix being used for that URI in the XML fragment, then manipulate the - possibly hardcoded - query) b) the NS resolver is supposed to be populated with the namespace in scope for the specified DOM node; but the XPath query could do something like "../ns:node", and "ns" could not be in that list, if defined on the sibling node. We suggest adding void addNamespaceBinding(DOMString prefix, DOMString uri) to the XPath(2)?NSResolver interface. iii) In section 4.3 of the note, you suggest that the Level 3 Core TypeInfo maps to the type information in XPath2. A couple of iterations of the Core spec ago, this was far more true than it is now. Specifically, if an implementation has type information available, even if that information comes from invalid element/attr, then the TypeInfo is set to the type name/ type namespace. This means that there is no way to tell if sections of the document are invalid. We believe that this removes useful functionality and may not be appropriate in its current form. iv) We feel that the ITERATOR_RESULT should not be invalidated if the sequence contains nodes. We feel that this provides unintuitive behaviour for users. v) There is currently no way to set the context item to be anything other than a node. We have provided an implementation of the evaluate method that takes an Item (a new interface that represents an atomic value or a node) in the place of the context node. vi) What is meant by "asDouble of type double, readonly. Conversion of the current result to double.' (Same for other asXXX). By conversion, is casting (in the XPath2 sense) meant? If so, we see two problems: * Casting is defined for XPath2 datatypes only, ie, xs:double, not the implementation's language 'double', and * the type xs:NOTATION cannot be cast to anything, meaning that no xs:NOTATIONs could be extracted from the result Otherwise, could the term 'conversion' be defined? We think that for asString a possible definition would be to serialise as per the DOM Level 3 LS (for nodes) and the XML Schema Part 2 (for canonical form of atomic types). Rewording suggestion: Suggest rewording of the 3rd sentence in 4.3 Data Types "The type information that is defined to be attached to nodes during validation is similar in both the DOM Level 3 Core and XPath 2.0" Gareth -- Gareth Reakes, Head of Product Development +44-1865-203192 DecisionSoft Limited http://www.decisionsoft.com XML Development and Services
Received on Tuesday, 26 August 2003 12:04:59 UTC