notes from technical discussion on XSLT WG call 2016-05-26

[Extract from minutes]

> 7. Spec bugs


> 29604 Request for clarification of xsl:stream example. External. See
> action item: ACTION  2016-05-12-002: Michael Kay to work out a map, fork
> and accumulator examples as in
> comment 2 of bug 29604, to be added to the spec, and to remove XP31
> specific syntax

MK summarized the current state of play: Martin Honnen found what
looks like some fossil text. It is not now correct, even if it once
was. We saw several ways to solve the application-domain problem, and
MK has an action (2016-05-12-002) to produce text with those
solutions. More time needed.


> 29602 xml-to-json() - inconsistency between XSLT 3.0 and XPath 3.1
> specifications.
>       Not yet discussed.

MK said there are two problems here.  

First, the two specs for xml-to-json() have got out of synch. We
should follow F and O 3.1, since that reflects joint decisions.

Second, implementing that is non-trivial, since F and O has factored
out rules for option parameters into a separate section, and XSLT 3.0
will need to do something to specify such rules. If XSLT 3.0 extracts
some of those rules, it will be very difficult to keep them in synch.

Also we specify some XSLT stylesheets which we say are equivalent to
the function, but they don't do all the validation required by the
function. MK suggested we should keep the stylesheets as is and
withdraw the claim that they are equivalent to the functions; what we
should say is that they are the same except in edge cases and errors.

MK would like to refer normatively to F and O 3.1 to avoid duplication
of material.

We discussed a possible normative reference. For the map functions, MK
has single-sourced the textual descriptions. That doesn't seem to be
possible for the option argument for xml-to-json().

SCA felt strongly that this was a bad idea; having XSLT 3.0 refer in
some places to F and O 3.0 and in others to F and O 3.1 is just too
confusing.

ABr asked why we can't incorporate the generic description of option
parameters from FO 3.1; MK said the main problem is that it's much
more general than we need. The xml-to-json function only has one
applicable option. MSM added that if we only have one such option, a
separate section will feel very odd.

We could try to paraphrase the rules that are relevant. The risk in
that case is falling out of synch.

After some discussion, we agreed that including the relevant section,
with the addition of a note saying that in fact at this time there is
only one function in XSLT which appeals to these rules.

RESOLVED: to settle issue 29602 by (a) weakening the claim about the
stylesheets to say that they are equivalent to the functions except in
edge cases and errors, (b) introducing the full set of rules governing
option parameters in F and O 3.1, and (c) treating the current text of
F and O 3.1 as the normative text. This same decision is also set out
(in different words) in comments 3 and 4 to bug 29602.




> 29574 - [xslt30] Default visibility of accepted components
>         outside WG comment - Max Toro
>         Discussed at last meeting - see ACTION item # 2016-05-12-2016-003.

MK still has work to do, but does not currently see the need for
further discussion. He will come back to the WG if this changes.


> 29513  [XSL30] Definition of "potentially consuming" in Glossary not
> complete
>     editorial - no discussion necessary; MKay to close after a few more
> tests.

SCA pleaded with MK to make some more tests so we can close this.
He said he would try.


> 29499  [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.

ACTION 2016-05-26-001: ABr to raise an issue analogous to 29499,
addressing accumulators.

RESOLUTION: to close issue 29499 as it applies to global variables 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. This resolution does not
apply to accumulators, which will be handled separately (bug to be
raised by action 2016-05-26-001).




> 29492  [XSLT30] streamability of xsl:attribute-set may not be complete
>       Action item from 14 April meeting.
>       https://lists.w3.org/Archives/Public/public-xsl-wg/2016Apr/0006.html

We need to come back to bug 29492.  

Next week's call will begin with bug 29492.

The meeting was adjourned at 26 minutes past the hour.


> 29472  [XSLT30] Optionally allow xsl:stream to process a document *without*
> streaming  2016-03-10
>       Action item from 14 April meeting.
>       https://lists.w3.org/Archives/Public/public-xsl-wg/2016Apr/0005.html


> 8. Test bugs

>   From bugzilla  (12 open bugs)  as of 25 May 2016
>   Are there any that need to be discussed?
>   There has been little recent movement...

-- 
****************************************************************
* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com 
* http://cmsmcq.com/mib                 
* http://balisage.net
****************************************************************

Received on Thursday, 26 May 2016 18:17:51 UTC