RE: Merged Copy

Hi Joseph,

The conversation thread for this goes all the way back to [1,2,3].

[1]
http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/1999OctDec/0219.html
[2]
http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/1999OctDec/0222.html
[3]
http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/1999OctDec/0224.html
[4]
http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/1999OctDec/0228.html

As you may recall, I was a proponent of open content, but you and Don
preferred to wrap everything in parameter tags of some kind.  The decision
to go this route was finalized in DC (see [5] for minutes) as follows:

"Eastlake: There are various types of algorithms ... there is consensus that
parameters should be labeled for algorithms ... "

[5] http://www.w3.org/Signature/Minutes/DC-Minutes/Overview.html

The following arguments were subsequently made by Don at the DC face to
face.

a) Wrapping each parameter in an element allows us to say things about the
content that we may not be allowed to say about the content according to the
content model.  This is certainly true of XPath, where the extra element
gives us a convenient place to put the namespace declarations that the
expression may need (can't be done at the Transform level because transform
has an ATTLIST, so every possible namespace declaration would have to be
declared in the ATTLIST, which is unusable).

b) We achieve consistency in how parameters are expressed, regardless of how
many parameters there may be.  It doesn't make sense to say that
multi-parameter transform would have element wrappers around each parameter
whereas a single parameter transform should have open content.

I basically conceded the wisdom of these points, and life went on.  So,
requiring the XSLT element wrapper now is not a flip-flop.  It's how the WG
decided to do it last year.

Thanks,
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: w3c-ietf-xmldsig-request@w3.org
[mailto:w3c-ietf-xmldsig-request@w3.org]On Behalf Of Joseph M. Reagle
Jr.
Sent: Thursday, September 07, 2000 5:41 PM
To: John Boyer
Cc: IETF/W3C XML-DSig WG
Subject: 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 Friday, 8 September 2000 16:18:11 UTC