Re: Draft Note on DOM Support for XPath 2.0

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