RE: Merged Copy

At 17:13 9/7/2000 -0700, John Boyer wrote:
Ok, I'll let other people way on the more substantive issues, but at the 
surface level only:

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

My point was I thought we didn't need the XSLT in our namespace at all, why 
the extra wrapping? It's an open content model. Ed had a request that we 
specify that if XSLT, the root should be <stylesheet>, but I don't recall if 
that we wanted to re-wrap again. (If Ed can correct me that'd be cool, I 
just want to make sure we aren't accidently flip-flopping.)

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

My editorial question relates to what is the "it". If it (a transform) only 
accepts octects, then if it received a node-set I'd expect the procedure 
call to have an argument type failure.

>Signature applications already know, in principle at least, how to convert
>node-sets to octet streams because C14N is required.

Ok, so the clarity I'm seeking is to say, X transform accepts only octects, 
if the Signature application has a node-set it will first have to 
(implicitly?) canonicalize prior to handing it to that transform.

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

Ok, curious for others' thoughts.


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

Well, If we don't here from Eve soon and we publish a new version, I'd 
prefer the spec reflect reality and state in the STATUS that we hope things 
will change.

_________________________________________________________
Joseph Reagle Jr.
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/People/Reagle/

Received on Thursday, 7 September 2000 20:41:01 UTC