[Bug 25679] [XSLT 3.0] Streamable stylesheet functions

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

Abel Braaksma <abel.braaksma@xs4all.nl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|CLOSED                      |REOPENED
                 CC|                            |abel.braaksma@xs4all.nl
         Resolution|FIXED                       |---

--- Comment #1 from Abel Braaksma <abel.braaksma@xs4all.nl> ---
-------------------
-- recap/summary --
-------------------

The essence of the proposal (1.e in 19.8.7.12) is that upon a call to a
stylesheet function, the sweep is the wider sweep of the streaming argument and
body of the function. 

A special exception (1.f) is made for recursive functions and non-final/private
functions which are considered "non-analyzable", with either a striding or
motionless argument, the result is striding and consuming.

---------------------------
-- motionless w/crawling --
---------------------------

This makes f:test(.//bar) with the following non-streamable:

<xsl:function name="f:exists" streamable="yes">
   <xsl:param name="n" />
   <xsl:value-of select="exists($n)" />
</xsl:function>

It fails because of rule 1.c, which disallows climbing/crawling arguments. I
think we can resolve this by:
- moving 1.c down to between 1.f and 1.e (non-analyzable functions)
- under 1.e we add "if the body is motionless and grounded, then grounded and
the larger sweep of the streaming argument and the body"
- under that we add "if the body is consuming and grounded and the streaming
argument is not climbing, then grounded and the larger sweep of the streaming
argument and the body"

----------------------
-- working examples --
----------------------

This works, because the posture of f:test() is the posture of the body of
f:test, which means that also the following is streamable:

<xsl:function name="f:grandparent" streamable="yes">
   <xsl:param name="n" />
   <xsl:value-of select="$n/ancestor::*[2]/name()" />
</xsl:function>

This works. Under 19.8.7.10 the new rule says that param refs are always
striding, but because path expressions that are crawling or string, then
climbing are motionless and because we force the result of the body to be
grounded, it is streamable and fits with existing rules.

Then this:

<xsl:function name="f:value" streamable="yes">
   <xsl:param name="n" />
   <xsl:value-of select="$n" />
</xsl:function>

would become consuming and grounded. Because we now allow crawling expressions
to be consumed in atomizing expressions (bug 25185) and because higher order
usage of the streaming argument is disallowed (19.8.7.10) this works for the
general case.

For any non-grounded function body, I don't think we can widen the rules, and
we should stick to the limitation of striding-in-striding-out.

----------------
-- Overriding --
----------------

The new rules effectively make it impossible to write an analyzable streamable
function in a library package that is not final. You could argue that a
non-final function can be overridden with a final signature, but that requires
copying the whole body (which may be hidden to the package user), because
reliance on the base function with a call on xsl:original() is not allowed (it
violates rule 1.d "contains a call to a potential caller of F).

I think this is too strict and I think we can completely loose the restriction
of non-final functions which makes the rules easier, allows abstract and
non-final, yet analyzable functions, by adding one rule in 10.3.5
(Streamability of Stylesheet Functions):

- an overriding function must have the same sweep and posture as its overridden
function

This rule might be better placed under "3.6.2.5 Overriding Components from a
Used Package".

----------------
-- some typos --
----------------

19.8.7.12, 1.c: "the the"
19.8.7.10: "U{N} (see specref ref="determining-static-type")"
10.3.5: missing closing paren in the last paragraph before the examples

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Wednesday, 4 June 2014 12:38:44 UTC