You are right, Gerrit - the desired output can be achieved using fn:serialize and the use-characgter-maps option: serialize($doc, map{'method': 'json', 'use-character-maps': map{'/': '/'}}) I had overlooked that, and it's good to know. I was speaking about function json:serialize, which does not support the option "use-character-maps". I still think option "escape=no" must not leave double quotes or backslashes without escaping, as it produces invalid JSON and a serialization function producing invalid output does not make sense to me. But as the use of fn:serialize is a work around, the matter is not urgent. Thanks, Gerrit! Kind regards,Hans
Am Montag, 22. März 2021, 08:49:59 MEZ hat Imsieke, Gerrit, le-tex gerrit.imsieke@le-tex.de Folgendes geschrieben:
What’s wrong with adding 'use-character-maps': map{'/': '/'} to the JSON serialization each time?
On 22.03.2021 08:05, Hans-Juergen Rennau wrote:
Good Morning, Liam, thank you very much for this precise link into the video, showing the "why" behind escaping slashes.
In spite of the incorrect "must escape", your previous post was key to me for understanding my error. It is absolutely crucial to understand that within the JSON model, "/" and "/" denote the same Unicode point. Therefore my talking about expected roundtripping behavior was simply wrong: you cannot expect, or achieve, roundtripping when there are alternative representations, as the choice of representation cannot be remembered. (Comparable with the choice of single or double quotes to delimit attribute values in XML.)
>>> NEW VERSION OF THE ORIGINAL "COMPLAINT" <<<
So now it seems to me that everything boils down to one REAL ISSUE, and one might look at it either as a bug or as a missing feature:
Currently, it is not possible to serialize JSON in unescaped form which is guaranteed to be *valid* JSON. The problem is that serialization option "escape" turns off ALL backslash escaping - not only the optional (like /) but also the mandatory ones: double quote and backslash. This means that the serialization option escape="no" may produce invalid JSON, and I regard this as a bug: only the optional escaping should be switched off.
If one disagrees and thinks it makes sense to offer a serialization which is potentially invalid JSON (difficult to imagine, though), then I regard the current situation as having a gap: we then need a further option switching off /optional/ serialization, but retaining mandatory escaping, in order to preserve valid JSON and safeguard unchanged information content.
SUMMING UP: can we have a possibility to serialize JSON with guarantee of correctness and without optional backslash escapes? Proposal: change the behavior of serialization option "escape=no", so that mandatory escaping is retained; alternative: add a further serialization option restricting backslash escaping to the mandatory cases.
Kind regards, Hans-Jürgen
PS: Default parser behaviour is perfect, as it is: every JSON character is represented by the same Unicode character, e.g. " becomes ", / becomes /, \n becomes 
.
Am Sonntag, 21. März 2021, 19:25:25 MEZ hat Liam R. E. Quin liam@fromoldbooks.org Folgendes geschrieben:
On Sun, 2021-03-21 at 18:06 +0000, Hans-Juergen Rennau wrote: > No, Liam, that is a misunderstanding - it *may* be escaped by a > preceding ,
oops, thanks! Altough i shuld note that it's sort of changed over time from recommended to "may" - but see e.g. for the rationale (Doug Crockford explains it in the first few second after the 6 minute point so that's where i've linked to):
https://www.youtube.com/watch?v=-C-JoyNuQJs&t=386s https://www.youtube.com/watch?v=-C-JoyNuQJs&t=386s
It's so that </script> doesn't occur.