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

[Bug 25316] [XSLT 3.0] Streamability and numeric predicates

From: <bugzilla@jessica.w3.org>
Date: Thu, 31 Jul 2014 13:40:21 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-25316-523-sthR1uhU42@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25316

Michael Kay <mike@saxonica.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #8 from Michael Kay <mike@saxonica.com> ---
The following proposal was accepted:

(A) in 19.8.7.8 change "For a filter expression of the form B[P]" to "For a
filter expression F of the form B[P]" 


(B) change rule 1 of 19.8.7.8 (Streamability of Filter Expressions) from

If B is crawling and consuming, and P is either a numeric literal, or a
variable reference whose 
static type is a subtype of U{xs:decimal, xs:double, xs:float}, then crawling
and consuming

to

If all the following conditions are satisfied:

* B is crawling;

* The static type of P is a subtype of U{xs:decimal, xs:double, xs:float}, and

* Neither P, nor any operand of P, at any depth provided it has F as its
focus-setting container, 
is a context item expression, an axis expression, or a call on a
focus-dependent function; [[it would be useful to explain the implications of
this rule]]

then striding and the sweep of B

(C) in section 19.2 (Determining Static Type), in the table entries for
AdditiveExpr and MultiplicativeExpr,
 qualify the current entries to say: "But if the expression is a predicate
(that is, if it appears between
  square brackets in a filter expression or axis step), then U{xs:decimal,
xs:double, xs:float}. 
  This type inference is possible because any other result of an addition or
subtraction [or multiplicative operation] within a predicate, for example an
xs:duration or xs:dateTime, would cause a type error, and static type inference
only needs to consider the type of non-error results.


Notes/examples:

(a) we don't recognize .//a[position() = 12] as striding - but this can be
rewritten .//a[12].

(b) we classify .//a[(1 to 5)] as striding, it actually throws a dynamic error,
but this doesn't affect the streamability analysis

(c) generally, give examples of where this analysis is helpful

In Streamability of Axis Steps, apply the same rules.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Thursday, 31 July 2014 13:40:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:47 UTC