RE: Merged Copy

Hi Joseph,

1. In 4.3.3.1 I thought we said we didn't need the extra XSLT element,
instead a proper <stylesheet> element should be included? (Though I honestly
don't remember so I made the change and rewrapped it).

<john>
Actually, we've been going after the idea that any defined transforms
include 'parameter' elements that are defined within our namespace.  The
contents of those parameters is what is up in the air.
The content model for Transform is XPath, XSLT, or any sequence of elements.
The last part is only there to accommodate Transforms not defined by us.  I
have no problem saying that the content model for Transform is (XPath |
XSLT) because I don't really see why people would do non-standard
transforms.  If more transforms are required, then we should be collecting
those ideas and doing a rev to the spec at some later time.
Anyway, these thoughts are in addition to the fact that the XSLT content
MUST be an xsl:stylesheet (or equivalently an xsl:transform).
</john>

2. I'm less than comfortable with the Base64 [2] and Minimal [3] changes as
it adds a lot of text and introduces confusion with respect XPath and
comments. These are supposed to be the _simple_ transforms.
a. Minimal: "This algorithm requires as input the octet stream of the
resource to be processed. However, the actual input to this algorithm may be
an XPath node-set (or a sufficiently functional replacement implemented by
the application). " I don't understand, does it take octects only or not?
Are you saying a Signature application can (or MUST) convert nodesets to
octects?

<john>
The processing model is that the input can be octets or a node-set.
However, the transform only accepts octets, so if it gets a node-set, it has
to convert the node-set to octets.
Signature applications already know, in principle at least, how to convert
node-sets to octet streams because C14N is required.
</john>

b. Base64: Again, the algorithm takes octects. If nodesets are present, who
is doing the converting? Should it be restated to say, "If a Signature
Application has a nodeset and wishes to base64 its encoding it must first
..." And now we have the Base64 doing XML processing by stripping away start
and end tags! I'd like to keep this transform clean and simple.

<john>
Actually, it is simpler.
Again, b64 wants octets.  If it gets a node-set, then obviously we have to
convert to octets.  However, consider the most typical usage case for
someone wanting to use this transform.  They have an element identified by
id as "CompanyLogo", which contains a base-64 encoding of an image in the
element's content.  They *want* to say

<Reference URI="#CompanyLogo">
	<Transforms>
		<Transform algorithm="&base64;"/>
	</Transforms>
</Reference>

But they can't because the result of the URI includes the start and end tags
of the company logo element.  Instead, they have to throw in an XPath
transform to dig the text out of the element, as follows:
</john>

<Reference URI="#CompanyLogo">
	<Transforms>
		<Transform algorithm="&xpath;">
			<XPath>self::text()</XPath>
		</Transform>
		<Transform algorithm="&base64;"/>
	</Transforms>
</Reference>

The XPath is run against every node in the node-set result of the URI, and
it chooses just the text nodes.

I think the former is simpler and more natural.
</john>

I'm not sure what the solution is, but if other people would like to keep
these simple, we can give it more thought.

3. I'm not sure if the 6th and 7th motivating paragraphs in the XPath
section aren't needed. "The primary purpose ..." I'd propose to strike them.

<john>
Many have felt and I still feel it is necessary for people to know why this
transform exists.  It is important that we not try to shorten the spec so
much that noone understands why we are doing what we are doing.  This is a
major problem in other specs.
</john>

4. XPath section, has (old) text that says, "The function definition for
here() is consistent with its definition in XPointer. It is defined as
follows:" However, this isn't the case, right?

<john>
It may not be the case at the moment, but I fully expect it will be the case
again soon.  Once the Xptr folks actually do discuss this, I'm sure they
will find there is no reasonable alternative.  If they do go in a direction
other than ours, we can change the text at that time to say "Note that it is
NOT the same as the XPointer here()".
</john>

Received on Thursday, 7 September 2000 20:13:24 UTC