[Bug 25316] New: [XSLT 3.0] Streamabilty and numeric predicates

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

            Bug ID: 25316
           Summary: [XSLT 3.0] Streamabilty and numeric predicates
           Product: XPath / XQuery / XSLT
           Version: Last Call drafts
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XSLT 3.0
          Assignee: mike@saxonica.com
          Reporter: mike@saxonica.com
        QA Contact: public-qt-comments@w3.org

In the streamability rules for filter expressions and axis steps we give
special treatment to numeric predicates, which is useful because it establishes
that the result is a singleton and this can change the posture from crawling to
striding.

However, the only cases we detect are where the value is a numeric literal or a
variable reference whose declared type is numeric.

We can extend this a little bit easily by saying "a variable reference whose
static type is a subtype of U{decimal, double, float}".

It would be nice to allow ANY expression whose static type is a subtype of
U{decimal, double, float}. The only reason we can't do this is that we need to
rule out context-dependent expressions such as X[position()], which do not
necessarily evaluate to a singleton. But I think we now have the machinery to
do this. Specifically, we should be able to use a formulation such as:

Given E as B[P]; the result is a singleton if the static type of P is a subtype
of U{decimal, double, float} and neither P, nor any subexpression of P at any
depth (a) has E as its focus-setting container and (b) is a context item
expression, an axis expression, or a call on a focus-dependent function other
than last().

Furthermore, the current type analysis infers U{A} (rather than a numeric type)
for expressions such as $X + 1. For operators "+" and "-", the result is
numeric if either operand is known to be numeric. For multiplicative operators,
the result is numeric if both operands are known to be numeric. In fact one can
go further; it doesn't matter if the result is a duration, because a duration
has no effective boolean value and is therefore a type error if it appears in a
predicate; therefore any arithmetic expression used as a predicate will either
deliver a numeric result, or cause a type error, which means we can safely
assume that a filter expression whose predicate is an arithmetic expression
will either deliver a result with cardinality 0:1 or will fail.

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

Received on Thursday, 10 April 2014 21:07:11 UTC