This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
I have applied fixes to the following test cases in the test set fn-matches.re (file: matches.re.xml) and introduced new tests: re00126 - applied fn:not to the first fn:matches (i.e. matches('', '^(?:\n\na\n\nb\n\n)$') is never true). re00127 - Changed the dependency to XPATH 3.0+. Issues relating to the serialization of escape characters not matching pattern because of parser. re00127a - Introduced test case which is the same as re00127, but differs in that its dependency is XQuery 3.0+ only and test case is wrapped in a CDATA section. re00129 - same reasoning as for re00127 re00129a - Introduced test case which is the same as re00129. Differences: See re00127a re00130 - same reasoning as for re00127 re00130a - Introduced test case which is the same as re00129. Differences: See re00130a
Correction: re00130a - Introduced test case which is the same as re00130. Differences: See re00127a
I think that the tests re00127, re00129 and re00130 are dodgy. e.g. re00129 When extracted from the test suite XML file, the XML parser will present: <test>matches('a
b', '^(?:a\r\nb)$'), matches('ab', '^(?:a\r\nb)$')</test> as matches('a { the two-character sequence #xD #xA } b', '^(?:a\r\nb)$'), matches('ab', '^(?:a\r\nb)$') which is then further normalized according to "The XPath 3.0 processor must behave as if it normalized all line breaks on input, before parsing. The normalization should be done according to the choice to support either [XML 1.0] or [XML 1.1] lexical processing." to give matches('a { the one-character sequence #xA } b', '^(?:a\r\nb)$'), matches('ab', '^(?:a\r\nb)$')
I had never noticed that XPath 2.0 requires line breaks to be normalized. This is very unfortunate in an XSLT context, where it means that expressions such as xsl:value-of select="'
" no longer have the expected effect. This is an undocumented incompatibility with XPath 1.0 and XSLT 1.0, and I propose to raise a bug against the spec.
I have raised bug #14917 against the XPath specification.
I have changed the three tests is question so they now work whether or not the XPath processor normalizes line endings. (Getting a x0D into an XPath string required some ingenuity). A test for XPath line endings has been added elsewhere (misc-XMLEdition, for want of a better place).
I think test re00130 still contains an error. Shouldn't the remaining 
 in this be replaced with $d? <test> let $d := codepoints-to-string(13) return ( (every $s in tokenize('
'||$d||'a

b', ',') satisfies (matches($s, '^(?:\n\ra\n\rb)$'))) and (every $s in tokenize('', ',') satisfies not(matches($s, '^(?:\n\ra\n\rb)$'))))</test>
Agreed. Fix applied to test re00130
Confirmed fixed. Thanks.