W3C home > Mailing lists > Public > public-qt-comments@w3.org > March 2017

[Bug 30064] [xslt30ts] Test case function-5006

From: <bugzilla@jessica.w3.org>
Date: Thu, 09 Mar 2017 17:00:27 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-30064-523-HDces9NWQ2@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=30064

--- Comment #3 from Michael Kay <mike@saxonica.com> ---
Let's first check exactly what the spec says.

19.8.5.6 says (for deep-descent functions):

Rules for the function body: For the function to be guaranteed-streamable, the
type-adjusted posture of the function body with respect to the declared return
type must be crawling, and the type-adjusted sweep of the function body with
respect to the declared return type must be motionless or consuming.

The body of the function is effectively

$node//section//p

This is analyzed as

$node/descendant-or-self::node()
  /child::section
  /descendant-or-self::node()
  /child::p

So we start with XX = $node/descendant-or-self::node() which is a
RelativePathExpr.

19.8.8.8 tells us:

First, the provisional posture is determined as follows: The provisional
posture of the expression is the posture of the right-hand operand, assessed
with a context posture and type set to the posture and type of the left-hand
operand; and the provisional sweep is the wider of the sweeps of the two
operands.

19.8.5.6 tells us that the LH operand is striding and motionless.

19.8.8.9 then tells us that the RH operand is crawling and consuming.

Now we consider XX/child::section where XX is the expression we've just
analyzed.

19.8.8.9 tells us this has a provisional posture of roaming.

So we reassess $node/descendant-or-self::node()/child::section to see whether
it is a scanning expression. It conforms to the syntax of a pattern, but the
pattern is not motionless, because it contains a rooted path.

So the body of the function is roaming, so it is not guaranteed streamable.

Now, I'm sure it is possible to devise a change to the rules that make it
streamable. But I don't think we should do so. There is too much risk of
getting it wrong, and not enough benefit. Implementations can provide this as a
streamability extension if they wish.

There's then a question what we should do with the test. We could simply mark
it as expecting XTSE3430, or we could drop the test, or we could somehow label
it to say that it might be streamable if the processor supports streaming
extensions.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Thursday, 9 March 2017 17:00:34 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 9 March 2017 17:00:34 UTC