- From: Grosso, Paul <pgrosso@ptc.com>
- Date: Tue, 6 Sep 2011 14:32:15 -0400
- To: "Pratik Datta" <pratik.datta@oracle.com>, <public-xmlsec@w3.org>, <jirka@kosek.cz>, <public-xml-core-wg@w3.org>
Pratik, Thank you for your response. The XML Core WG has a telcon scheduled for tomorrow, and the WG may discuss your resolutions at that time. Unfortunately, I will have to miss that telcon and will be offline for the next two weeks, so I hope you (and the XML Core WG) will excuse my individual response at this time. My only issue with the latest draft relates to Jirka's original comment on "11.3 Namespace Context and Portable Signatures" which is now at "B.8 Namespace Context and Portable Signature". The latest phrase reads: In addition, the Canonical XML and Canonical XML with Comments algorithms import all XML namespace attributes (such as xml:lang) from the nearest ancestor in which they are declared.... I would still object to the phrase "XML namespace attributes". You say: By "XML namespace attributes" we mean attributes that are in the "xml" namespace . e.g "xml:lang", "xml:space", "xml:id", "xml:base" etc. But that remains misleading. The phrase "XML namespace attributes" does not mean attributes in the xml namespace to most people. Most readers would, like Jirka and myself, assume "XML namespace attributes" referred to attribute-like constructs that declared XML namespaces. It would be better to avoid the phrase "XML namespace attributes" and be clear about what attributes are "imported". You might say "all attributes in the XML namespace (such as xml:lang)", though I wonder if you really want to "import" xml:id which would seem like the wrong thing to do, so I'm not really sure what you want to say here. But the current wording is problematic. As such, I would recommend that the XML Core WG not accept your current resolution of this issue. paul > -----Original Message----- > From: Pratik Datta [mailto:pratik.datta@oracle.com] > Sent: Tuesday, 2011 September 06 13:06 > To: Grosso, Paul; public-xmlsec@w3.org; jirka@kosek.cz; public-xml- > core-wg@w3.org > Subject: RE: FW: Last Call for XML Signature 2.0, Canonical XML 2.0 and > XML Signature Streaming Profile of XPath 1.0 > > Jirka, > > Thanks for your review. > > We have made the following changes to XML Signature Syntax and > Processing Version 2.0 after your review. > The latest draft version is here > http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-20/ > > > > ----------------------------------------------------------------- > > >>•Specification uses term "XML namespace URI" instead of "namespace > name" > >>Although this probably doesn't create confusion, such informal term > shouldn't > >>appear in W3C spec. Either proper term "namespace name" should be > used > >>(see http://www.w3.org/TR/xml-names/#dt-NSName) or at least "XML > namespace URI" > >> should be put into Appendix A - Definitions and be properly defined > here as a synonym of "namespace name". > > RESOLUTION: This is in the original 2002 REC, so it seems this change > is not urgent. That said, we have resolved this by adding a definition > to Appendix A in XML Signature 2.0. > > XML namespace URI > This refers to the namespace name [[XML-NAMES]]. > > > ----------------------------------------------------------------- > > > > >> * Insufficently defined context for XPath evaluation in § "10.6.1 > Selection of XML Documents or Fragments" > > > RESOLUTION: Added the following paragraph in section 10.6.1 Selection > of XML Documents or Fragments > > > Initialize the XPath evaluation context for the dsig2:IncludedXPath > element and the dsig2:ExcludedXPath as follows: > > A context node equal to the root of the document. > A context position, initialized to 1. > A context size, initialized to 1. > A library of functions equal to the function set defined in > [XMLDSIG-XPATH]. (Note: The XPath function here() defined in Xpath > Filter Transform must not be used in this context) > A set of variable bindings. No means for initializing these is > defined. Thus, the set of variable bindings used when evaluating the > XPath expression is empty, and use of a variable reference in the XPath > expression results in an error. > The set of namespace declarations in scope for the XPath > expression. > > > ----------------------------------------------------------------- > > > > >> * Typo in § "11.3 Namespace Context and Portable Signatures" > >> In addition, the Canonical XML and Canonical XML with Comments > >> algorithms import all XML namespace attributes (such as *xml:lang*) > from > >> the... > >> > >> There shouldn't be `xml:lang', but namespace declaration attribute > like `xmlns:foo'. > >> > >> Also using entity references in examples as content of namespace > >> declarations looks quite confusing. > > > RESOLUTION: There is no typo here. By "XML namespace attributes" we > mean attributes that are in the "xml" namespace . e.g "xml:lang", > "xml:space", "xml:id", "xml:base" etc. > > > > Also removed the entity references from namespace declaration and > instead used regular namespaces like this: > > <A xmlns:n1="http://foo.example"> > <B xmlns:n2="http://bar.example"> > <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> ... > <Reference URI="#signme"/> ... > </Signature> > <C ID="signme" xmlns="http://baz.example"/> > </B> > </A> > > > Also this whole section has now been moved to the compatibility section > "B.8 Namespace Context and Portable Signature" as it is not applicable > to canonical XML 2.0. Canonical XML 2.0 uses only exclusive > canonicalization so it is portable. > > ----------------------------------------------------------------- > > > >> * § "B.7.2 Base64" > >> Transformation as described assumes that operates on text node -- > >> otherwise it will always return empty string. I'm not sure whether > >> this is correct assumption. Omitting operation 1) will fix this > >> problem. > > > RESOLUTION: Changed the text slightly to mention these steps (step 2 > is changed) > > If an XPath node-set (or sufficiently functional alternative) is given > as input, then it is converted to an octet stream by performing > operations logically equivalent to > 1) applying an XPath transform with expression self::text(), then > 2) sorting the nodeset by document order, then concatenating the > string-value of each of the nodes into one long string. > > > This doesn't need to operate only on text nodes. Here is an example to > illustrate > > Suppose your XML looks like this <a><b>hello</b/><c>world</c></a> , > and you apply an XPath transform with "self:text()". Remember with > XPath transform, the xpath expression is evaluated repeatedly for every > node, and then only the nodes tha! t return true are considered. I.e. > the Xpath expression will be evaluated 5 times , > 1) <a> self:text() returns false > 2) <b> self:text() returns false > 3) hello self:text() returns true > 4) <c> self:text() returns false > 5) world self:text() returns true > so the filtered nodeset will have two nodes "hello" and "world". > > Taking the string value of each of these nodes in document order and > concatenating them returns "helloworld". > > ----------------------------------------------------------------- > > > This is related to my ACTION-830 > > > Pratik > > > > -----Original Message----- > From: Grosso, Paul [mailto:pgrosso@ptc.com] > Sent: Monday, June 06, 2011 12:08 PM > To: public-xmlsec@w3.org > Subject: FW: FW: Last Call for XML Signature 2.0, Canonical XML 2.0 and > XML Signature Streaming Profile of XPath 1.0 > > Forwarding from XML Core to XML Signature WG. > > paul > > -----Original Message----- > From: Jirka Kosek [mailto:jirka@kosek.cz] > Sent: Tuesday, 2011 May 31 4:03 > To: Grosso, Paul > Cc: public-xml-core-wg@w3.org > Subject: Re: FW: Last Call for XML Signature 2.0, Canonical XML 2.0 and > XML Signature Streaming Profile of XPath 1.0 > > On 27.4.2011 15:37, Grosso, Paul wrote: > > The XML Core WG has been asked to review these specs before the end > of > > May. Jirka and Norm have actions to do so and report back to the WG. > > Hi, > > I spent very limited time on this and haven't time to review RELAX NG > schemas at all. Below are few issues I have found. I'm also attaching > HTML rendering. > > Jirka > > 1 XML Signature Syntax and Processing Version 2.0 > -------------------------------------------------- > [http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-20/] > * Specification uses term "XML namespace URI" instead of "namespace > name" > Although this probably doesn't create confusion, such informal term > shouldn't appear in W3C spec. Either proper term "namespace name" > should be used (see [http://www.w3.org/TR/xml-names/#dt-NSName]) or > at > least "XML namespace URI" should be put into Appendix A - Definitions > and be properly defined here as a synonym of "namespace name". > * Insufficently defined context for XPath evaluation in § "10.6.1 > Selection of XML Documents or Fragments" > XPath 1.0 specification defines the following properties for context > ORG-BLOCKQUOTE-START > a node (the context node) > a pair of non-zero positive integers (the context position and the > context size) > a set of variable bindings > a function library > the set of namespace declarations in scope for the expression > ORG-BLOCKQUOTE-END > Only the context node is defined in this specification, other > properties should be defined as well. > * Typo in § "11.3 Namespace Context and Portable Signatures" > In addition, the Canonical XML and Canonical XML with Comments > algorithms import all XML namespace attributes (such as *xml:lang*) > from > the... > > There shouldn't be `xml:lang', but namespace declaration attribute > like `xmlns:foo'. > > Also using entity references in examples as content of namespace > declarations looks quite confusing. > * § "B.7.2 Base64" > Transformation as described assumes that operates on text node -- > otherwise it will always return empty string. I'm not sure whether > this is correct assumption. Omitting operation 1) will fix this > problem. > > 2 XML Signature Streaming Profile of XPath 1.0 > ----------------------------------------------- > [http://www.w3.org/2008/xmlsec/Drafts/xmldsig-xpath/] In general I > don't think it is good idea to create yet another XPath subset. > Proliferation of XPath subsetting prevents using standalone XPath > libraries when implementing various subsets of the language. If > streaming is necessary then effort should be derived from XSLT 3.0 > which provides streaming facilities. > > > > -- > ------------------------------------------------------------------ > Jirka Kosek e-mail: jirka@kosek.cz http://xmlguru.cz > ------------------------------------------------------------------ > Professional XML consulting and training services > DocBook customization, custom XSLT/XSL-FO document processing > ------------------------------------------------------------------ > OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 member > ------------------------------------------------------------------
Received on Tuesday, 6 September 2011 18:33:16 UTC