Oh, thank you, Christian - only now I understand the option "escape" of json:serialize (do I?)! I thought it was about how to *represent* the input characters (apply optional escaping or not), but in fact it is (also) about how to *interpret* them - interpret them in the XDM way (escape=yes) or interpret them in the JSON way (escape=no). An experiment made it clear: with "escape=yes", input text "a\nb" represents 4 characters, serialized into "a\\nb"; whereas with escape=no, "a\nb" represents 3 characters, serialized into "a\nb". Understood, this enables to construct JSON text with JSON escaping, and retain this representation when serializing.

So serialization via json:serialize does currently not foresee a possibility to control whether or not to use optional escaping in the output - / is escaped, relentlessly. If I'm not mistaken, neither does fn:serialize offer an option for that . But as Gerrit pointed out, escaping can be controlled via fn:serialize with serialization parameter "use-character-maps".

Alright - "escape=no" means that *all* responsibility for escaping is taken over by the caller, which explains the present behavior and its "refusal" to escape quote and backslash! I agree, in case of invalid JSON an exception would be better than the silent construction of invalid JSON.

Thanks a lot for explaining!

Hans-Jürgen

Am Montag, 22. März 2021, 13:14:12 MEZ hat Christian Grün <christian.gruen@gmail.com> Folgendes geschrieben:

Dear Hans-Jürgen,

> 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.

The JSON options have been designed to improve bidirectional
conversions: The option can be supplied to preserve the original
escape strings (which can e.g. be helpful if the input data is
invalid). The same options should be used for parsing and serializing
data.

But I completely agree, we shouldn’t allow users to create invalid
JSON. It may be better to raise an exception if the serialization of
data with the supplied options would lead to corrupt output?

Best,
Christian

>
> 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.
> >