Saxon » SaxonJS

This escaping is required by the W3C spec, and any JSON consumer should accept the output in this form, but I agree it's not universally popular. (I think the W3C justification was that an unescaped "/" causes problems in HTML script elements, though I can't say I fully understand the problem).

In the case of JSON serialization it's possible to switch it off using the rather cumbersome device of a character map that maps "/" to "/". But that doesn't apply here (unless you parse the JSON produced by xml-to-json() and then re-serialise it.... )

Post-processing using replace() is of course possible, but I don't think there's any other workaround at the moment.

Ah, okay! We can maybe try using replace() and check if its meeting our use case! Thankyou for your quick reply and help!

I've noticed an oddity in the rules for xml-to-json. It says

Strings are escaped as follows:

If the attribute escaped="true" is present for a string value, or escaped-key="true" for a key value, then:
...
any unescaped occurrence of quotation mark, backspace, form-feed, newline, carriage return, tab, or solidus is replaced by \", \b, \f, \n, \r, \t, or \/ respectively;
...
Otherwise (that is, in the absence of the attribute escaped="true" for a string value, or escaped-key="true" for a key value):
...
any occurrence of quotation mark, backspace, form-feed, newline, carriage return, or tab is replaced by \", \b, \f, \n, \r, or \t respectively;
...

Note that "/" is escaped in the first case but not the second. I find it hard to see any rationale for the difference, and I suspect it is an oversight.

See also https://github.com/w3c/qtspecs/issues/32

Ah! that is an interesting find, will also subscribe the git hub issue to see the updates! Thankyou so much for the findings!

Under issue #4860 we added an option number-formatter : function(string) as string to control formatting of numbers by xml-to-json. (Though we added it on SaxonJ only, it's equally applicable to SaxonJS.) I feel the right approach here might be a similar callback string-formatter that puts string formatting under user control. The only slight complication is that it might need a second argument to indicate whether the string is already escaped.

Having hit this myself yesterday, I'm now inclined to do it the easy way: just add an option escape-solidus=true|false.

Note that all the other characters we escape are characters that MUST be escaped to make it valid JSON.

Two things I observed when investigating this. First, if you put a literal bit of JSON in a select statement, the compiler does the escaping so the runtime option won't have any effect. Second, there seem to be a lot of places where this escaping occurs. I failed to find all of them, I'm sure.