RE: C14n and inherited namespaces (again) (sorry)

Hi all,

Nothing to be sorry about.  In the new version of the c14n spec, I have
taken the liberty of changing the way namespaces are handled.  As a result,
the messages signed by forthcoming signatures will be different than ones
generated in the past.  However, there are VERY good reasons for making this
change (including yours), and my perception is that most if not all WG
members will prefer the results.

The change is that, rather than simply writing the full namespace context of
each element in its start tag, we need to eliminate superfluous namespace
declarations.  I apologize for the inconvenience of this change, but I
believe it will not seriously impact implementations.  For anyone doing the
current c14n by ANY mechanism (including SAX), this change should amount to
less than a page of code.

When processing an element, we will only add those namespace declarations
that differ from the setting in the parent element.  For a SAX
implementation, you will have to keep an auxiliary stack whose top contains
the parent element's settings so that when you are notified of the namespace
of the current element, you can have something to compare against (after
which you would push the current node as the new top of stack).  Note that
for document subsetting, one has to go up to the nearest ancestor that is in
the node-set, but for canonicalizing a whole document, that's always the
parent.

Given that the current formulation is verbose but technically correct, why
do this?

1) For starters, xmlns="" shows up in every element for which no default
namespace is declared.  There's nothing technically wrong with this, but the
examples look broken and are harder to explain.  It is particularly hard
when the originating application may not even care about or really be using
namespaces.  Consider the impact on an app that uses a validating processor
but not namespaces.  To use the canonical form, we would like to say they
should simply slap the DTD back onto the front of it.  But we can't because
xmlns would have to be added to the ATTLIST of every element.  This is
unacceptable when it is so easy to fix c14n before it goes to candidate rec.

2) For elimination of superfluous declared namespaces, it was something of a
consistency measure.  It seemed wrong to get rid of extra xmlns="" but not
get rid of extra declared namespaces, esp. when one realizes that it can be
done with the same solution that solves the xmlns="" problem.  In addition
to the consistency, it also makes the examples in the spec much more
readable.

I will be posting the new spec today after I do a few more editorial tweaks.
And, by the way, although the document is massively improved in structure
and explanation, this is THE ONLY CHANGE to the expected output of the
algorithm.

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 merlin
Sent: Wednesday, August 30, 2000 10:46 AM
To: John Boyer; XML DSig
Subject: Re: C14n and inherited namespaces (again) (sorry)



Not to keep dragging this out.. This is trivial, but of
minor importance for interop where XPaths are involved.
Most should ignore it.

Elements mystically inherit namespace attributes from their
ancestors. In no implementation that I have seen, however,
is there a physical representation of these attributes.

In other words, if you query a node for a namespace prefix,
you'll get the nearest inherited value. But if you look at
the attributes of the element (getAttributes()), they're
not there.

As a result, inherited namespace attributes cannot be part
of a node set because there is no physical entity that can
be placed in a set. Or are we expected to create a physical
representation ourselves if our underlying toolkits do not?

In particular, if I start out with:

 <Foo xmlns:bar='baz'><Bar /></Foo>

Then when I start processing, as far as XPath is concerned
this is equal to:

  <Foo xmlns:bar='baz'><Bar xmlns:bar='baz' /></Foo>

I use the following xpath:

  . namespace::* *

The result is:

  <Foo xmlns:bar='baz'><Bar /></Foo>

This is the same as my original document. When I go to C14n
or XPath again, does the inherited attribute reappear, just as
when I went to XPath originally?

Or to start out, should I have physically created all inherited
namespace nodes? Or is this an XPath question.

And again, I apologize for the entropy.

Merlin
--
I will think before I ^X^S/:wq.

r/merlin@baltimore.ie/2000.08.30/18:16:28
>
>I understand now.
>
>All elements do actually contain the inherited namespace nodes
>within their namespace axis. I just failed to understand this.
>
>Apologies.
>
>Merlin
>
>r/merlin@baltimore.ie/2000.08.30/18:09:29
>
>>I think my brain is on vacation at the moment. Or maybe this has been
>>addressed and fixed in the working copy of this document. Or brought
>>up before and solved. But...

Received on Thursday, 31 August 2000 12:44:34 UTC