Relative namespace URIs in C14N

DSig folks--

Jonathan Marsh (, one of our XML gurus) has brought to
my attention a proposal before the XML Plenary that, if it passes, would
require some changes in C14N.  Specifically, the Plenary is proposing to
deprecate use of relative URIs in namespace declarations (things like
'xmlns:foo="../bar"').  The net result is that operations involving relative
namespace URIs will be unspecified and thus have implementation-specific
behavior, which obviously isn't a good thing for canonicalization.  Jonathan
kindly provided the following analysis of what this means for C14N and the
XPath data model:

Subject: Plenary relative namespace URI decision impacts on C14N

The "undefined/deprecated" proposal [1] being voted on by the XML Plenary
appears likely to pass.  If so, treatment of relative URIs in namespaces
will be officially "undefined" by W3C specs and an erratum to XPath will
likely be issued to un-define the mandatory absolutization of relative
namespace URIs.  This affects canonicalization, which is built upon the
XPath data model.

Implementation-specific canonicalization is a self-evident contradiction,
and steps must be taken to ensure that implementation-specific behavior is
not surfaced in the canonicalized output.

The section entitled "Canonical XML Data Model" [2] contains this text:

  An element E has namespace nodes that represent its namespace 
  declarations, any namespace declarations made by its ancestor 
  that have not been overridden in E's declaration, the default 
  namespace if it is non-empty, and the declaration of the 
  prefix xml. The XPath data model expects the XML processor to 
  convert relative URIs to absolute URIs.

The last sentence will become false with the XPath erratum, and should be

The section entitled "Document Order for Canonical XML" [3] contains this

  An element's attribute nodes are sorted lexicographically 
  with namespace URI as the primary key and local name as the 
  secondary key (an empty namespace URI is lexicographically 

This is a case of comparing namespace URIs (although it is used for sorting
instead of identity), which is impacted by the "undefined/deprecated"
proposal.  With the upcoming XPath erratum, this will result in an
implementation-specific order when relative namespace URIs appear.  There
appears to be an easy solution to this case - sort by QName instead.

The section entitled "Generation of Canonical XML" [4] contains this text:

  Namespace and Attribute Nodes- a space, the node's QName, an 
  equals sign, an open double quote, the modified string value, 
  and a close double quote. The string value of the node is 
  modified by replacing all ampersands (&) with &, all open 
  angle brackets (<) with &lt;, all double quote characters 
  with &quot;, and the whitespace characters #x9, #xA, and #xD, 
  with character references. The character references are 
  written in uppercase hexadecimal with no leading zeroes 
  (for example, #xD is represented by the character reference

With the upcoming XPath erratum, the string-value of a namespace node for
relative URIs will be implementation specific.  To avoid this issue, the raw
value of the namespace declaration could be used, but there is no way in
XPath to get the raw value of the namespace declaration.  A solution may be
for C14N to augment the XPath data model to provide these raw values.



Thoughts?  I don't have any problems sorting by QName (that's a pretty easy
change to make), but I can't really speak to the third issue involving
augmenting the XPath data model to get at raw namespace declarations.  John,
any insight here?


Received on Thursday, 24 August 2000 11:42:36 UTC