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

…and thanks for your reply.

Out of interest: What’s your main reason for trying to avoid escaped
slashes in the JSON result? Is it “only” about better readability, or
about a technical problem, e.g. a JSON processor that cannot handle
backslashed slashes?

I’m asking because we already had a client who stumbled upon the
latter case. Back then, we also proposed the use of a character map
(very similar to Gerrit’s suggestion):

serialize(<json>/</json>, map {
'method': 'json',
'use-character-maps': map { '/': '/' }
})

On Mon, Mar 22, 2021 at 2:19 PM Hans-Juergen Rennau <hrennau@yahoo.de> wrote:
>
> 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

On 3/22/21, Hans-Juergen Rennau <hrennau@yahoo.de> 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
>
> It's so that </script> doesn't occur.
>
>
>
> --
> Liam Quin, https://www.delightfulcomputing.com/
> Available for XML/Document/Information Architecture/XSLT/
> XSL/XQuery/Web/Text Processing/A11Y training, work & consulting.
> Barefoot Web-slave, antique illustrations: http://www.fromoldbooks.org
>
>