Bug #4134
closedXQuery: default collation and starts-with causes fatal error cannot be cast to net.sf.saxon.lib.SubstringMatcher
100%
Description
When default collation
is declared, using starts-with
function with two parameters, i.e. starts-with($arg1, $arg2)
, causes the error net.sf.saxon.expr.sort.SimpleCollation cannot be cast to net.sf.saxon.lib.SubstringMatcher.
There are two solutions:
- removing default collation declaration
- adding collation argument to
starts-with
function, for examplestarts-with($arg1, $arg2, "http://saxon.sf.net/collation?lang=cs-CZ")
I would expect that default collation
is used for comparison within starts-with
function without "redefining" it.
Am I wrong?
Example file with commented code is attached.
Files
Updated by Michael Kay almost 6 years ago
Thanks for reporting it. There's logic for handling substring matching using such collations when explicitly specified in the argument to substring(), but the logic is missing for the case where it's the default collation.
By the way, I would suggest that you switch to using the standardized collation URIs such as
http://www.w3.org/2013/collation/UCA?lang=cs-CZ;fallback=yes
in place of the Saxon-specific collation URIs.
I have to say that I have found the effect of using functions like starts-with()
and contains()
with collations that ignore some characters like spaces and hyphens pretty hard to comprehend.
Updated by Michael Kay almost 6 years ago
- Category set to Internals
- Status changed from New to Resolved
- Assignee set to Michael Kay
- Priority changed from Low to Normal
- Applies to branch 9.9, trunk added
- Applies to branch deleted (
9.8) - Fix Committed on Branch 9.9, trunk added
Fix committed on the 9.9 and development branches.
Updated by Michael Kay almost 6 years ago
Added test cases to QT3 test set "prod-DefaultCollationDecl" and to XSLT3 test set "collations"
Updated by O'Neil Delpratt over 5 years ago
- Status changed from Resolved to Closed
- % Done changed from 0 to 100
- Fixed in Maintenance Release 9.9.1.2 added
Bug issue fixed in the Saxon 9.9.1.2 maintenance release.
Please register to edit this issue