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, 02 Mar 2017 16:46:30 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-30064-523-H6FVcbUVsn@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=30064

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

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

--- Comment #1 from Abel Braaksma <abel.braaksma@xs4all.nl> ---
I am not sure this should be considered a rooted expression when we assess it
as a scanning expression (but see my own analysis).

I think this is an omission. Esp. since here $node has the role of . (context
expr) and I see the same expression going wrong when written as ".//section//p"
(with CP striding). I doubt that was the intent here, but I have to admit my
memory is rather fuzzy.

What I basically don't get if you have A/B/C and A is an expression with
striding posture, but is not a pattern, that A/B/C will fail even if only B/C
is a scanning expression:

/A//B  -> fails, it is a rooted expr, even if context is root
outermost(X//Y)//Z -> fails, even though outermost(X//Y) is striding
.//B[name() = 'foo'] -> fails, "." is not allowed in a pattern

I think some of these also fail because we have to rewrite X//Y for the
analysis, leading invariably to a roaming expression (child axis upon crawling
CP).

I think we need something in the text that says "in a RelativePathExpr A/B
where A has striding posture and B is a scanning expression, the result is
crawling/consuming".

==================================

re-analysis:

I tried from a different angle for analysis, but with the current text (and the
previous draft!) I come to similar conclusions as you, but with some trouble
near the end.

We say in 19.8.8.8, first item:

1) 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. 

We start this analysis with "$node" from "$node//section//p":

Step 1: $node is striding and motionless for deep-descent (19.8.5.6)

Then we analyze "//section" with CP from step 1, i.e. like
[striding/motionless]/descendant-or-self::node()/section

Step 2a) "[CP]/descendant-or-self::node()" with CP=striding, gives
crawling/consuming (19.8.8.9)

Step 2b) [CP]/section, with CP=crawling, gives roaming free/ranging

At this moment, section 19.8.8.8 kicks in, as this is the "provisional
posture". 

Now the rules are unclear, because the text does not say that we need to assess
the expression as a whole. If we don't then we can consider "section//p"
separately, but we would still have trouble with "//section", because it is
rooted (and not because it is preceded by $node).

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Thursday, 2 March 2017 16:46:39 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 2 March 2017 16:46:39 UTC