W3C home > Mailing lists > Public > public-qt-comments@w3.org > May 2016

[Bug 29499] [XSLT30] Global xsl:variable/xsl: param not in streamability rules

From: <bugzilla@jessica.w3.org>
Date: Thu, 26 May 2016 23:01:58 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-29499-523-B7qF8t0ZRD@http.www.w3.org/Bugs/Public/>
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

This archive was generated by hypermail 2.3.1 : Thursday, 26 May 2016 23:02:01 UTC