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
instruction.
]]



--------

Bug 29459   Streamability rules for arrow expressions
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29459

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

MK: current statement is 
<<
Arrow expression (XPath 3.1)	See 19.8.8.13 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:
<<
19.8.8.10 Streamability of Dynamic Function Calls

Note:

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
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29460

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
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29460#c1



-------

Bug 29461  Clarify effect of document("") when the source stylesheet is not available at run-time
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29461


>From the F&O spec 
https://www.w3.org/XML/Group/qtspecs/specifications/xpath-functions-31/html/#func-static-base-uri
<<
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
https://www.w3.org/XML/Group/qtspecs/specifications/xslt-30/html/#func-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
https://www.w3.org/XML/Group/qtspecs/specifications/xslt-30/html/#uri-references

(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
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29462


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.

RESOLVED: bug closed as WORKSFORME.


-------

Bug 29463 A little too much prejudice in the algorithm of on-empty/on-non-empty
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29463

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

RESOLVED: closed 


-------

Bug 29467  Non-streaming fallback implementation of xsl:stream
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29467


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.
[break]

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
stylesheets.
Florent: processor option? behave as streaming processor or a non-streaming
processor. 
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.

SUMMARY:
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
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29468

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

ABr: a param has to be "public"

https://www.w3.org/XML/Group/qtspecs/specifications/xslt-30/html/#package-overriding-components

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
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29470

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
implementation.

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]

SUMMARY:
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.

-------
TEST SUITE BUGS:


Bug 20843  function-1902
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20843

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

-------

Bug 28926  merge with accumulators - no tests 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28926

needs tests

-------

Bug 28927  Tests for streamable stylesheet functions
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28927

Some tests exists, needs more

-------

Bug 29123  validation-0202
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29123

line 161, MK fixes it live with a for expression
RESOLVED FIXED

-------

Bug 29128  QT3 converter: load-xquery-module tests
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29128

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,
-5
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29129

RESOLVED FIXED

-------

Bug 29223  function-1025/1026 test implementation-defined behavior
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29223

Abel will revert his change as announced.


-------

Bug 29231  tests import-0001 and import-0002 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29231

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

-------

Bug 29233  package-017: duplicate function declaration
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29233

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
instruction.

-------

Bug 29235  package-101 - entry point
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29235

Already fixed, should be closed.

-------

Bug 29236 package-100, 101: extra empty <row> elements in output
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29236

Already fixed, should be closed.

-------

Bug 29302  expected error codes
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29302

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
respectively.
   => 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
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29305

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
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29379

ABr: if you want to use an initial mode on a package it must be public or
final.
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
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29423

WG agreed, already fixed, close.


-------

Bug 29447  math-3307
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29447

Already fixed, close.

-------

Bug 29448 accept-007 tries to override a final component but does not expect
an error
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29448

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