- From: Frederick Hirsch <Frederick.Hirsch@nokia.com>
- Date: Mon, 1 Aug 2011 11:59:52 -0400
- To: ext Pratik Datta <pratik.datta@oracle.com>
- Cc: Frederick Hirsch <Frederick.Hirsch@nokia.com>, <public-xmlsec@w3.org>
- Message-Id: <A20E37C5-5D52-4A04-A8A5-E71C78DCD02E@nokia.com>
Thanks Pratik comments inline regards, Frederick Frederick Hirsch Nokia On Jul 29, 2011, at 8:00 PM, ext Pratik Datta wrote: > ACTION-810 > > > Issue 1) > 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 (seehttp://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". > We have been using term "XML Namespace URI" since version 1, and it is present in both XML Signature and XML encryption specs. If we decide to change it we should change it uniformly across all the specs. > > [fh] This is in the original 2002 REC, so it seems this change is not urgent. That said, I suggest we resolve this by adding a definition to Appendix A in XML Signature 2.0. XML namespace URI This refers to the namespace name [[XML-NAMES]]. > > Issue 2) > 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 > 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 > Only the context node is defined in this specification, other properties should be defined as well. > I agree. Let us add the following text to section "10.6.1.1 The dsig2:IncludedXPath Element", and also to the next section on ExcludedXPath. This text is copied from "Section B.7.3. XPath Filtering" with a slight change – no "here(): function. > [fh] I would suggest adding this material (what you have following) in 10.6.1 before "Processing of the selection and parameters is as follows:" There is already common material there I do not think we want to replicate this in two places. > Initialize an XPath evaluation context by setting > A context node equal to a node of the input node-set. > A context position, initialized to 1. > A context size, initialized to 1. > A library of functions equal to the core function set defined in [XPATH] , (The here() function defined is Xpath Filter is not applicable ) > 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. > > Issue 3) > 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. > This section is copied verbatim from XML Signature 1.0 section 7.3 http://www.w3.org/TR/xmldsig-core/#sec-NamespaceContext > I suggest we remove this section completely, because we only support exclusive canonicalization in 2.0, so this section is not applicable any more. > > [fh] I suggest instead that we move this section 11.3 to be under a new section B.8 Compatibility Mode Considerations I'm not sure xml:lang is incorrect in the context of the c14n discussion about copying declarations onto the node. > Issue 4) > > "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. > I don't agree with this. [fh] I don't agree either. > However there appears to be a problem with this section, (this has been there all along since XML Signature 1.0 > > 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". > > Now the string-value of a nodeset is defined as the string value of the first node. > So in this case the result is "hello" > But from the description it appears that expected value is "helloworld" not "hello" > > I suggest we change step 2) > > Currently it says > 2) taking the string-value of the node-set > > We should change it to > 2) sort the nodeset by document order, the concatenate the string value of each of the nodes into one long string. > [fh] I'm not sure #2 is wrong, but it certainly isn't clear. Isn't the result of step #1 in document order, and isn't the need to concatenate the strings, which is what #2 is trying to say? > 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 "name! space 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 s! tring. 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 Monday, 1 August 2011 16:08:40 UTC