RE: C14n and Default namespace

Hi Gregor,

If a parent has a non-empty default namespace declaration, and the child
does not actually have xmlns="" declared, then the XPath data model creates
a non-empty default namespace node *in the child*.

In other words, the full namespace context of an element (e.g. the child) is
represented in the namespace axis of the element.

However, an empty default namespace is represented as the absence of a node
with local name xmlns and empty URI.  We can't tell whether the element
source explicitly declared xmlns="" or inherited it from an ancestor.

To solve this problem, I've simply said that when there is no default
namespace node (empty URI, local name of xmlns), then I will output
xmlns="".  This ensures there is no ambiguity (a good thing for c14n), but
it adds a lot of xmlns="" to the document.  So, although there is no
criticality in this issue, if the WG would prefer to have more intelligence
w.r.t. handling the default namespace AND if the implementers indicate it is
easy to do so, then I am amenable to a change.

Thanks,
John Boyer
Development Team Leader,
Distributed Processing and XML
PureEdge Solutions Inc.
Creating Binding E-Commerce
v: 250-479-8334, ext. 143  f: 250-479-3772
1-888-517-2675   http://www.PureEdge.com <http://www.pureedge.com/>



-----Original Message-----
From: w3c-ietf-xmldsig-request@w3.org
[mailto:w3c-ietf-xmldsig-request@w3.org]On Behalf Of Gregor Karlinger
Sent: Tuesday, August 29, 2000 12:24 AM
To: John Boyer; XML DSig
Subject: AW: C14n and Default namespace


Hi John,

> If there is no default namespace node, then
>   if the parent is omitted from the node-set or if the parent's
>   default namespace is non-empty, then generate an xmlns=""

If the parent's default namespace is non-empty, shouldn't this
namespace be propagated to the child?

Regards, Gregor
---------------------------------------------------------------
Gregor Karlinger
mailto://gregor.karlinger@iaik.at
http://www.iaik.at
Phone +43 316 873 5541
Institute for Applied Information Processing and Communications
Austria
---------------------------------------------------------------

Received on Tuesday, 29 August 2000 13:33:20 UTC