Re: [Json] Proposed minimal change for strings

[Bjoern Hoehrmann <[e-mail]>]

* Manger, James H wrote:
>It is only "unnecessary dataloss" when you are certain a value will only 
>be handled by ECMAScript -- in which case relying on ECMAScript's 
>(reasonable) extension beyond JSON is ok.

This is not an ecmascript-specific problem. Environments that can encode
unpaired surrogates in the native string type are the norm; Perl can

  % perl -MJSON -e "print JSON->new->ascii->encode([chr(0xd800)])"
  ["\ud800"]

and as far as I am aware so can Java, C#, C++, Python, and many others,
and for many of them it is easy to create lone surrogates by accident.

>I think your previous paragraph provides the argument. If different 
>decoders can legitimately roundtrip, substitute, or fail on parsing an 
>unpaired surrogate escape than senders need to be warned (in big 
>flashing lights) of this non-interoperable behaviour. The best way to do 
>that is to exclude unpaired surrogate escapes from the specification of 
>JSON.

But receivers need to be warned that they will likely have to deal with
JSON documents with unpaired surrogate escapes in strings, and the best
way to do that is to include them in the specification...
-- 
Björn Höhrmann · mailto:[e-mail] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: [phone] · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/