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: Fri, 21 Jan 2000 13:49:59 +0900
Message-Id: <200001210449.NAA42742@ns.trl.ibm.com>
To: <w3c-ietf-xmldsig@w3.org>

> 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.

If the elements with some attributes are included in the result
of XPath, we can apply the XML-C14N transform after the
XPath transform.  We have a problem in the case where the result
is not well-formed.

If the result of an XPath transform was always well-formed, we
could calculate a digest value by applying the XML-C14N
transform. Otherwise, the XML-Signature specification must
define octet stream presentations for the result of XPath, not
string representations.

> 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.

One of the advantege of using XML and XML-related specifications
is that we can reuse existing implementations conforming to each

It seems arrogation that the XML-Signature specification defines
behavior of XSLT implementations.

TAMURA Kent @ Tokyo Research Laboratory, IBM
Received on Thursday, 20 January 2000 23:50:34 UTC

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