This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This test expects true. However, in http://www.w3.org/TR/xmlschema-2/#nt-WildcardEsc the wildcard "." is listed as being equivalent to [^\n\r]. The comment in this test seems to directly contradict this. Compare with fn-matches-43. <test-case name="fn-matches-45"> <description> "." does match CR in default mode</description> <created by="Michael Kay" on="2012-01-13"/> <test>fn:matches(concat('Mary', codepoints-to-string(13), 'Jones'), 'Mary.Jones')</test> <result> <assert-true/> </result> </test-case>
The test is to highlight that (for reasons unknown to me) the XPath definition here is different from the XSD definition. 5.6.1.1 says: If the s flag is not specified, the meta-character . matches any character except a newline (#x0A) character. We can pursue this as a spec bug if you wish. One could argue that it contradicts the statement in 5.6: "The regular expression syntax and semantics are identical to those defined in [XML Schema Part 2: Datatypes Second Edition] with the following additions:" and that 5.6.1.1 is not trying (or should not try) to be normative about what happens in the absence of any flags.
As suggeseted, I've changed this bug report to be against the 3.0 specification.
The WG decided to solicit information on how existing implementations (including XQuery 1.0 implementations) handle this test case before making a decision.
The WG agreed to align the spec with XSD: that is, "." matches everything except CR and NL. This change will be made for 3.0. The question of an erratum for the XPath 2.0 version of the spec remains open; we will add this to the informal list of candidate errata being maintained by the editor.
The 3.0 spec has been updated to reflect this change; a note has been added to the list of candidate errata for 1.0/2.0. The test case fn-matches-45 has been updated to reflect the resolution. I am therefore marking this bug as closed.