- From: TAMURA Kent <kent@trl.ibm.co.jp>
- Date: Mon, 17 Jan 2000 17:37:53 +0900
- 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 element. I think the XML-Signature specification should forbid XPath expressions such that its result node-set consists of only attributes. 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