W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > January to March 2002

Re: Notes on xml-exc-c14n rev 1.21

From: Joseph Reagle <reagle@w3.org>
Date: Thu, 10 Jan 2002 15:17:54 -0500
Message-Id: <200201102018.PAA19412@tux.w3.org>
To: "John Boyer" <JBoyer@PureEdge.com>, "Thomas Maslen" <tmaslen@wedgetail.com>, <w3c-ietf-xmldsig@w3.org>
On Thursday 10 January 2002 13:22, John Boyer wrote:
> <jb>
> Confirmed.  Proposed new text:
> The namespace axis of an element contains nodes for all non-default
> namespace declarations made within the element as well as non-default
> namespace declarations inherited from ancestors of the element. The
> namespace axis also contains a node representing the default namespace
> if it is not the empty string, whether the default namespace was
> declared within the element or by an ancestor of the element.  Any
> subset of the nodes in a namespace axis can be included in a document
> subset.
> </jb>


> <jb>
> Some of the parts of Section 3 don't sound quite right:
> 1) The third exception says "For every namespace node with a prefix that
> does not appear in the InclusiveNamespacePrefix List, a namespace
> declaration is output at every output element where that prefix is
> visibly utilized and that prefix and its value is not already in an
> output ancestor."  Shouldn't it be the case that the *nearest* output
> ancestor has to have the same value?

Fixed,  "...a namespace declaration is output at every output element where 
that prefix is visibly utilized and that prefix and its value does not 
appear in the nearest output ancestor with the same prefix."

> 2) In implementation note 3.2, shouldn't it say that when the recursion
> returns, then the namepsace nodes should be popped from the stack?
> Otherwise, doesn't an element get interference from the namespaces at
> play by the last processed descendant of the element's preceding
> sibling?

Oops, yes. Fixed: "3. After the recursion returns, pop the state stack."

> 3) In the Note after the implementation method, it says that "many XPath
> implementations do not distinguish namespace nodes from attribute
> nodes."  This is actually an incorrect implementation of XPath.  The
> next sentence should start with something other than "This is
> necessary..." such as "It is necessary to distinguish namespace nodes
> from attribute nodes because ... [same ending]".

Agreed. A careless edit since I was trying to accomodate Thomas' request 
that we repeat the point that a XPath namespace node includes all of its 
ancestor declarations as well: "n [XPath] an element's namespace axis is 
distinct from attribute nodes and it contains all the namespace 
declarations from its ancestors. For non-conformant implementations 
additional processing and stacks are required to separate a namespace node 
list from the attribute node list and keep a stack of a list of namespace 
nodes in effect for one's parent.)...


Joseph Reagle Jr.                 http://www.w3.org/People/Reagle/
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/Signature/
W3C XML Encryption Chair          http://www.w3.org/Encryption/2001/
Received on Thursday, 10 January 2002 15:18:21 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:21:37 UTC