W3C home > Mailing lists > Public > public-qt-comments@w3.org > July 2016

[Bug 29712] [xslt3.0] Why are streamable stylesheet functions required to be consuming?

From: <bugzilla@jessica.w3.org>
Date: Sat, 02 Jul 2016 08:08:53 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-29712-523-0MeilZJ5gb@http.www.w3.org/Bugs/Public/>

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

           What    |Removed                     |Added
                 CC|                            |abel.braaksma@xs4all.nl

--- Comment #4 from Abel Braaksma <abel.braaksma@xs4all.nl> ---
ACTION 2016-06-30-003: ABr to review bug 29712 in detail and determine whether
changing the rule would lead to inconsistencies or implementation issues.

I've been over previous mail and earlier bugs. I could recollect that we
removed the ability for variants of resulting posture (a filter must be
striding, grounded is not allowed). I can't recollect we did the same
consciously for the sweep of the body of the function.

I see no problem in allowing this and agree to Mike's assessments in the
previous comments.

A processor could, if they want, raise a warning, telling users they should use
there resources more carefully and choose inspect instead of absorb.

This does raise a related question though: why don't we make our lives a bit
simpler w.r.t. the rules. Some rules in this section would, for instance, be a
bit easier if we force users to use a type signature of U{N} for the return
types of filter, shallow-descent and deep-descent (the rules already require
the function body to return nodes).

(In reply to Michael Kay from comment #3)
> if (current-date() < xs:date('2000-01-01') 
> then sum($input/@value)
> else 0
> which has consuming sweep (the wider of the sweeps of the two conditional
> branches), but doesn't actually consume anything.
The wider of the sweeps here is dependent on the type of the parameter (does it
accept more-than-one?), which can then be either consuming or motionless.

You are receiving this mail because:
You are the QA Contact for the bug.
Received on Saturday, 2 July 2016 08:09:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:58:01 UTC