- From: Carine Bournez <carine@w3.org>
- Date: Tue, 16 Feb 2016 16:49:35 +0000
- To: public-xsl-wg@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