Tweaked New attachment, was RE: Proposed processing model for Reference and Transforms

Hi Gregor,

You're absolutely right.  In a burst of youthful exuberance, I wrote that--
before I realized we actually needed to be pushing full node-sets through
the transform sequence.

I have attached a new copy of the "editors' copy" with this fixed.  The
change to base-64 is not large, and it is marked in brown (with strikeout in
grey).

Actually, your email has been doubly helpful in refocusing my attention on
this transform because I think it now addresses something that would've been
an interoperability issue.  As currently specified, it is clear that
comments and processing instructions should also be removed should they
appear.  This imposes some additional work on implementers because you can't
just obtain the stuff between the start and end tags and assume can be
passed directly to a base-64 decoder.  It has to remove all comments and PIs
as well as all start and end tags appearing within the content.

It was my original intention to satisfy what I believe is everyone's
preference that use of the base-64 transform should not REQUIRE a preceding
XPath transform to isolate the text node from its parent element, but the
expression self::text() does a lot more work than handle the base case of
one element with a single text node inside.  On the one hand, the WG may
feel this is too much for this transform, but I think it will be challenging
to  define formally what we mean (i.e. to write an XPath expression that
just shaves the outermost element tags).

Thanks for your careful attention to the proposed changes :).

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



-----Original Message-----
From: Gregor Karlinger [mailto:gregor.karlinger@iaik.at]
Sent: Friday, August 25, 2000 7:37 AM
To: John Boyer; TAMURA Kent; Gregor. Karlinger@Iaik. At; Joseph Reagle;
Ed Simon
Cc: XML DSig; jboyer@csr.csc.UVic.CA
Subject: AW: Proposed processing model for Reference and Transforms


Hello John,

I think there is a problem with the new text for the base64 transform
(section 6.6.2):

It says: "... If an XPath node-set (or sufficiently functional alternative)
is
given as input, then it is converted to an octet stream by taking the
string-value of the node-set ..."

According to XPath, the text value for an element node is the concatenation
of
all text node values it bears. The text value for a text node is its
character
data. Consider following simple example:

  <Element>Text</Element>

If I generate the octet stream according to the new proposal, I think I
would
get:

  TextText

since there are two nodes in the input node set, namely the element and the
single text node it bears.

I remember that we had the same problem with the specification of the
serialization
result in Canonical XML. Maybe some additional text should be added here to
make it
clear how the conversion to an octet stream should actually behave.

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