W3C home > Mailing lists > Public > public-qt-comments@w3.org > November 2015

[Bug 29253] [XQ3TS] fn-matches-50

From: <bugzilla@jessica.w3.org>
Date: Wed, 04 Nov 2015 10:25:30 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-29253-523-PyBDLrSCIH@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29253

Michael Kay <mike@saxonica.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mike@saxonica.com

--- Comment #1 from Michael Kay <mike@saxonica.com> ---
I have yet to find a specification of how captured groups work that isn't
completely fuzzy around the edges, and our spec is no exception. It's useful to
have evidence of what other respected regex engines do (e.g. Perl, PCRE) as
prima facie evidence that there is a problem. 

I tried the online tester at https://regex101.com/ on p303 and this gives false
(our expected result) for Python and PCRE, but true for Javascript. It also
gives false in the Java JDK engine.

I can certainly see the logic for why it should be considered to match. The
counter-argument is probably that each captured group only has one value, it
does not have different values for different iterations of some outer
expression. But in the absence of a more formal specification, it's difficult
to give an authoritative answer.

For p908, the online tester gives false for all three engines, and also for
Java. The only engine I can find that returns true is the Saxon one (a
derivative of Jakarta). So I'll concede that one! The Jakarta engine has a
rather moronic interpretation of the rule that a captured group returns what
was matched by the last matching attempt, sometimes returning this even when
that matching attempt was not part of a complete match of the entire regex.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Wednesday, 4 November 2015 10:25:33 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 4 November 2015 10:25:33 UTC