W3C home > Mailing lists > Public > public-xmlsec@w3.org > July 2009

Clarifying XPath Filtering Transform text (pertains to Action-350, etc.)

From: Ed Simon <edsimon@xmlsec.com>
Date: Tue, 28 Jul 2009 16:51:29 -0400
To: XMLSec WG Public List <public-xmlsec@w3.org>
Message-Id: <1248814289.3240.11.camel@XMLSEC-BIZ.phub.net.cable.rogers.com>
As per this morning's meeting, here is the email re clarifying XPath
Filtering and serialization. Note that I've tried to present the
questions as if I was a newbie going though the XML Signature

The Canonicalization 1.1 specification 



"The first parameter of input to the XML canonicalization method is
either an XPath node-set or an octet stream containing a well-formed XML

The English language, alas, makes it a little ambiguous as to whether
this means an XPath node-set has to be a well-formed XML document or
only octet streams have to be well-formed XML documents. My
understanding is that it is generally taken that the input has to be a
well-formed XML document whether it is an XPath node-set or an octet
stream. (If so, we should clarify that in the Canonicalization

The XML Signature 1.1 specification describes the output of the XPath
Filtering Transform as follows:
The transform output is always an XPath node-set. The XPath expression
appearing in the XPath parameter is evaluated once for each node in the
input node-set. The result is converted to a boolean. If the boolean is
true, then the node is included in the output node-set. If the boolean
is false, then the node is omitted from the output node-set.

And from the XPath 1.0 specification

The primary syntactic construct in XPath is the expression. An
expression matches the production Expr. An expression is evaluated to
yield an object, which has one of the following four basic types:

    * node-set (an unordered collection of nodes without duplicates)
    * boolean (true or false)
    * number (a floating-point number)
    * string (a sequence of UCS characters)

To summarize:

1) The input to a hash algorithm is an octet stream.

2) In XML Signature, node sets are converted to octet streams by running
the node set through an XML Canonicalization algorithm.

3) The XML Canonicalization algorithms require a node set that
represents a well-formed document.

4) And this is where it gets a little unclear for me...unless the XPath
expression in an XPath Filtering transform is set to evaluate to a node
set of a single XML element, then the XML Signature specification seems
ambiguous as to what will happen.

I believe it would be sensible to support XPath expressions that return
boolean, number, and string values. Is that generally agreed by the
workgroup? If so, then do we also agree that in those cases, XML
Canonicalization is NOT necessary? If so, we should state that in the
XML Signature specification. 

One thing I find confusing is that XML Signature description of XPath
expression evaluation (done after the justifiably unique context
initialization for XML Signature XPath Filtering) seems to differ from
that prescribed in the XPath specification. The XML Signature
description of XPath expression evaluation seems to be solely focused on
XPath Predicate processing and not the general XPath expression
evaluation prescribed in the XPath specification. Do XML Signature
implementation actually implement XPath expression evaluation as
described in XML Signature or do they just use the APIs that follow the
generic W3C XPath Recommendation? (I suspect the latter is generally the

I also believe it would be sensible to support XPath expressions that
return generic XPath node sets. I'm guessing most implementations do
this but I'd like to hear how. For example, what is the prescribed
treatment of the following examples of node sets returned by an XPath
Filtering transform in order to produce a hashable octet stream?:

* a node set containing two element nodes;

* a node set containing an attribute node;

* a node set containing a text node; and

* a node set containing all of the above.

Received on Tuesday, 28 July 2009 20:52:12 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:11 UTC