Bug #3216
closedError QNames are not ordered
100%
Description
The following XSLT snippet:
<xsl:when test="map:get($bindings,generate-id($in-node))=xs:QName('xs:date')">
<xsl:attribute name="type" select="'date'" />
</xsl:when>
Produces the following error in the browser:
XError {name: "XError", message: "QNames are not ordered at file:/Users/ond1/work/de…xon-dev/licensing/src/JStool/xsltforms-js.xsl#166", code: "FORG0006", stack: "Error↵ at new XError (http://localhost:8000/JSt…(http://localhost:8000/JStool/SaxonJS.js:6824:20)", xsltLineNr: "166"…}
This relates to the Compare.gc(lhsIter, rhsArray, op, comparer)
function in the Compare.js file.
Updated by John Lumley over 7 years ago
- Assignee set to John Lumley
- Found in version set to 1.0.0
- Applies to branch 9.7, 9.8 added
I don't have time just now to investigate in more depth (will do tomorrow) but the issue is tied up with an ordering comparison being used when an equality comparison is appropriate and may be in some portion of logic not being implemented correctly in Saxon-JS. (I've encountered this in the XPath compiler for xs:QName
and use the EQC comparer for such cases, so I understand the issue.)
Updated by O'Neil Delpratt over 7 years ago
As a workaround I am using the 'eq' operator which works fine.
Updated by Debbie Lockett over 7 years ago
- Status changed from New to Resolved
- Assignee changed from John Lumley to Debbie Lockett
Fix in Compare.gc method, so that when suitable (i.e. op is '=' or '!='), the comparer.equals method is used for making the comparison, rather than always using comparer.compare.
This bug was only showing up in the particular case that we are using "GAC" (general) comparison. In various other cases, at compile time a more specific comparison is already assigned (e.g. "EQC"), and in this case there is no error.
Updated by Debbie Lockett over 7 years ago
- Applies to branch deleted (
9.7, 9.8) - Applies to JS Branch 1.0 added
- Fix Committed on JS Branch 1.0 added
Updated by Debbie Lockett over 7 years ago
- Status changed from Resolved to Closed
- % Done changed from 0 to 100
- Fixed in JS Release set to Saxon-JS 1.0.1
Bug fix applied in Saxon-JS 1.0.1 maintenance release.
Please register to edit this issue
Also available in: Atom PDF Tracking page