AW: Proposed processing model for Reference and Transforms

Hi John,

please see my comments below.

2) Removed requirement for barename XPointer support from external
resources.  We nevery really had this support, we just really haven't
acknowledged it before.  Also, I glommed onto the definition of
same-document reference from RFC2396 as the way to distinguish when we do
require barename XPointer support.  Same-document reference covers the null
URI plus URIs that essentially start with a #.

<Gregor>
This is fine, I also interpreted the draft in this way.
</Gregor>


3) Added idea that same-document URIs in the Reference would result in a
location-set, then defined how to boil the location-set down to an XPath
node-set (which is pretty easy considering an XPointer location set is a
node-set except for the addition of point and range ndoes).  BTW, the new
text is careful to say 'XPath node-set (or sufficiently functional
alternative)' or words to that effect throughout the document.

<Gregor>
As Kent I cannot see a good reason for introducing XPointer features for
same-document URIs. Why should they result in a location-set, if they are
then converted into a XPath node-set again.

I suggest to do the following:

* If the same-document URI is null, then the result of dereferencing the URI
is a XPath node-set covering all nodes of the document, in which the
signature is embedded.

* If the same-document URI is a reference (i. e. "#xxxx"), the reference
part (i. e. "xxxx") is interpreted as a the value of a XPath id-expression,
i. e. the XPath node-set as computed for a null URI forms the input for an
XPath transform "id(xxxx)".
</Gregor>

7) Changed XPath so that it iterates on all nodes in a full node-set rather
than simply setting the context node to be the document root.  This was
necessary to the new transform processing model because the output is
expected to be a full node-set (minus a few carefully omitted elements), so
XPaths chained together (or an XPath after an enveloped signature transform)
needed to take full node-sets as input.  However, the result is quite lovely
in that the required XPath expressions are simpler and almost always
identical to the expressions one would write for an XSLT template match.

<Gregor>
In your proposal you write that the result of applying the XPath expression
is converted into a boolean. How can this be achieved?
</Gregor>

 8) I now distinguish between Canonical XML and Canonical XML with Comments.
This was really quite necessary to get everything to work and keep all of
the features we used to have.  Canonical XML with Comments is recommended,
not required.  As well, it seemed like it wouldn't hurt anything because
Minimal canonicalization would be quite difficult if comments had to be
omitted.

<Gregor>
Why do you think is this necessary? The proposal reads quite complicated due
to this distinction.
</Gregor>

 Regards, Gregor
---------------------------------------------------------------
Gregor Karlinger
mailto://gregor.karlinger@iaik.at
http://www.iaik.at
Phone +43 316 873 5541
Institute for Applied Information Processing and Communications
Austria
---------------------------------------------------------------