Saxon

If I do this from the command line:

java net.sf.saxon.Query -qs:"json-to-xml('1234567890')" -t

the output is

<?xml version="1.0" encoding="UTF-8"?>
<number xmlns="http://www.w3.org/2005/xpath-functions">1234567890</number>

Hello,

Could you please provide us an update regarding this issue.

Thank you in advance.

Best regards.

Indeed, running the output of xml-to-json through parse-json does "undo" the number formatting fix.

The JSON requirement to escape forward slashes is a frequent source of awkwardness.

I'm not immediately seeing a workaround that will accomplish both fixes, but I'll make sure we discuss it and see what we can come up with.

Thank you for your response.

we will wait for updates from your side.

Hello,

Any news regarding the issue ?

Best regards.

I would not rely for json serializer to escape or unescape values. Formally, it is the same data. E.g. we often deal with Hebrew and some json serializers decide to escape Hebrew text, some - not. It is pointless to appeal here.

Basically same story is with xmls, which in addition may reorder attributes.

Thanks for the explanation. What do you suggest to solve the problem and get the desired result.

I would suggest undoing the part

• serialize(map{ 'method' : 'json', 'use-character-maps' : map { '/' : '/' } }) that you intended to use to prevent escaping of '/';
• treat result string as json, which would mean that "\/" and "/" are the same values.

I'm afraid I can't offer any workaround with the current product that allows you both to control the number formatting, and to avoid escaping of "/".

In the 4.0 specs we have added an option escape-solidus="no" to the JSON serialization method (so you no longer need the workaround with character maps), and at https://github.com/qt4cg/qtspecs/issues/530 I have proposed we should also add this option to the xml-to-json() function.

I'm also going to propose that we add an option for number formatting to JSON serialization.

After attempting to specify a new number-format serialization property, I've come to the conclusion that it gets terribly complicated, and probably won't meet the requirements, because you actually want different formats for different numbers in the document.

The JSON serialization method already says that the processor can emit any format that's legal in JSON. So I think the simplest thing to do is to change the Saxon implementation to use exponential notation only in extreme circumstances, for example if the value to be output is an xs:double less than 1e-20 or greater than 1e20.

While looking into this, it also occurred to me that there is another workaround you could use: before serializing the output, transform it so that all the xs:double values are converted to xs:decimal. Saxon will not use exponential notation for xs:decimal values.