This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Created attachment 1558 [details] Streamability analysis for streamable function calls This bug report is related to bug 25679 and action item ACTION-2014-10-16-005. The resolution of bug 25679 seems to have not (yet) been completely implemented in the spec, esp. comment#3 (which refers to comment#1). The essence of this change was to allow more input postures to a function without changing the default posture of the streamed parameter. Two things: 1) the new rules have not been fully implemented, leading to incomplete analysis 2) other arguments of the function call are not part of the streamability analysis (essentially, they follow the default streamability rules) In a private conversation with Michael Kay I proposed one solution that I believe works, provided here for reference. An alternative solution is also still in the mail (which changes less words) but I wasn't 100% it was correct (this proposal I believe is correct).
Created attachment 1577 [details] Editable updated attachment During the F2F of February 16, 2015 (Member only: https://lists.w3.org/Archives/Member/w3c-xsl-wg/2015Feb/0008.html) we went in detail over the proposal and the intricacies involved. The added Word document is an edited and expanded version of the original PDF, edited with the Working Group to make it in line with the findings of the F2F discussion and turn prose into spec prose where applicable.
Resolved as per the revised text in the attachment dated 2015-02-17.
Not also, as noted in the minutes but not in the attachment, we decided to move the streamable="yes" attribute from the xsl:function element to the xsl:param element defining the parameter that accepts streamed input.
I am re-opening because two problems have been found in the proposed solution. Firstly, the rules for computing the streamability of a stylesheet function allow it to be streamable in the case where the sweep is consuming and the posture is roaming, provided the result is atomized. For example a function with an atomic return type whose body is //section/head[1] might fall in this category: this is not streamable because of document order. Secondly, the proposed rules for determining the posture and sweep of a function call require analysis of the body of the "target" function. The concept of the "target" function is not properly defined, and is non-trivial in the context of the package binding rules, xsl:override, etc. The attempt to deetermine whether the target function is recursive doesn't properly handle attempts to overrids the target function in a using package. There's no description of what happens if the function is abstract. I attach a revised proposal. This is more restrictive, mainly by requiring the return value of a streamable function to be grounded. It still allows both motionless and consuming functions, by requiring the user to assert this distinction in the function signature, and preventing this property eing overridden.
Created attachment 1580 [details] New v3 proposal
Comments on the proposal after implementation into the new current internal WD can be found here: https://lists.w3.org/Archives/Member/w3c-xsl-wg/2015Mar/0018.html (member only) and have been discussed at the latest telcon, see minutes: https://lists.w3.org/Archives/Member/w3c-xsl-wg/2015Mar/0022.html (member only).
After those comments were implemented, a few (minor) bugs and typos were found and reported by mail: https://lists.w3.org/Archives/Member/w3c-xsl-wg/2015Mar/0025.html (member only). These bugs were discussed during the telcon of 19 March, minutes here: https://lists.w3.org/Archives/Member/w3c-xsl-wg/2015Mar/0039.html (member only) and accepted. In summary this means that variable references that can be bound to a streamed node must not be grounded, but should be striding (similar to fn:current or ContextItemExpr), and to consider whether or not the Singular column is needed or a duplicate of already existing logic on higher-order constructs (other mentioned bugs were purely editorial).
After much discussion on the mailing list and in telcons, this facility is now in the spec with an agreed specification. The bug report is therefore closed.