This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
It would be good to add a relation between XSLT 3.0 xsl:analyze-string and F&O fn:analyze-string [1] http://www.w3.org/TR/xslt-30/#analyze-string [2] www.w3.org/TR/xpath-functions-30/#func-analyze-string
here is the email from the archive https://lists.w3.org/Archives/Member/w3c-xsl-wg/2014Jan/0011.html
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.
I have rephrased the introductory material at the start of section 17 to describe the relationship of xsl:analye-string and fn:analyze-string in more detail, replacing the existing note.