- From: <bugzilla@wiggum.w3.org>
- Date: Wed, 16 Jan 2008 08:46:16 +0000
- To: public-qt-comments@w3.org
- CC:
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 UTC