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

[Bug 29355] Modernize sequence filtering

From: <bugzilla@jessica.w3.org>
Date: Thu, 07 Jan 2016 15:30:27 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-29355-523-uWyMl2QrtJ@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29355

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

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

--- Comment #1 from Abel Braaksma <abel.braaksma@xs4all.nl> ---
> $sequence[-1] to get the last value
This would introduce a backwards-compatibility issue. It is currently legal
syntax and code and examples exists that exploit the fact that zero and
negative values return the empty sequence.

> Then you can at least do $sequence[2 to 4]
This I'd like, but I believe with XPath 2.0 there was a strong reason to
disallow sequences of more-than-one in predicates (FORG0006, EBV not defined
for sequences > 1).

Note: you can already do the following, which gives what you want and is
shorter than your alternative syntax:

$sequence[position() = 2 to 4]

> $sequence[2 to 10 by 3]
This would change the RangeExpr production (or, as you suggest as operator, the
infix operator productions). If it doesn't cause any EBNF conflicts (and the WG
agrees) this is viable, I think. I agree that it adds clarity to a certain
class of use-cases.

Given the previous rewrite, this can be rewritten as:

$sequence[position() = (2 to 10)[position() mod 3 = 1]]

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Thursday, 7 January 2016 15:30:30 UTC

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