- From: Joseph M. Reagle Jr. <reagle@w3.org>
- Date: 2000年9月07日 20:40:59 -0400
- To: "John Boyer" <jboyer@PureEdge.com>
- Cc: "IETF/W3C XML-DSig WG" <w3c-ietf-xmldsig@w3.org>
- Message-Id: <4.3.2.7.2.20000907203136.040b4ba0@rpcp.mit.edu>
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