XSLT F2F at XML Prague 2016, Feb 15, 2016 (day 1)

Minutes W3C XSL WG F2F Prague 2016-02-15

 

Minutes from last telcon approved:

https://lists.w3.org/Archives/Member/w3c-xsl-wg/2016Feb/0009.html

 

Present on the F2F:

Jirka

Charles

Carine

Liam

Debbie

Florent

Michael Kay

Abel

 

On the phone: no-one

 

 

We have a rather generic agenda today.

 

1) going over action items

 

ACTION-2015-04-23-001 RelaxNG schema

 

Michael Kay explained the subtle inricacies of getting the schema as correct as possible.

 

After some discussion of auto-generating it from the XSD in the spec we realized this wasn't the based way to go about it.

 

MK suggested to invite a volunteer to either regenerate the RelaxNG from the XSD or 

 

https://github.com/innovimax/xslt30/blob/master/xslt30.rnc

Charles volunteers 

 

MK suggests to create a deadline on the anniversary of the issue

 

The WG agrees.

 

ACTION-2015-11-19-002: MHK to ensure that the build system creates up-to-date namespace documents for the XSLT and MAP namespaces.

 

Still open.

 

ABr asks for the difference in REC links between "xslt30" "xslt-30", where there's often confusion and they point to 404 error pages.

 

Liam says that they once wanted to normalize all links but technical difficulties prevented this. However, redirects are possible and he asks ABr to send out a list of problematic links to be fixed.

 

NEW ACTION-2016-02-15-001: ABr to go over problematic links and suggest 302 redirects to Liam/Carine

 

ACTION 2015-12-17-002: Mike Kay to carry out the decisions made for resolving bug 29234.

 

TODO: MKay says the decision on this bug got lost somehow. We'll revisit when we go over the bugs.

 

ACTION 2016-01-14-001: ABr and MKay to come up with a status and summary of the workshop in XML Prague

 

DONE / overtaken by events (the workshop has been given, see next action item)

 

NEW ACTION-2016-02-15-002: MKay to prepare a report on the XSLT 3.0 workshop of XML Prague and incorporate Liam's notes.

 

ACTION 2016-01-14-003: MKay to update the rules on arrow expression streamability such that it is done in the same way as in XP, which means that the lexical rewrite is applied and the streamability rules apply *after* the lexical rewrite

 

The WG briefly discussed this action, MKay finding out that it seems like the text is actually correct. 

 

MKay created a bug report. 

 

Action can be dropped in favor of bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=29459.

 

ACTION 2016-01-14-004: ABr to suggest alternative wording as suggested in the minutes of today, and to create a bug report for https://lists.w3.org/Archives/Public/public-xsl-wg/2016Jan/0002.html

 

Bug created by MKay, action item can be dropped

 

https://www.w3.org/Bugs/Public/show_bug.cgi?id=29460

 

ACTION-2016-02-04-001: MKay to come up with a proposal for explaining the fuzziness of document("") when used in packages or otherwise. Plus adding examples that explain this.

 

Bug created by MKay to track this, action item to be dropped: https://www.w3.org/Bugs/Public/show_bug.cgi?id=29461

 

 

 

ACTION-2016-02-04-002: ABr to turn this into a bug report and to write up a suggested wording for putting it under the dynamic-evaluation feature.

 

NOTE FROM SCRIBE "This" here points to https://lists.w3.org/Archives/Public/public-xsl-wg/2016Jan/0006.html

 

ACTION now tracked by bug report https://www.w3.org/Bugs/Public/show_bug.cgi?id=29462

 

 

ACTION-2016-02-04-003: MKay to come up with a proposal to add fn:serialize under the serialization feature (bug 29392)

 

MKay has recorded the conclusion from last telcon (that we agreed in principle that we need to make this happen, i.e. that fn:serialize should be part of the serialization feature)

 

Bug report updated, action can be dropped.

 

-----------------------------------------------

 

Next item: bugs

 

Bug 29234[xslt30ts] package-908

 

This bug evolved around what dynamic error should be raised in the mentioned situation. The WG went over the bug report and agreed with the proposed resolution in comment#3, leaving it to the editor to come up with a text *without* the double negative to avoid confusion.

 

DECISION: resolution in bug 29234, comment#3, accepted: rewording of error XTDE0045.

 

-----------------------------------------------

 

Next item: bug 29375 [XT30] Changes of bug 29251 (dropping the XQuery Invocation feature etc) are not in the Changes section

 

Marked EDITORIAL. Editor fixed the bug on-the-fly during the F2F meeting.

 

DECISION: bug marked accepted, no change log of this bug will be available, as it is about the changelog itself

 

-----------------------------------------------

 

Next item: Bug 29387 - [XSLT30] typo in title

 

Marked EDITORIAL

 

DECISION: bug accepted, no change log of this bug will be available, 

marked DONE during the F2F meeting.

 

-----------------------------------------------

 

Next item: Bug 29392 - [xslt 3.0] Serialization Feature and the fn:serialize() function

 

FG argues that there's a conceptual difference between serialization to a string and to series of octets

 

ABr argues that supporting serialization means supporting xsl:result-document and xsl:output, plus xsl:character-maps. If we require fn:serialize to be supported this should not require all these other features.

 

Carine points out that F&O already defines an error FODC0010, which says that if a host language has serialization as an optional feature, the fn:serialize function is an optional feature, in which case it MUST throw an error if the fn:serialize function is called.

 

FG: says that this is not a good thing, because that means that you cannot *not* support serialzation without also supporting fn:serialize

 

Proposal: 

  If the Serialization Feature is not available, then a processor MAY raise error FODC0010 if fn:serialize() is called, or if fn:serialize() is called requesting options that are not supported.

 

This caused some additional discussion, though the group was sympathetic towards this proposal. ABr suggested that the wording should REQUIRE an error if fn:serialize is supported, but not the Serialization Feature, *AND* it is called with a parameter that is not supported.

 

Revised proposal:

 

  If the Serialization Feature is not available, then a processor MUST raise error FODC0010 if fn:serialize() is called requesting options that are not supported.

 

FG and ABr discuss the issue with certain options that do not make sense when serializing to an xs:string is performed.

 

ABr and Liam discussed the issues involved with encoding and serializing, realizing that the F&O spec allows leniency in output character references as a string, or not (unescaped).

 

The WG reached consensus towards allowing leniency with fn:serialize and allowing cherry-picking features. This also means that, for instance, cdata-section-elements does *NOT* have to be supported but at the same time does *NOT* have to raise an error when present *if and only if* there is no element in the result tree that matches the cdata-section-elements option.

 

Revised proposal:

 

If the Serialization Feature is not available and fn:serialize() is called with values for serialization parameters that are not supported, then a processor MUST raise error FODC0010 

 

(and add notes to say what this means - a processor might reject all calls on fn:serialize, or it might support only selected options.)

 

DECISION: This proposal was accepted.

 

--------------------------------------------------

 

Next item: Bug 29424 - [XSLT30] Contradiction in the sentence on item-separator

 

The WG discussed this briefly, ABr realized he hadn't read the sentence carefully enough and it does say everything it needs to say.

 

DECISION: close but 29424 as WORKSFORME

 

-------------------------------------------------

 

Next item: Bug 29425 - [XSLT30] Some AVT's in xsl:result-document seem not defined as such

 

The WG discussed the bug report and decided that the XSLT 2.0 spec already had an AVT for the method attribute, which should be reinstated. Also, the "these" in the sentence refers to the list before, which does not include @validate and @type.

 

The WG rejected the suggestion in the last para of the bug report, stating that such information should be available statically and shadow attributes are enough.

 

The WG decided to resolve this bug as written in comment#1 of the bug report.

 

---------------------------------------------------

 

Next item: Bug 29431 - [XSLT30] item-separator applicability

 

We discussed this bug until some extend trying to understand the current spec and realized it needs some clarification. Then the discussion went on and some points were made towards adding item-separator to a situation where build-tree="yes"  (the default).

 

We then went on a lunch break, from here Liam takes over the minutes.

 

###################################################

 

Following minutes copied from Liam's minutes, who was the minute taker the 2nd half of the meeting.

 

 

https://www.w3.org/Bugs/Public/show_bug.cgi?id=29431

 

Abel asks, what does item-seperator do...

Mike Kay researches it; it's defined in the serialization spec...

which says it's used for separating atomic values in the result.

This means it has no effect between elements.

 

Mike: 2 possible changes to the spec. (1) that the build tree phase should take account of item separator, and (2) is to explain what happens more clearly. I think we need to go and asses the impact, not do this on the fly.

 

See comment 1 to bug 29431 which Mike wrote during the discussion: [[

 

We spent considerable time discussing this.

 

One possible spec change that might help usability is for the "build tree" phase to take account of item-separator, so item-separator separates atomic values in the raw result sequence whether or not you are serializing.

 

Apart from that, we felt that improved explanations in the spec (including perhaps a diagram!) could aid understanding, but there was no need for technical change.

 

Note (from reading the serialization spec) that item-separator does NOT separate adjacent text or element nodes, only adjacent atomic values.

]]

 

## no resolution yet.

 

 

https://www.w3.org/Bugs/Public/show_bug.cgi?id=29434

Bug 29434 - [XSLT30] xsl:on-empty/on-non-empty with attributes and use- attribute-sets (edit) 

 

 

Mike: I don't agree the spec's ambiguous. It's just wrong. It doesn't include use-attribute-sets. But we don't ignore namespace nodes.

 

Going back to use cases for this, HTML generation is [important], and empty should mean "looks empty", e.g. a table is empty is empty if it looks empty even if it has a style attribute. Empty is often used this way in XML too, as in an empty element that might have attributes.

 

But anything we say about attributes should apply regardless of whether the attributes were literal or came from attribute sets etc. My comment

1 on the bug [is intended to] achieve this.

 

[discussion with Florent, Mike, Abel]

 

Abel asks about why a sequence of zero-length strings should be empty.

Empty here is not the same as XPath empty().

 

Liam: It's like deep-equal - you either have to accept it's not perfect for all use cases, or you want a parameterized version that takes a comparison function. But that was rejected for deep-equal, and here, you can write your own solution if you need a different definition for empty.

 

Abel: we need more tests in corner cases, or at least to check them.

ACTION Abel to review the new on-empty tests in the light of bug 29434

 

Mike: it's worth adding the workaround of using xsl-sequence, and of adding to the notes something about attribute sets.

 

DECISION: resolve 29434 by accepting Mike Kay's comment 5.

 

 

https://www.w3.org/Bugs/Public/show_bug.cgi?id=29436

Bug 29436 - [XSLT30] List in 5.7 sequence constructor seems a bit off

 

The text in question is not normative but rather tutorial in nature, and so the list of elements that might return sequences doesn't need to be complete.

 

DECISION: resolve 29436 by accepting Mike Kay's editorial changes in comment 1 (and reported in comment 2).

 

 

https://www.w3.org/Bugs/Public/show_bug.cgi?id=29441

Bug 29441 - [xslt3.0] Definition of "extension functions"

 

Our current definition makes an inline function be considered an extension function, which isn't right. So the definition needs t obe updated in the light of XPath functions.

 

Mike Kay's comment 1 to 29441 isn't really enough of an improvement - e.g "a reference to an extension function" isn't a well-defined concept.

 

Mike: "I think we can get away with a fairly fuzzy definition as long as it's not actually wrong."

 

Can extension functions be anonymous?

 

Abel - sure.

 

E.g. an extension function that returns functions.

 

So, yes, an extension function can be anonymous.

 

An extenstion function is a named function introduced to the static or dynamic context by mechanisms outside the scope of this specification.

 

What about an extension function that returns anonymous functions?

Maybe that doesn't matter.

 

DECISION: close 29441 by accepting Comment 2 from Mike Kay

 

 

https://www.w3.org/Bugs/Public/show_bug.cgi?id=29442

Bug 29442 - [XSLT30] Some tweaks may be needed on 5.7 Sequence Constructors to create a better understanding between the two phases involved and the effect of build-tree 

 

Not talking about making any technical changes here.

 

ACTION Mike Kay to propose editorial improvements for bug 29442 on Sequence Constructors.

 

 

https://www.w3.org/Bugs/Public/show_bug.cgi?id=29445

Bug 29445 - [XSLT30] clarification / cleanup in section 5.7.2 Constructing Simple Content on the separator attribute

 

DECISION: close 29445 on consructing simple content as per comment 5

 

 

https://www.w3.org/Bugs/Public/show_bug.cgi?id=29449

Bug 29449 - [xslt 3.0] Streamability of $map($key) and $array($index)

 

In practice streamablity depends only on the argument, which depends on the static context. If we know it's a map... but a map used as a function can't in general be determined statically to be a map. But if we do now, key is xs:anyAtomicType, so type usage becomes absorbtion, so a node will be atomized, so it's consuming, which is what we want. 

 

The spec turns out to be right, so it's editorial.

 

DECISION close 29449 accepting comment 1 to add a note to the spec on streamability of $map() and $array().

 

 

https://www.w3.org/Bugs/Public/show_bug.cgi?id=29453

Bug 29453 - [xslt30ts] package-019 - use package via xsl:include

 

[discussion not captured]

 

Abel's impl'n allows this, Mike and Debbie's dos not.

 

Compromise was achieved.

 

DECISION: close 29453 by accepting Abel's compromise as described by Mike in Comment 2.  Essentially: allowing xsl:include to include xsl:use-package into the package manifest and to disallow xsl:import to do the same, for which a static error will be defined.