W3C home > Mailing lists > Public > public-qt-comments@w3.org > February 2014

[Bug 24618] xsl:analyze-string and fn:analyze-string

From: <bugzilla@jessica.w3.org>
Date: Thu, 13 Feb 2014 11:58:46 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-24618-523-XIIw6nrIYV@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24618

C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |cmsmcq@blackmesatech.com
         Resolution|---                         |FIXED

--- Comment #2 from C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com> ---
We discussed this issue in Prague.  By "adding a relation" between the two, the
bug report means demonstrating their equivalence by showing that the one can be
implemented in terms of the other.  Some expressed the view that either could
be implemented in terms of the other (at least in the sense that a stylesheet
using either could be rewritten to a stylesheet using the other).

Some WG members felt that the only really important relation here was that they
are two approaches to providing similar functionality; for that, a hyperlink
and some prose should suffice.  This has the advantage that it's unlikely to
elicit bug reports about corner cases.  

Note also that xsl:analyze-string supports zero-width matches, while
fn:analyze-string() doesn't.  FG has sent mail to the discussion list with an
example which can be done in fn:analyze-string() but not (or not conveniently)
in xsl:analyze-string:  fn:analyze-string returns information about position of
captured substrings, which would be impossible in the general case to recreate
with xsl:analyze-string.

MoZ suggested that capturing such lack of equivalence would also be interesting
for the note.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Thursday, 13 February 2014 11:58:47 UTC

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