Re: XPath transform

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

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