- From: John Boyer <jboyer@PureEdge.com>
- Date: Wed, 24 May 2000 15:55:10 -0700
- To: "XML DSig" <w3c-ietf-xmldsig@w3.org>
- Cc: <jjc@jclark.com>, <Steven_DeRose@Brown.edu>
I was just reading through the XPath spec for the umpteenth time when I realized that although the node() function matches any time of node, it can only match any type of node available on the given axis. Furthermore, the descendant and descendant-or-self axes of XPath exclude attribute and namespace nodes (for some completely unfathomable reason). Although the whole idea of having special axes for namespaces and attributes is flawed and unnecessary (rather than simply leaving them as children of the element and letting the fact that they have a *TYPE* of namespace or attribute carry the information), we have to live with the recommendation. Therefore, in places where I have in the past used the subexpression "/descendant-or-self::node()" to mean ALL of the nodes in the parse tree INCLUDING namespace and attribute nodes, it is necessary to substitute the following subexpression: (//. | //@* | //namespace::*) The union operator | combines the results of the three sets. The first subexpression (//.) is the abbreviated syntax for obtaining the root document node and all of its descendants (which unfortunately includes only elements, text nodes, processing instructions and comments). The second subexpression obtains all of the attributes in the entire parse tree, and the third obtains all of the namespace nodes in the entire parse tree. The union of the three sets contains all of the nodes in the parse tree. Do you think there is any possibility that this might get fixed at some point in the future? It seems terribly tedious to have to go through such hoops to simply say "give me a set containing all nodes in the whole parse tree". If not, I suppose we can be content that at least there is *some* way to indicate what we want. John Boyer Software Development Manager PureEdge Solutions Inc. (formerly UWI.Com) Creating Binding E-Commerce jboyer@PureEdge.com
Received on Wednesday, 24 May 2000 18:55:23 UTC