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

Re: namespace node implementation

From: Per Bothner <per@bothner.com>
Date: Tue, 21 Oct 2003 20:22:29 -0700
Message-ID: <3F95F7F5.4050405@bothner.com>
To: james anderson <james.anderson@setf.de>
Cc: www-ql@w3.org

james anderson wrote:

> at issue is when [mapping lexical QNames to QName valus]
> happens. much of the xquery documents is written 
> as if that point needs to be pushed back into the processor, even 
> though, from the cases given, names are in fact immutable and can be 
> reported as constants by the parser.

I've always read it that the names are resolved at parse-time.
That is certainly what I've implemented.

> constructed have not yet demonstrated that they need be constructed on 
> the basis of (prefix X prefix->namespace X localpart) combinations 
> rather than direct (namespace X localpart) combinations.

Note how the formal semantics defines how computed element constructors 
map string names to QName.  It uses a function fn:QName-in-context.
Note that how that function is nowhere defined ...

Unfortunately, XQuery has a few places like that where the compiler 
needs to carry the compile-time namespace bindings through to the 
runtime.  It looks like this area of XQuery is still unsettled.


>> First-class names don't "use the ns1 prefix", but you need to be able 

> the difficulty with an approach which seeks to afford the 
> prefix-namespace bindings indefinite extent, is that it is hard to 
> understand how it should operate with situations like
> ...
> $E
> ? (rotatef (first (children (second (children $e))))
>          (first (children (fourth (children $e)))))
> NIL
> ? (push (first (attributes (second (children $e))))
>       (attributes (fourth (children $e))))

I'm not concerned about modifying nodes in-place, since that isn't 
possible in XQuery, at least untl somebody defines update semantics for 
XQuery.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/
Received on Tuesday, 21 October 2003 23:22:30 UTC

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