W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > January to March 2000

Re: XPath transform

From: TAMURA Kent <kent@trl.ibm.co.jp>
Date: Mon, 17 Jan 2000 17:37:53 +0900
Message-Id: <200001170837.RAA23912@ns.trl.ibm.com>
To: <w3c-ietf-xmldsig@w3.org>

In message "RE: XPath transform"
    on 00/01/14, "John Boyer" <jboyer@uwi.com> writes:
> For your part B, XPath says that attribute order is application dependent.
> Well, the DSig Xpath transform is an application of Xpath, and the defined
> order is c14n order.  An application that conforms to dsig MUST conform to
> dsig's usage of xpath.

If I implement a signer and a verifier for the XML-Signature, of
course I use an existing XPath implementatoin in LotusXSL or XT.
It is impossible to sort the result node-set evaluated by these
XPath implementation in the c14n order because the node-set can
contain attributes from more than one element and application
can not know a parent element of an attribute node in DOM Level 1.

I think modifying an existing generic XPath implementation as
ordering in the c14n makes no sense.

I found one more problem.
5.6.3 XPath Filtering:
> If the result of the XPath expression is a node-set, then the
> output of the transform is a string containing the text
> rendering of the nodes in the node-set. The nodes are selected
> for rendering based on the document order (as defined in
> [XPath]) of the canonicalized input resource. The text
> rendering is performed in accordance with [XML-C14N].

How to render a node-set that consists of only attributes?  The
c14n does not define the way to render attributes out of an

I think the XML-Signature specification should forbid XPath
expressions such that its result node-set consists of only
If the problems I wrote were solved, the specificatoin would be
very hard to implement and to be understood.

TAMURA Kent @ Tokyo Research Laboratory, IBM
Received on Monday, 17 January 2000 03:38:37 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:21:33 UTC