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

Re: namespace node implementation

From: james anderson <james.anderson@setf.de>
Date: Wed, 22 Oct 2003 23:20:14 +0200
To: www-ql@w3.org
Message-Id: <8721FC80-04D5-11D8-96EF-000393BB8814@setf.de>

On Wednesday, Oct 22, 2003, at 20:22 Europe/Berlin, Per Bothner wrote:

> Kay, Michael wrote:
>> I haven't yet implemented the new construction rules: when you add an 
>> element to a new parent in Saxon today, it will inherit the 
>> namespaces of its new parent, which is incorrect according to the 
>> spec.
if saxon is using the name representation described in the earlier 
message, the apparent namespaces at the time when the parent was parsed 
cannot affect the correctness of the model produced by this operation. 
neither the bindings apparent when the expressions were parsed nor 
those when the expressions were compiled.

> 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)?  It could be:

it does not matter what get-in-scope-naemspaces returns.

? (defparameter $a (root (parse-document "<a xmlns:ns1='NS1'><b 
? (defParameter $c (root (parse-document "<c xmlns:ns2='NS2'></c>")))
? (setf (children $c) (children $a))
(#<ELEM-NODE ||::\b 2 #x1693E16>)
? (write-node $c *trace-output*)
<c xmlns:ns2='NS2'><b ns1:x='X' xmlns:ns1='NS1' /></c>
#<ELEM-NODE ||::\c 1 #x169979E>

with the appropriate model for names, it is possible to produce a 
correct result document without any "in-scope namespaces."

Received on Wednesday, 22 October 2003 17:20:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:43:43 UTC