XPath serialization RE: Enveloped signatures

Based on your comments below, it is clear that we will have to tweak the
XPath serialization description.  The problem is that your sample output for
the XPath serialization is not what was intended.  The sample output you
show for c14n is the output I expect to see from Xpath serialization.

The section is called XPath 'filtering' because we view the XML document as
a single tree.  The mental model is that of performing a standard, ordinary
depth first tree traversal, rendering only those nodes that are in the
node-set.  We are trying to regenerate the actual document minus the parts
that are excluded by the XPath expression.  Your implementation duplicates
the subtrees in each tree of the forest and generally creates an enormous
result.

Obviously, I will have to make some changes so that this is clear, but
obviously agree on how the XPath serialization should generate most of its
output.  The serialization algorithm is quite similar to c14n, except in the
following ways:

1) The XPath serializer assumes a forest, so it handles fragmentary XML
documents.
2) The XPath serializer doesn't rewrite namespaces.
3) The XPath serializer doesn't do character model normalization.

Furthermore, the XML core WG just dropped C14N.  Since we need it to be
finished, they've handed it off to us, and we have the ability to change it
as necessary so that we finish.  When we are finished, there will be no
difference between c14n and XPath serialization, although I predict that
your current c14n code will be obsoleted.  Specifically, namespace rewriting
and character model normalization will be eliminated.

John Boyer
Software Development Manager
PureEdge Solutions Inc. (formerly UWI.Com)
Creating Binding E-Commerce
jboyer@PureEdge.com



-----Original Message-----
From: w3c-ietf-xmldsig-request@w3.org
[mailto:w3c-ietf-xmldsig-request@w3.org]On Behalf Of Petteri Stenius
Sent: Monday, May 15, 2000 12:16 PM
To: 'John Boyer'
Cc: IETF/W3C XML-DSig WG (E-mail)
Subject: RE: Enveloped signatures




I think it would be good if the XPath serialization and c14n were closer to
each other, or even equal!


I'm not saying I need a c14n after a XPath transform, I'm saying that the
whole process of doing an XPath transform is not possible in one pass.

A simple example should clarify:

<A>
	<B>text</B>
	<Signature Id="S1">
	</Signature>
</A>

The result node-set from the XPath expression for excluding the Signature
element is a list with the nodes:

A
B
text

The serialized output from the XPath expression is:

<A><B>text</B></A><B>text</B>text

Output from the combination of exclude-signature transform + C14N
serialization is simply:

<A><B>text</B></A>


Petteri


> -----Original Message-----
> From: John Boyer [mailto:jboyer@PureEdge.com]
> Sent: Thursday, May 11, 2000 10:17 PM
> To: Petteri Stenius; 'Joseph M. Reagle Jr.'
> Cc: IETF/W3C XML-DSig WG (E-mail)
> Subject: RE: Enveloped signatures
>
>
> I would be interested in knowing exactly why you feel you
> need c14n after an
> XPath transform.  After running the XPath expression, the result of
> serialization is quite similar to c14n in most respects and
> was written so
> that there would be no output ambiguities that did not result
> from changing
> the input document.  You should not need c14n, so one pass should be
> sufficient.
>
> Moreover, it seems that we are inheriting the c14n spec, and the two
> principal differences between the XPath serialization and
> c14n, which are
> namespace normalization and composed character normalization,
> are quite
> likely to be deleted (for reasons that will be discussed
> later).  Assuming
> this is true, though, means that the XPath serialization
> will, in essence,
> be equal to c14n.
>
> Thus, the only area of awkwardness that we are trying to
> overcome is the
> 'political' awkwardness of having applications provide support for a
> specific XPath exclusion transform without providing full
> XPath support.
>
> I don't mind if we want to do this, but the WG has avoided
> doing this in the
> past because it has, up to now, meant that we would have to repeat the
> definition of 'how to write' the result.  It's one thing to
> say 'I just want
> to exclude the Signature being created while calculating this
> DigestValue'
> but it's another thing entirely to recognize that you must
> still create a
> byte stream that can be digested.
>
> In other words, the enveloped-signature-transform still needs
> something like
> the XPath serialization to fit our current processing model.
>
> John Boyer
> Software Development Manager
> PureEdge Solutions Inc. (formerly UWI.Com)
> Creating Binding E-Commerce
> jboyer@PureEdge.com
>

Received on Monday, 15 May 2000 16:13:33 UTC