New proposed fix for here(), was RE: Enveloped Signature Transform, XPath Transform: function here()

Hi Gregor and Joseph,

Other implementers ran into same problems you are reporting.  At the
Pittburgh F2F, we decided to address that problem by

1) Removing the here() function from the XPath transform

2) Specifying the enveloped signature transform as follows:

<Reference URI="#xpointer((//. | //@* | //namespace::*)
   [count(ancestor-or-self::dsig:Signature |
here()/ancestor::dsig:Signature[1]) >
   count(ancestor-or-self::dsig:Signature)])">
	<Transforms>
		<Transform Algorithm="http://www.w3.org/TR/2000/WD-xml-c14n-20000710"/>
	</Transforms>
</Reference>

In other words, take the current document, apply the same XPath that we
previously specified, then canonicalize the result.

As I sit here today trying to write that up, I realize that it fixes the
XPath transform, but does not solve the underlying problem, which is that
the enveloped signature transform needs an extra piece of information that
is simply not in our transform processing model.

It is important to realize that although we can say 'it must behave as if'
the signature were created by the above Reference, but that doesn't fix the
fact that it is still a transform, so our processing model does not allow it
to act like the above Reference.

Instead, it is necessary to fix the processing model. The reason that we
cannot do this by giving transforms access to the parse tree is NOT that it
is a hack, but rather that it is actually not going to work.  Even with
access to the parse tree, the here() function cannot return a node of the
parse tree because it is the parse tree of the current document not the
parse tree of the octet stream's copy of the parse tree.

It occurs to me today that we can fix this problem by adding a second
implicit string parameter to each transform.  All we have ever really needed
is to uniquely identify the signature we are currently processing.  We have
found that it is hard to do this by 'id'.  However, the path from a node
(such as the Signature element) to the root of a tree (the document root) is
unique and therefore it is relatively easy to dynamically compute a simple
XPath expression to describe its location within the document.

I propose that the processing of Transforms should begin with computing the
XPath expression string that describes where the Signature element is within
the current document.  The Signature identifier string remains constant
during the processing of transforms, but any transform needing implicit
access to this information can have it.

The expression would be of the form /doc/echild[n1]/.../Signature[nk], where
the signature is at depth k below the doc root (which is depth 0), and the
numbers n1...nk are a unique signature identifying the path between the root
and the Signature.  Obviously, if the Signature is the root element, then
the string would be "/Signature".

I propose that the XPath and enveloped signature transforms should use this
expression to obtain a node within the parse tree representing the octet
stream input.  This could be returned by a function such as
this-signature().  This would obviously replace the here() function.

Chairs:  Can we now seek consensus from stakeholders on this proposal?  As
soon as consensus is reached, I can provide the modified text.

Thanks,
John Boyer
Development Team Leader,
Distributed Processing and XML
PureEdge Solutions Inc.
Creating Binding E-Commerce
v: 250-479-8334, ext. 143  f: 250-479-3772
1-888-517-2675   http://www.PureEdge.com <http://www.pureedge.com/>

Received on Friday, 11 August 2000 16:44:35 UTC