Project

Profile

Help

Feature #4860

closed

Format of numbers generated by fn:xml-to-json

Added by Michael Kay almost 4 years ago. Updated about 3 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Saxon extensions
Sprint/Milestone:
-
Start date:
2020-12-18
Due date:
% Done:

100%

Estimated time:
Legacy ID:
Applies to branch:
10, trunk
Fix Committed on Branch:
10, trunk
Fixed in Maintenance Release:
Platforms:

Description

A customer writes saying they have a JSON application where the JSON parser can't handle numbers in scientific notation. I've heard the same problem before. We should add an option to the options parameter to disable scientific notation for number values.

Actions #1

Updated by Michael Kay almost 4 years ago

  • Status changed from New to In Progress

I propose to provide an option on xml-to-json():

map{'number-format': '0000.0'}

where number-format follows the rules of the picture argument to the fn:format-number() function.

A similar option on the JSON serializer is also appropriate.

Actions #2

Updated by Michael Kay almost 4 years ago

Having second thoughts on the design here. Making the property a format-number picture implies that we will still start by doing string-to-double conversion on the <number> element, which may not always be wanted. For example, it doesn't allow users to "stretch" what is allowed to appear in the <number> element (e.g. some might want to use a European-format number with a "," as the decimal separator, or to have more decimal digits than xs:double can accommodate.) And it restricts the reformatting that is possible, for example it doesn't give you the opportunity to output `"INF" or "NaN" (as JSON strings) rather than rejecting these as errors.

So I'm going to try an alternative design, where we add an option number-formatter whose value is a function(xs:string) as xs:string, which takes the number as it appears in the XML, and outputs the number as it will appear in the JSON (with no constraint that the result is valid JSON).

Actions #3

Updated by Michael Kay almost 4 years ago

I've added a proposal for this extension, and a draft spec, for the 4.0 project. I've added test cases to the qt4cg/qt4tests repository.

Actions #4

Updated by Michael Kay over 3 years ago

  • Tracker changed from Bug to Feature
Actions #5

Updated by Michael Kay over 3 years ago

  • Status changed from In Progress to Resolved
  • Applies to branch 10, trunk added
  • Fix Committed on Branch 10, trunk added

This appears to have been implemented as described on both the 10.x and 11 branches.

Actions #6

Updated by O'Neil Delpratt about 3 years ago

  • Status changed from Resolved to Closed
  • % Done changed from 0 to 100
  • Fixed in Maintenance Release 10.6 added

Bug fix applied in the Saxon 10.6 maintenance release

Please register to edit this issue

Also available in: Atom PDF