RE: XPath transform

Well, I originally wrote the section such that attributes were placed in
document order, and many whined about that, and the decision was made to
choose c14n order.

Certainly you must be able to get the attributes out in *some* order since
you have a string function that can be applied to any node-set, so it must
generate a string with the attributes in *some* order.  What is the order
used by your implementation's string function?

Secondly, based on what you've said, I don't understand how attribute order
translates into a problem.  It does not seem likely that 'string(some
XPath)' could produce a set of elements with their associated attributes in
the desired order, yet 'string(some XPath/attribute::node())' might scramble
the attributes from the desired order.  Thus, if you cannot solve the
attribute order problem with your XPath implementation, then you have a
problem whether or not the attributes' containing elements are included in
the XPath.

In general, the dsig xpath transform should be implemented so that its
behavior is equivalent to applying c14n as preprocessing then reading the
result and maintaining its document order as node-set transformations occur.
There are few things that could be simpler.  If LotusXSL or XT don't support
this ability, then a new XPath implementation will be required.  You cannot
use an existing XPath implementation if it is not sufficiently robust to
support how dsig is applying XPath.

Still, it would be helpful to know what order is used by those existing
xpath implementations.  If you c14n a document, then put it through one of
these processors with an XPath that isolates some attributes from multiple
elements, then call the string function, what do you get?  It would be so
nice if the processors didn't change the order from the c14n order imposed
by preprocessing, but if the order is changed, it should at least be
consistent so that you can identify how and why it changed.  Please let us
know what you find.

Thanks,
John Boyer
Software Development Manager
UWI.Com -- The Internet Forms Company


-----Original Message-----
From: w3c-ietf-xmldsig-request@w3.org
[mailto:w3c-ietf-xmldsig-request@w3.org]On Behalf Of TAMURA Kent
Sent: Monday, January 17, 2000 12:38 AM
To: w3c-ietf-xmldsig@w3.org
Subject: Re: XPath transform



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 13:04:40 UTC