technical discussion of 2016-06-30

Extract from the minutes of today’s call:

> 6. Email discussions.

> 6.1 Options for what https://www.w3.org/TR/xslt <https://www.w3.org/TR/xslt>
>  Carines' action item email.  To be discussed.
>  https://lists.w3.org/Archives/Public/public-xsl-wg/2016Mar/0011.html <https://lists.w3.org/Archives/Public/public-xsl-wg/2016Mar/0011.html>
>  Note: topic not expected to be discussed this week.

> 6.2 Invocation variants
>  https://lists.w3.org/Archives/Public/public-xsl-wg/2016Jun/0005.html <Https://lists.w3.org/Archives/Public/public-xsl-wg/2016Jun/0005.html>

We discussed ABr's mail and the document.

ABr clarified that "input is streamed" and "input is not streamed"
mean we get called on interfaces that accept something the
implementation regards as a streamed node, or something the
implementation regards as a non-streamed node. A simple-minded oberver
can without too much loss of generality regard these as packaging for
either a SAX even or a DOM tree.

Some aspects of the questions raised here seem to belong to API
design, which is out of scope for us. But we decided to discuss them
anyway, on the grounds that while we don't want to constrain API
design, we do want to be sure that the spec works for at least one
possible API design.

One point that may merit recording: in response to the question "what
obligation does a streaming processor have, if the value for its
to-be-streamed input is presented as an in-storage DOM?", MK suggested
that our policy ought to be that in that case, we don't actually care.
ABr elaborated this idea by suggesting that one could regard such an
in-memory data structure as the result of an xsl:copy-of performed on
the streamed node -- like all such copies, this one need not itself be
streamed.

MK asked ABr to try to net out a concrete set of proposed changes.

ACTION 2016-06-30-001: ABr to derive a concrete set of proposed 
changes to the spec from the table in the attachment to 
public-xsl-wg/2016Jun/0005.html, or at least a concrete list of areas 
where changes are needed. 


> 7. XSLT Draft

> The diff version is at the usual location.

>  Published CR: http://www.w3.org/TR/2015/CR-xslt-30-20151119/ <http://www.w3.org/TR/2015/CR-xslt-30-20151119/>

> Internal version:
> https://www.w3.org/XML/Group/qtspecs/specifications/xslt- <https://www.w3.org/XML/Group/qtspecs/specifications/xslt->
> 30/html/Overview.html
> dated W3C Candidate Recommendation 27 May 2016


> 8. Spec bugs

MK will produce a new version of the spec as soon as feasible in order
to allow various of these bugs to be fixed.

> 29472  [XSLT30] Optionally allow xsl:stream to process a document *without*
> streaming  2016-03-10
>  https://www.w3.org/Bugs/Public/show_bug.cgi?id=29472 <https://www.w3.org/Bugs/Public/show_bug.cgi?id=29472>
> Note on status: Awaiting offline discussion

> 29513  [XSL30] Definition of "potentially consuming" in Glossary not complete
> 2016-03-31
>  https://www.w3.org/Bugs/Public/show_bug.cgi?id=29513 <https://www.w3.org/Bugs/Public/show_bug.cgi?id=29513>

> 29667  [XSLT30] XTSE3050 with hidden components and homonymous name
> conflict is ambiguous
>  https://www.w3.org/Bugs/Public/show_bug.cgi?id=29667 <https://www.w3.org/Bugs/Public/show_bug.cgi?id=29667>

>  Note from June 16 minutes: bug is marked RESOLVED in minutes but not
>  annotated in bug report: see decision in the bug in comment
>  #5, based on WG decision June 2, 2016.
>  Is there a reason for delay?

> 29686 - [xslt3.0] Imprecise language for rules on xsl:override -
>  reopened at MK request
>  https://www.w3.org/Bugs/Public/show_bug.cgi?id=29686 <https://www.w3.org/Bugs/Public/show_bug.cgi?id=29686>

> Status: Bug is now closed: please check resolution.

> 29692 xsl:strip-space and packages
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=29692 <https://www.w3.org/Bugs/Public/show_bug.cgi?id=29692>

> Status: Bug is still open, but detailed changes are written up in Bugzilla and have been applied to the spec; please check proposed resolution.

> 29696 Dropping streamability of the global context item (GCI), in particular, xsl:global-context-item/@streamable
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=29696 <https://www.w3.org/Bugs/Public/show_bug.cgi?id=29696>

> Status: Bug is now closed: please check resolution.

> 29697 [XSLT30] With nested xsl:merge, should the current-merge-group() of outer merge be available for a merge group selection of inner merge?  
>  https://www.w3.org/Bugs/Public/show_bug.cgi?id=29697 <https://www.w3.org/Bugs/Public/show_bug.cgi?id=29697>

> Status: Proposal in Bugzilla, has been provisionally applied to the spec. Please check resolution.

> 29698 [XSLT30] Streamable merging does not require streamability checking anymore 
>  https://www.w3.org/Bugs/Public/show_bug.cgi?id=29698 <https://www.w3.org/Bugs/Public/show_bug.cgi?id=29698>


> 29699 [XSLT30] XTSE3085 needs slight clarification for <xsl:template name="x" /> situation  
>  https://www.w3.org/Bugs/Public/show_bug.cgi?id=29699 <https://www.w3.org/Bugs/Public/show_bug.cgi?id=29699>

ACTION 2016-06-30-002: editor to propose wording to resolve bug 29699 
by rephrasing the error description to resolve the problem identified. 


> 29705 [xslt3.0] global-context-item() function 
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=29705

ABr suggested that if we introduce such an accessor, we should also
introduce an initial-match-selection() accessor. MK suggested that
this might raise issues for streamed nodes in the initial match
selection. ABr said that in that case, calling the accessor should be
forbidden.

In both cases one can declare a tunnel parameter with the value. But
the initial match selection is a sequence, each member of which is
accessed one at at time; this is either a good thing because it gives
us new functionality, or a bad thing because it creates a new
obligation for the implementation.

MK noted that the tunnel parameter can only be bound to one item at a
time: the current node being processed where the value of the tunnel
parameter is set.

We will come back to this bug next week, after thinking about it some
more.


> 29709 [XSLT30]Some xsl:merge examples use variables not defined in the samples, probably as earlier versions bound merge groups or keys to variables 
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=29709

RESOLVED:  to accept bug 29709 as editorial and correct.


> 29710 [xslt3.0] Streamability="filter" example
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=29710 
 
RESOLVED:  to classify bug 29710 as correct and editorial.


> 29711 [XSLT30]Example: Merging Two Sequences of Numbers should use xsl:sequence instead of xsl:value-of 
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=29711

RESOLVED: to classify bug 29711 is correct and editorial.

ABr suggested we should try to take some steps to ensure that Martin
Honnen has access to the WG-internal drafts.


> 29712 [xslt3.0] Why are streamable stylesheet functions required to be consuming? 
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=29712

MK asked if the restriction to consuming function bodies was
necessary. ABr thought it might have been in order to avoid confusing
users with situations like the following: 

  If you declare f as absorbing, with a motionless grounded body (like
  second example in bug), then when you call that function the result
  will be absorbing; you won't be able to call it twice anyway.

ACTION 2016-06-30-003: ABr to review bug 29712 in detail and determine
whether changing the rule would lead to inconsistencies or
implementation issues.
 

> 9. Test bugs

ACTION 2016-06-30-004: ABr to clean up outstanding test bugs, and 
bring to the meeting any that need discussion. 

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


ABr suggested that we should perhaps turn the list of tests to be
created into action items, to increase their visibility.

Adjourned after ninety minutes.  Next call next week.



********************************************
C. M. Sperberg-McQueen
Black Mesa Technologies LLC
cmsmcq@blackmesatech.com
http://www.blackmesatech.com
********************************************

Received on Thursday, 30 June 2016 17:40:38 UTC