W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > July to September 2000

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

From: merlin <merlin@baltimore.ie>
Date: Wed, 30 Aug 2000 18:46:29 +0100
Message-Id: <200008301746.SAA12693@cougar.baltimore.ie>
To: "John Boyer" <jboyer@PureEdge.com>, "XML DSig" <w3c-ietf-xmldsig@w3.org>

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 Wednesday, 30 August 2000 13:47:08 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.29 : Thursday, 13 January 2005 12:10:11 GMT