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

Ed

comment inline, suggestion that we may need additional revision to  
6.6.3 if we go with your proposed change.

regards, Frederick

Frederick Hirsch
Nokia



On Jul 28, 2009, at 8:31 PM, ext Ed Simon wrote:

> OK, so I'm looking at the C14N test cases in
>
> http://www.w3.org/TR/2008/NOTE-xmldsig2ed-tests-20080610/
>
> and I see there are some that introduce non-well-formed XML node- 
> sets as
> input to canonicalization. However, I don't see any examples in the  
> C14N
> 1.1 specification that deal with non-well-formed input node-sets and
> much of the text seems to imply input node-sets represent well-formed
> docs. (Let me know if you see something to the contrary.)
>
> So, I would suggest the following:
>
> 1) That the line in the W3C Canonicalization 1.1 specification that
> states
>
> "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
> document."
>
> be changed to
>
> "The first parameter of input to the XML canonicalization method is
> either an octet stream or an XPath node-set. If it is an octet stream,
> the octet stream must contain a well-formed XML document."
>
> 2) Add some examples of canonicalizing non-well-formed input node sets
> to the C14N specification (they can be taken from the interop test
> cases).
>
> 3) A minor typo: look for any instances of "node set" in the C14N
> specification that should be "node-set".
>


we have to decide whether to update C14N 1.1 or simply go toward C14N2.0

>
> Now, re the description of XPath Filtering in the XML Signature
> specification. What one specifies in the <dsig:XPath> element is not  
> an
> XPath expression but an XPath Predicate Expression that when evaluated
> will be prepended with "(//. | //@* | //namespace::*)" to form the
> actual XPath expression that will be evaluated.
>
> As such, I propose the first sentence in section 6.6.3 which states
>
> "The normative specification for XPath expression evaluation is  
> [XPath].
> The XPath expression to be evaluated appears as the character  
> content of
> a transform parameter child element named XPath."
>
> be changed to
>
> "The normative specification for XPath expression evaluation is  
> [XPath].
> [XPath] defines "predicate expressions" (have link) which provide a
> boolean qualifier to node-set specifications. In the XML Signature  
> XPath
> Filtering transform, the node-set specification is defined as "(//.
> | //@* | //namespace::*)" and the predicate expression for that node- 
> set
> specification is specified through the content of the <XPath> element.
>
> For example, this XPath Filtering element
>
> <XPath>
> @signMe='true'
> </XPath>
>
> will result in the following XPath expression being evaluated against
> the input node-set:
>
> (//. | //@* | //namespace::*)[@signMe='true']
>
> ".
>
>

I'm not sure this change is absolutely necessary, since the text in  
6.6.3 seems to discuss this in the following paragraph, though I  
think  what you propose could result in a more readable and  
understandable section:

[[
The input required by this transform is an XPath node-set or an octet- 
stream. Note that if the actual input is an XPath node-set resulting  
from a null URI or shortname XPointer dereference, then comment nodes  
will have been omitted. If the actual input is an octet stream, then  
the application MUST convert the octet stream to an XPath node-set  
suitable for use by Canonical XML with Comments. (A subsequent  
application of the REQUIRED Canonical XML algorithm would strip away  
these comments.) In other words, the input node-set should be  
equivalent to the one that would be created by the following process:
	• Initialize an XPath evaluation context by setting the initial node  
equal to the input XML document's root node, and set the context  
position and size to 1.
	• Evaluate the XPath expression (//. | //@* | //namespace::*)

]]

I think what you have suggested is much clearer. If we adopt it, do we  
need to simplify/revise this second paragraph and the rest of the  
section  as well? Can you please look at the whole section and  
indicate what other changes you would make (or did you plan to remove  
the existing material and replace with your proposal?)


> Right now it seems to me that a complete, unambiguous understanding of
> the core specifications requires looking at the interoperability docs
> (which I almost never do as I'm not an implementor). I think the above
> changes would help clarify the specs.
>
> Again, let me know if my understanding is amiss.
>
> Ed
>
>
>
> On Tue, 2009-07-28 at 18:19 -0400, Scott Cantor wrote:
>> Ed Simon wrote on 2009-07-28:
>>> 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
>>> specification.)
>>
>> Pretty (as in 100%) sure that's NOT the case. C14N is such a pain  
>> because
>> it's NOT assumed to be anything but a totally arbitrary node set.  
>> In the
>> octet stream case, it's a well-formed document, but not otherwise.
>>
>>> 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?:
>>
>> In all cases, you apply c14n. I think you got lost because you took  
>> a wrong
>> turn on the input rules there.
>>
>> -- Scott
>>
>>
>>
>>
>>
>
>

Received on Wednesday, 29 July 2009 14:56:04 UTC