RE: Enveloped signatures and XPath

On Thu, 23 Mar 2000, John Boyer wrote:
> Attached and Pasted below is the HTML for a new version of the XPath
http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000JanMar/att-0250/01-transforms2.htm

Thanks John, looking good (I look forward to others' comments), brief
comments following:

>Identifier: 
>http://www.w3.org/TR/1999/REC-xpath-19991116 

I think we should move  this identifier to our own namspace since we
specify something above and beyond.

>(The XPath transform cannot simply
>generate incorrect output since many applications distinguish an
>unverifiable signature from an invalid signature).

We don't mention exception handling elsewhere in the spec (which is more
protocol orientated), we should probably add some explanatory text about
this (perhaps including a definition for 'unverifiable'.)

>As a result of reading the input with an XML processor, linefeeds are
>normalized, attribute values are normalized, CDATA
>sections are replaced by their content, and entity references are
>recursively replaced by substitution text. In addition,
>consecutive characters are grouped into a single text node.
>The XPath implementation is expected to convert the information in the
>input XML document and the XPath expression string
>to the character domain prior to making any comparisons such that the
>result of evaluating the expression is equivalent
>regardless of the initial encoding of the input XML document and XPath
>expression.

Do we need to recommend that Canonical XML transform be used before
the Xpath? (Or do we assume the processors use Canonical XML (or some
other  method (e.g., DOM)) consistently to accomplish this?)

>The method of text generation is dependent on the node type and given in
>the following list:

(typo)

Received on Monday, 27 March 2000 02:48:38 UTC