Summary of Minutes of XSLT Telcon Agenda Thursday, 12 May 2016

What follows is a summary of the minutes of XSLT Telcon Thursday, 12 May 2016.

> -----Original Message-----
> From: Michael Kay [mailto:mike@saxonica.com]
> Sent: Thursday, May 12, 2016 12:54 AM
> To: XSL Working Group
> Subject: XSLT Telcon Agenda Thursday, 12 May 2016
> 
> AGENDA:
> 
> Michael Kay will  chair this week
> 
> 2 Assign minute-taker - need volunteer

Abel volunteers.

> 
> 3 Approval of previous minutes
> 
> https://lists.w3.org/Archives/Member/w3c-xsl-wg/2016Apr/0017.html (member only)

Minutes approved without further comments.

> 
> 5.3 Report on joint work - MKay, Abel

Nothing to report

> 7. Spec bugs
> 
> 29574 - [xslt30] Default visibility of accepted components
>         Needs to be further discussed - outside WG

MKay summarizes his action item ACTION-2016-04-28-001, which lead to the proposal in Comment#9.

He explained why visibility="absent" gives problems but also has holes in the current spec (see Comment#10) and suggests to solve this as mentioned in Comment#12.

He summarizes the issue as:
1) Do we mean the component exists without visibility
2) Do we mean the component is absent
3) Do we mean something else

MKay walks us through the proposal
ABr asks whether we can remove the attribute value "absent" entirely
The WG discusses this proposal and there's sympathy for it

By dropping it, the whole of visibilities becomes more orthogonal and removes the issue between option (1) and (2) above.

MSMcQ asks about the meaning "hidden". 
Answer (MKay, ABr): it removes it from scope of the current stylesheet, while "private" is visible in the current stylesheet

CONCLUSION/DECISION:
1) We drop visibility="absent"
2) We get the same functionality using attribute value "hidden"
3) The default for an abstract component will be "hidden"
4) The wording of XTSE3052 and the paragraph around it needs to be updated to reflect this change

> 
> 29513  [XSL30] Definition of "potentially consuming" in Glossary not complete
>     editorial - no discussion necessary; MKay to close after a few more tests.
> 
> 29499  [XSLT30] Global xsl:variable/xsl:param not in streamability rules
>      Needs to be discussed.

The WG went through Comment 2 and 3 of this bug report.

ABr suggests to add a little Note saying that xsl:key (the declaration) will NEVER apply to a streamed node or document because indexing requires multiple passes.

The WG accepted this proposal (about a Note).

We went over Situation 2a) we discussed section 3.5.6 and we decided that it is worthwhile to look for a different wording of this paragraph and perhaps disallow accessing the context item *unless* xsl:global-context-item/@streamable is present. This would create a dynamic error if a global variable were to access the global context item (as if it is absent).

Note that this is not a change in current rules, it is a change in where and when the error is allowed to be raised, and how we define the error in relation to xsl:global-context-item or global declarations.

We went on to discuss situation 3 and 4. Situation 3 was considered but , with streaming analysis being a static error in cases where global variables access the context item with a consuming or free-ranging expression, it was considered a breaking change to allow this and too little to gain with it.

Situation 4, while discussing, was considered a more worthwhile addition to the rules, as we currently already allow overriding variables with import precedence, and MKay mentions the use-case where you want to override an existing streaming variable with a non-streaming one that accesses the context-item (or vice-versa).

We ran out of time. MKay asked the scribe to summarize where we are in this bug report (29499):

- We discussed situation 1, agreed there was no problem, but clarification on xsl:key was considered helpful by means of a Note
- 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 
- 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). 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

> 
> 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
> 
> 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
> 
> 29602 xml-to-json() - inconsistency between XSLT 3.0 and XPath 3.1
> specifications.
>       Not yet discussed.
> 
> 29604 Request for clarification of xsl:stream example. External. Probably
> needs
>      a draft response (from MK or Abel?) fo the group to consider.

The WG went over the original bug report.

ABr suggested to add the map-based solution to the examples as a whole
MSMcQ suggested to also add the explicit forking example, with the map example and the accumulator example and to compare all three approaches

ABr adds to these three workarounds that it is technically possible to reach the same solution by using tunnel parameters, but does NOT suggest to add this to the spec. ABr and MSMcQ *may* take this discussion offline to see if it is possible at all.

The WG continued discussing variants and DECIDED to add all three workarounds as a good comparative example of what methods XSLT 3.0 provides for working with streams that need to be forked somehow to be processed correctly.

ABr suggests to remove the XP31 syntax of the lookup operator.

DECISION:
To resolve bug 29604 by adding three examples that show the ways XSLT 3.0 provides for situations that would otherwise require two downward (consuming) expressions.

Received on Friday, 13 May 2016 11:12:59 UTC