W3C home > Mailing lists > Public > public-qt-comments@w3.org > January 2008

[Bug 5224] [XQuery] Dynamic context in global variable initializers

From: <bugzilla@wiggum.w3.org>
Date: Wed, 16 Jan 2008 08:46:16 +0000
CC:
To: public-qt-comments@w3.org
Message-Id: <E1JF3ua-0002W6-QP@wiggum.w3.org>

http://www.w3.org/Bugs/Public/show_bug.cgi?id=5224





------- Comment #6 from mike@saxonica.com  2008-01-16 08:46 -------
> MK: It seems that the WG has decided that these are defined,
> MD: Not necessarily. 

I don't actually know what the WG decided - I've only got the minutes to go by.
One option was clearly that the dynamic context in a variable initializer
should be the same as that in a function body - explicitly undefined[*]. I got
the impression that the WG decided firmly against that. That's really what I
meant by saying the WG had decided that the focus is "defined".

If the focus is not explicitly undefined, then I think it should be the same as
for the QueryBody in the main module. I can't see any sense in making it
different in different modules - it would complicate the API immensely. (I
could see some logic in saying that the focus is explicitly undefined for
variable initializers in library modules: that could prevent some subtle bugs.) 

This means of course that if the focus is undefined in the QueryBody then it is
undefined in variable initializers. Also, of course, I'm talking about the
focus for the variable initializer as a whole - it can change within
subexpressions in the usual way.

Option declarations are allowed to do anything they like; you can define an
option declaration that makes 2+2=5. So I don't think we need to worry too much
about that case.

Incidentally, in XSLT the context item in a global variable declaration is the
node at the root of the tree that contains the initial context item of the
transformation. A curious rule: IIRC we did it for compatibility with an MSXML
behaviour that had been emulated by several other XSLT 1.0 processors.

[*] for avoidance of doubt, by "explicitly undefined" I mean "defined to have
no value", whereas "undefined" could be read as "not defined by this
specification".
Received on Wednesday, 16 January 2008 08:46:20 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 March 2012 18:14:49 GMT