- From: <bugzilla@jessica.w3.org>
- Date: Wed, 11 Nov 2015 18:22:29 +0000
- To: public-qt-comments@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=4378 --- Comment #33 from Josh Spiegel <josh.spiegel@oracle.com> --- Sounds more like a "WONTFIX" to me but I had to leave early and wasn't there for the decision. In any case, I am including the minutes from the previous meetings below. Here are the minutes from meeting 622: §§ Action A-620-01 has been completed, so this is up for discussion. §§ JR reported that he has done essentially what is described in comment §§ 14 of bug 4378. The text of 4.18 Function Declaration now reads in §§ part: §§ [Definition: User defined functions are functions that contain a §§ function body, which provides the implementation of the function §§ as an XQuery expression.] The static context for a function body §§ includes all functions, variables, and namespaces that are §§ declared or imported anywhere in the Prolog, including the §§ function being declared. Its in-scope variables component also §§ includes the parameters of the function being declared. However, §§ its context item static type component is absentDM31, and an §§ implementation should raise a static error [err:XPST0008] if an §§ expression depends on the context item. §§ We discussed at some length. §§ Among the points raised: §§ - MD suggested that "if an expression depends on the context item" §§ was a bit fuzzy as regards the phrase "an expression". §§ - MK suggested the "depends on the context item" also leaves a §§ great deal of work to the reader. §§ - TM argued that the correct error to raise here is a type error. §§ He has found some places where we talk about an item's typed value §§ being absent, but not (so far) places where we talk about its §§ type annotation being absent. §§ - TM suggested that changing 2.2.3.1 Static Analysis Phase of XQuery §§ might do the job; others were inclined to agree. §§ It was felt that we needed a fuller discussion of the issues involved, §§ in email. AC suggested that the right way to launch such a discussion §§ was with a concrete proposal. §§ ACTION A-622-05: MK to propose a resolution to bug 4378 "error in §§ K2-NodeTest-21" (dependency of function bodies on context item). Here are the minutes from meeting 623: §§ There was a lot more discussion (almost an hour), but we didn't make great progress. §§ There seems some level of consensus: (a) we all want to be allowed to raise a static error when a context-dependent expression is used in a function body. (b) We think making it a type error might be an expedient way to achieve this. §§ The disagreement is about how we need to define the static/dynamic context to make this possible. §§ Also need machinery for describing how type errors are raised for things like name() where the reference to the context item is implicit. We can't raise type errors from within the F+O spec of the function, it has to be associated with the function call itself. §§ Feeling that we want to progress and we may have to do so without making progress on this issue: i.e. decide to stick with the status quo. §§ DECISION: close bug 4378 as "works for me". -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Wednesday, 11 November 2015 18:22:33 UTC