- From: Per Bothner <per@bothner.com>
- Date: Tue, 21 Oct 2003 20:22:29 -0700
- 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