Problems with QName hash-codes in trieWithCollation()
In cases where the key for a map entry is a
QName, rather than 'string-like', a hash function wasn't being assigned. This requires some careful alterations to the logic in
#1 Updated by Michael Kay 10 months ago
There are two further problems here:
(a) for non-string keys, we are treating keys as equal if their hash codes are equal.
(b) For QNames, we have a very poor hash function, specifically:
return this.uri.substring(this.uri.length - 3) + ":" + this.local.substring(0, 3);
A better one would be
return this.uri.substring(this.uri.length - 3) + ":" + new XdmString(this.local).hashCode()
Test case: try grouping elements by node-name() where there are elements whose names don't vary in the first four characters.
#3 Updated by Debbie Lockett 10 months ago
- Found in version deleted (
trieWithCollation is new development code since the release of Saxon-JS 1.0.0.
It may be worth testing whether the same bug arises when grouping by element name using Saxon-JS 1.0.0. Or whether it is just now broken in the development version. (For now I'm declassifying this bug from being 'found in version Saxon-JS 1.0.0'.)
#4 Updated by Debbie Lockett 8 months ago
- Status changed from New to Resolved
XSLT 3.0 test for-each-group-082 added.
Saxon-JS code fixes:
1. Atomic.XdmQName.hashCode updated as suggested in (b).
2. New method matchKey() added to all classes for primitive types. matchKey() returns a string representation of the value, such that
!(a.equals(b)) implies (matchKey(a) != matchKey(b))
i.e. the matchKey strings are always different for different values. (Note that this condition is not always true for hash codes, so they are not always suitable.)
matchKey() can then be used by matchFn() in Compare.trieWithCollation.
Please register to edit this issue