- From: C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com>
- Date: Thu, 20 Oct 2016 11:48:13 -0600
- To: public-xsl-wg@w3.org
- Cc: "C. M. Sperberg-McQueen" <cmsmcq@blackmesatech.com>
The XSLT WG met on Thursday, 20 October 2016 for 60 minutes ... > 6. Email discussions. > 6.1 Lazy evaluation of static parameters > Possibility of lazy evaluation of static > parameters / variables / use-when / shadow attributes > https://lists.w3.org/Archives/Public/public-xsl-wg/2016Oct/0002.html ABr > https://lists.w3.org/Archives/Public/public-xsl-wg/2016Oct/0003.html MK > https://lists.w3.org/Archives/Public/public-xsl-wg/2016Oct/0004.html ABr > https://lists.w3.org/Archives/Public/public-xsl-wg/2016Oct/0005.html > MK ABr summarized the point of his message 2: in expressions that need not be evaluated to evaluate the stylesheet, is the processor required to report errors or allowed to treat them as dynamic errors which did not in fact occur. We reviewed the thread. Both MK and ABr reported that their processors either already defer some static checking of constructs until first use of the construct, or are moving in that direction; this causes problems for this rule. MK suggested: "A processor must have a mode of operation in which the stylesheet author is able to determine whether or not there are any static errors in the stylesheet." MSM suggested as an alternative “A processor must at user option [be able to?] determine whether …” NEW ACTION 2016-10-20-002: ABr to open a Bugzilla entry suggesting detailed spec changes needed to meet the requirement to allow processor modes which do not raise all possible static errors. > 6.2 Invocation variants. > See MK ACTION 2016-09-29-003: > See also ACTION 2016-09-29-004: Abel to propose a table as described in > #9 in https://lists.w3.org/Archives/Public/public-xsl-wg/2016Sep/0001.html > To be skipped until Abel action item is completed We decided that progress on this topic requires someone to have a substantial amount of time thinking in a quiet room; we postponed further discussion until that happens. > 6.3 Component binding in inline functions > https://lists.w3.org/Archives/Public/public-xsl-wg/2016Jul/0005.html > https://lists.w3.org/Archives/Public/public-xsl-wg/2016Jul/0006.html > See MK action ACTION 2016-10-06-002: > 7. XSLT Draft > The diff version is at the usual location. > Published CR: http://www.w3.org/TR/2015/CR-xslt-30-20151119/ > Internal version: > https://www.w3.org/XML/Group/qtspecs/specifications/xslt-30/html/Overview.html > W3C Candidate Recommendation 11 September 2016 > 8. Spec bugs > 29790 [xslt30] Sample stylesheet for xml-to-json conversion uses a reserved namespace > Reclassified as editorial - Bug left open until the revised > version is tested. > In process. > 29818 [xslt30] Visibility and Applicability of Accumulators - > Discussed for a time last week - finish discussion today if possible. We discussed at some length, trying to understand the problem from all points of view. How to keep the treatment of different kinds of names as parallel as possible, how to make things as useful as possible for programmers, and how to avoid making things needlessly complex for implementations. In the end, in the light of our inability to hit upon a clear improvement that commands consensus, the WG was inclined to stick with the status quo. RESOLVED: close bug 29818 (Visibility and applicability of accumulators) with no action. Anyone with a bright idea that they believe will command consensus should bring it up. > 29819 [XSLT30] (editorial) Core functions > People were asked to review G.1 (when the draft containing that > text becomes available). > 29827 [XSLT 3.0] Error XTDE0045 revisited > https://www.w3.org/Bugs/Public/show_bug.cgi?id=29827 > 29880 [XSLT30] package-version - limits > https://www.w3.org/Bugs/Public/show_bug.cgi?id=29880 We discussed. There was support for the basic ideas of comment 2. MSM suggested (inspired by Mike Cowlishaw's observations on the design of Rexx) that limits which are round numbers in decimal might be preferable to round numbers in binary. So perhaps IntegerLiteral values up to 9999 rather than 65535, and NCNames up to 100 characters long. ABr suggested perhaps that it should not be allowed for a package to fail solely because its version identifier is too long. We discussed. RESOLVED: to close bug 19880 by allowing processors to impose limits on package version identifiers. Processors MUST accept identifiers up to [specified limits] and MAY accept longer identifiers. We agreed on 4 segments, 999999, and 100 characters in the NCName as the limits. We extended the meeting to allow ourselves to complete the discussion of this bug and adjourned at 25 minutes past the hour. > 29887 [XSLT30] Assertion on attributes of xsl:for-each-group is too strict, does not take shadow attribs into account Thu 22:12 > https://www.w3.org/Bugs/Public/show_bug.cgi?id=29887 Editorial; has been fixed. > 29889 [xslt30] Add clarifications on stylesheet invocation options > https://www.w3.org/Bugs/Public/show_bug.cgi?id=29889 > Is further discussion needed? > 29938 [XSLT30] Suggestion to drop XTDE1370 and XTDE1380 to bring them in line with XDM 3.0 > https://www.w3.org/Bugs/Public/show_bug.cgi?id=29938 > 9. Testing > 18 bugs open in bugzilla. ******************************************** C. M. Sperberg-McQueen Black Mesa Technologies LLC cmsmcq@blackmesatech.com http://www.blackmesatech.com ********************************************
Received on Thursday, 20 October 2016 17:48:38 UTC