W3C home > Mailing lists > Public > www-ql@w3.org > October to December 2003

Re: namespace node implementation

From: Xavier Franc <xfranc@online.fr>
Date: Fri, 24 Oct 2003 14:47:26 +0200
Message-ID: <3F991F5E.2020206@online.fr>
To: www-ql@w3.org


I don't understand this:
(from M. Kay's message http://lists.w3.org/Archives/Public/www-ql/2003OctDec/0043.html)

>> Right, and that's the problem I'm concerned about (assuming we're
>> talking about the same thing).  Given:
>>
>> let $a := <a xmlns:ns1="NS1"><b ns1:x="X"/></a>
>> let $c := <c xmlsns:ns2="NS2">{$a/b}</c>
>>
>> what is the result of get-in-scope-namespaces($c/b)?
>
> When <b> is constructed it acquires a namespace node for ns1 by virtue of
> the fact that ns1 is an active in-scope namespace at that point.
>
> When <a> is constructed it also acquires a namespace node for ns1 for the
> same reason.
>
> When <b> is copied to make it a child of <a> it retains (copies of) its
> namespace nodes.
>
> The path expression $a/b selects this b element. The element is copied to
> make it a child of the new <c> element. It retains the ns1 namespace node,
> but does not acquire a namesapce node for ns2.
>
...
> but the more accurate XML 1.1 serialization is:
>  <c xmlns:ns2="NS2"><b xmlns:ns2="" xmlns:ns1="NS1" ns1:x="X"/></c>


What is the meaning of "[it] does not acquire a namesapce node for ns2." ?
First, what is "it" ? the first node $a/b or the new node $c/b ?
(I assume it is the latter)

Why should the new node ($c/b) _not_ have NS2 in its "in-scope namespaces" ?
[BTW the definition of "in-scope namespaces" is far from clear.]

I don't see in the spec something that would prescribe such a strange rule:
could you please Michael point it out ?
The argument "serialization should roundtrip" seems not sufficient, because
what matters is that element and attribute names get their proper NS, and
there are different ways to serialize to get this result.

-- 
Xavier FRANC
Received on Friday, 24 October 2003 08:46:15 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:17:16 UTC