- From: <bugzilla@jessica.w3.org>
- Date: Thu, 26 May 2016 23:01:58 +0000
- To: public-qt-comments@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29499 --- Comment #5 from Michael Kay <mike@saxonica.com> --- >From the minutes of 12 May and 26 May: [XSLT30] Global xsl:variable/xsl:param not in streamability rules Summary from last meeting: - We discussed situation 1, agreed there was no problem, but clarification on xsl:key was considered helpful by means of a Note (no action item assigned) - We discussed situation 2 and agreed there was room for improvement, in particular for error scenarios. The editor proposed to look for better wording here (no action item assigned) - We discussed situation 3, decided to leave it as is - We discussed situation 4 and considered import-precedence should be taken into account, but did not reach a full conclusion, though there was clear sentiment towards making this change (note that currently the spec does not say anything about it). Again, no action item was assigned, further discussion needed. - We DID NOT yet discuss the situation sketched in last para of comment 4. - No formal DECISION was reached yet, but consensus was reached on points mentioned above MK said there are two situations where a variable declaration is not used: (a) when there is no reference to it, and (b) when it is overridden by a declaration with higher import precedence. In those situations, does it need to satisfy the streamability rules? In the case of import precedence, it would be nice to say "no" -- one could imagine a non-streamable library which is overridden precisely to make it streamable. In the case of an unreferenced variable, MK felt the natural answer was "no", since we have no distinctions anywhere in the spec between declarations that are referenced and those that are not. The same principles should apply to other global components for which the same question arises. Proposed resolution: to close issue 29499 as summarized in the minutes of 12 May (extracted above), plus a resolution of situation 4 with two parts: (a) error is raised for unreferenced global variables, and (b) no error is raised for overridden global variable declarations. We were about to adopt this proposed resolution when it became clear that 29499 also covers accumulators. ABr proposed that the same principles will apply to (the initial value of) accumulators. MK felt the need for more study of how these considerations apply to accumulators. So we decided to separate accumulators from variables. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Thursday, 26 May 2016 23:02:00 UTC