Project

Profile

Help

Bug #3383

closed

General Comparison in 1.0 compatibliity mode: cannot compare xs:string with xs:integer

Added by Michael Kay over 7 years ago. Updated about 7 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
-
Sprint/Milestone:
-
Start date:
2017-08-10
Due date:
% Done:

100%

Estimated time:
Applies to JS Branch:
0.9, 1.0, Trunk
Fix Committed on JS Branch:
1.0, Trunk
Fixed in JS Release:
SEF Generated with:
Platforms:
Company:
-
Contact person:
-
Additional contact persons:
-

Description

W3C test case boolean-069 fails saying "cannot compare xs:string with xs:integer".

We do not appear to have the logic in place to handle string-to-number comparison according to the 1.0 compatibility rules.

Actions #1

Updated by Michael Kay over 7 years ago

There seems to be some confusion as to whether we support 1.0 compatibility mode. In the documentation we say that we don't; but in that case we ought to reject stylesheets specifying version="1.0" (as Saxon-HE 9.8 now does). Any many aspects of 1.0 compatibility mode are in fact implemented. We need to decide one way or the other. There are good reasons for supporting it if we can, because we want to make transition easy for stylesheets written to run using native browser implementations of XSLT 1.0.

Actions #2

Updated by Michael Kay about 7 years ago

  • Status changed from New to In Progress
  • Fix Committed on JS Branch Trunk added

I have modified the "gc10" implementation so string-to-number conversion in 1.0-mode general comparisons is now working (and this test case passes).

Generally I think it is the case that we DO implement 1.0 backwards compatibility. A lot of the work (casting in the function conversion rules, extracting the first value of a sequence) is actually done at compile time - the SEF file contains the code to do the necessary casting. In the case of general comparisons, we had implemented some of the BC rules but not all. For arithmetic (arith10) we have code in place to implement BC semantics. There are a few other cases where BC comes into play, e.g. in xsl:number, but we should handle these on a case by case basis.

The documentation should say that 1.0 backwards compatibility IS supported.

Actions #3

Updated by Debbie Lockett about 7 years ago

  • Fix Committed on JS Branch 1.0 added

Fix also committed on 1.0 branch.

Actions #4

Updated by Debbie Lockett about 7 years ago

  • Status changed from In Progress to Resolved

Documentation (http://www.saxonica.com/saxon-js/documentation/index.html#!conformance/xslt30) updated to add XSLT 1.0 backwards compatibility to the list of optional features that are included.

Actions #5

Updated by Debbie Lockett about 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.2

Bug fix applied in Saxon-JS 1.0.2 maintenance release.

Please register to edit this issue

Also available in: Atom PDF Tracking page