W3C home > Mailing lists > Public > public-xsl-wg@w3.org > February 2016

[minutes] XSLT F2F at XML Prague 2016, Feb 16, 2016 (day 2)

From: Carine Bournez <carine@w3.org>
Date: Tue, 16 Feb 2016 16:49:35 +0000
To: public-xsl-wg@w3.org
Message-ID: <20160216164935.GQ15302@people.w3.org>

Minutes of XSLT F2F - February 16th

Present: Debbie, Mike Kay, Abel, Jirka, Florent, Carine
Minute taker: Carine

Note that during the day:
Abel requests that we add 2 items to the agenda:

* behavior of xsl:accept element: what happens to the other public components
in the used package (the ones not concerned by the xsl:accept)?

* usability issue: How to accept several components in a single xsl:accept


Bug 29459   Streamability rules for arrow expressions

MK: we just need to generalize to static *and dynamic* function calls
ABr: agree

MK: current statement is 
Arrow expression (XPath 3.1)	See Streamability of Static Function Calls: the rules for X => F(Y, Z) are the same as the rules for F(X, Y, Z)

Debbie: spec already covers dynamic calls:
<< Streamability of Dynamic Function Calls


This section applies to dynamic function calls written using the traditional syntax $F(X, Y, Z) and equally to those using the new XPath 3.1 syntax X => $F(Y, Z)

RESOLVED: update the spec as indicated in ACTION 2016-01-14-003.

The WG looked at bug 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29346 (marked Resolved Fixed)
and searched for the actual change in the XPath spec.
MK sent an email to the editors to check the status and made a note in 
bugzilla to keep tracking this.


Bug 29460   External (non-XSLT) packages

RESOLVED: add a sentence to make it clear that processor can offer mechanisms
for packages written in other languages (impl. defined).

Wordsmithing the sentence. Then we noticed that wording in 2.7 needs to be
amended. Result of the discussion is therefore recorded in comment 1


Bug 29461  Clarify effect of document("") when the source stylesheet is not available at run-time

>From the F&O spec 
XQuery 3.0 and XSLT 3.0 give an implementation freedom to use different base URIs during the static analysis phase and the dynamic evaluation phase, that is, for compile-time and run-time resources respectively. In this situation, the fn:static-base-uri function should return a URI suitable for locating resources needed during dynamic evaluation.
MK: It's a bit fuzzy but I'm not sure if we want to be more precise.
In a classic interpreted env., it's the value evaluated by fn:document().
If it's in a stylesheet, you get the stylesheet source doc. If in an included 
or imported module, you get that module.
If it is a package, you can get the location of where it was at compile-time.
ABr: If I get a compiled package from you, I can't call document("") from 
inside this package unless you provide it to the user.
If it is a byte-stream, you may not know a location at all.
MK: the text says it would be the location where it was compiled, then.
ABr: I can see a usability feature to get the working directory.
MK: question is 'are we happy with the current text in F&O?'
ABr: I'd like to see a place in the spec saying what users should do.
MK: this bug report highlights that document("") no longer always work

The WG looked at 20.1 fn:document
The first paragraph of the Notes needs fixing.

Last paragraph of (5.8) URI References already mentions possible differences
between compile-time and dynamic call

(Abel notes a typo,  s/which to avoid/wish to avoid)

[discussion about static expression/static analysis of "compiled" package]

ABr example:

<xsl:variable select="doc("")/*/x:data: static="yes" name="data"/>
<xsl:template select="foo[$data]...]">

MK: the context of the static evaluation might be different. You have a MUST here
by having static="yes". You can't expect the document to be still there when
you ship your package.
Jirka: what about forbidding doc("") in packages?
ABr: clearly doc("") won't work all the time
Florent: it's not a spec issue, it's the developer's job.
ABr: we should add a note saying whenever you use the document or doc collection
functions and you want to ship your packages, you should paramterize, or not
do it at all.
CB: do we all agree that the spec should warn the developers about the use of
those functions in packages?
MK: yes.

ACTION 2016-02-16-001: Mike Kay to propose wording changes to align document 
function with the current flexibility of static-base-uri (bug 29461), essentially
in section 20.1.


Bug 29462 Add fn:transform and fn:load-xquery-module to dynamic evaluation feature

MK: I think we already give sufficient flexibility to fn:transform already.
ABr: and optional feature in F&O (You can always raise errors 
[FOXT0001] if you like)
MK: yes, e.g. throw the error if you think it would be a security risk.

fn:load-xquery-module is similarly defined.

ABr argues that if it's similar to fn:document, but you don't have doc-available
to recover if failure happens at compile time.

MK proposes to close as WORKSFORME.



Bug 29463 A little too much prejudice in the algorithm of on-empty/on-non-empty

ABr: I read it wrong and there's no issue.

RESOLVED: closed 


Bug 29467  Non-streaming fallback implementation of xsl:stream

MK: this issue came from the interop workshop.
XSLT 30 section 19.10 says
For a non-streaming processor, the processor must evaluate the construct delivering the same results as if execution used streaming, but with no constraints on the evaluation strategy. (Processing may, of course, fail due to insufficient memory being available, or for other reasons.) A non-streaming processor is not required to assess whether constructs are guaranteed-streamable, or to apply restrictions such as the rules for where calls on the functions accumulator-before and accumulator-after may appear. However, a non-streaming processor must enforce the constraint implied by a use-accumulators attribute restricting which accumulators can be used with a particular document.
It might be possible to switch streaming on and off in the processor.

ABr: what about <xsl:evaluate without-streaming="yes" ?
Debbie: did this arise from being able to distinguish whether you used streaming
or not? being able to use a switch would make it clear.
MK: yes.

Section 19.10 already says 
one of the following 
[throw an error, process as non-streaming processor, or with streaming] 
at user option
do we need an interoperable way of setting this option, in the stylesheet?

ABr: this is for the entire stylesheet. The bug report suggests to have this 
option for xsl:stream element.
Carine: objection to add a "don't stream" option on a "stream" instruction.

MK: main use case is to write an application capable of streaming when fed 
with large documents, and not streaming with small ones, without changing the
Florent: processor option? behave as streaming processor or a non-streaming
I would like to allow a streaming processor to try to stream a non-guaranteed
streamable stylesheet and throw a dynamic error if it does not work.

see wording proposal in bugzilla

MK: we have an at-risk feature (#3) about the requirement for processor to 
report non-guaranteed streamability while it is able to stream (might happen
when streamability analysis happens after optimization, and optimization made
it guaranteed-streamable).
ABr: if we remove that feature at risk, we have to rephrase rule 2.a in 19.10.
Carine: it is important that guaranteed streamability assessed with a processor 
is also valid on a different processor.

Requirement made in bug 29467 is already covered by a note in section 18.1
and the paragraph in 19.10 

MK: proposal to close with no action.

RESOLVED: bug closed with no action.

Abel raises a new bug for the other point. (see bug 29472)


Bug 29468

ABr: package version is mandatory, example in to be fixed
We confirm that Cpq should have visibility private, not public.

ABr: a param has to be "public"


Carine: Even though 1st para says default is private, there is a sentence later
that deals with xsl:param
The visibility of the overriding component in the using package is defined by the visibility attribute appearing on the overriding declaration, except in the case of xsl:param, which is implicitly public.

ABr: It seems a bit contradictory.

Carine raises a new bug about this contradiction. (see bug 29473)

RESOLVED: Close bug 29468 with the visibility fix for Cpq in the table.

[lunch break]

Bug 29470  Polyfills

MK: a polyfill is a function that fills gaps in the js libraries. If the
browser does not have a function, that it can use the one you provide.
We've got a similar concept with <xsl:function
override-extension-function="yes"/> which is explicitly designed to allow
users to define an implementation of a function that is present in some
implementations but not others.
We've got the facility for vendor-defined functions, but not for the 
reserved namespace.
In the proposal, if override-extension-function="yes" then you force using 
your implementation of the function, if override-extension-function="no"
your implementation will be used only if the processor does not provide an

MK: We could define that it has to have visibility set to private.
Florent: it would be less useful then, you could not use a function from
another package.

[lengthy discussion about function signature, binding function calls and so on]

The WG likes the idea but it sounds much more complicated than what 
Mike originally thought. Built-in functions are dealt with differently 
in implementations than extension functions.

RESOLVED: close the bug with no action.

The remaining 2 spec bugs were raised during this morning discussions, the WG
agreed to look at test suite bugs first.


Bug 20843  function-1902

RESOLVED: fixed by replacing the expand-text feature, closed


Bug 28926  merge with accumulators - no tests 

needs tests


Bug 28927  Tests for streamable stylesheet functions

Some tests exists, needs more


Bug 29123  validation-0202

line 161, MK fixes it live with a for expression


Bug 29128  QT3 converter: load-xquery-module tests

Proposal to "merge" the catalogs.
Debbie will take care of extracting the tests.


Bug 29129  QT3-derived tests -s:prod-AxisStep.unabbr -t:unabbreviatedSyntax-4,



Bug 29223  function-1025/1026 test implementation-defined behavior

Abel will revert his change as announced.


Bug 29231  tests import-0001 and import-0002 

>From information on comment #8, it looks like it should already be closed


Bug 29233  package-017: duplicate function declaration

The tests (package-017 and -018) are both fixed. Bug should be closed already

Abel requests that we add 2 items to the agenda:

* behavior of xsl:accept element: what happens to the other public components
in the used package (the ones not concerned by the xsl:accept)?

* usability issue: How to accept several components in a single xsl:accept


Bug 29235  package-101 - entry point

Already fixed, should be closed.


Bug 29236 package-100, 101: extra empty <row> elements in output

Already fixed, should be closed.


Bug 29302  expected error codes

import-schema-157 expects XTTE1540, but I think it should be XTSE0010.
(XTTE1540 is to do with type attributes, which are tested in
import-schema-158, but not in import-schema-157.) 
  => WG agreed

unparsed-text-lines-006 expects XTDE1190 which should be updated to FOUT1190.
  => WG agreed

for-each-group-059, and 060 expect XTSE3220 but this appears to have been
removed from the spec. I think they should expect XTDE1071 and XTDE1061
   => for-each-group-059 should raise dynamic error XTDE1071
   for-each-group-060 should raise dynamic error XTDE1061

for-each-group-079b expects XTDE1061 but I think it should be XTDE1071 (the
test involves the current-grouping-key() function, not current-group()).
   => WG agreed


Bug 29305  number-3501, 3229, 4001

Going through test 3501 very carefully, the WG agrees with Tim's view on 
the expected result. 
MK: Saxon JS gives that result (and it is implemented very litterally according 
to the spec)

Similarly, the results for tests 3229 and 4001 are wrong.

Tests will be fixed and bug is closed.


Bug 29379  mode-1701 expects success, but should probably fail with XTDE0045

ABr: if you want to use an initial mode on a package it must be public or
MK highlights (from comment 4) that 6.6.1 says: "A named mode is not 
eligible to be used as the initial mode if its visibility is private."

Test result should be a failure with error code XTDE0045.

MK raises a spec issue for the lack of precision about visibility in the 
description of error code XTDE0045. -> Bug 29475

Suggested resolution for this new bug is to add "*whose visibility is public 
or final*" at the end of the description of error code XTDE0045. 


Bug 29423  result-document-0243 expects SEPM0016 but should be XTSE0020

WG agreed, already fixed, close.


Bug 29447  math-3307

Already fixed, close.


Bug 29448 accept-007 tries to override a final component but does not expect
an error

WG agreed there's a bug, xsl:override tries to override a final variable.
To be fixed.

[recess for the day]
Received on Tuesday, 16 February 2016 16:49:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:43:27 UTC