On Wed, Jan 18, 2017 at 03:38:17PM +0100, Sven Van Caekenberghe wrote: > So talking only about the encoding/writing phase, the conclusion would be
10. Generators A JSON generator produces JSON text. The resulting text MUST strictly conform to the JSON grammar. I guess the ABNF table is the best reference; but we want to generate the most compact form available (=that still conforms to the syntax). > - not to escape $/ For covenience's sake compact is better * I guess the speciality of \/ is somehow related to JavaScript strings interpreting both '/' and '\/' into '/'? > - escape everything with code points [0,31], using named escapes if they > exist, else \uHHHH yes, the named ones have Pharo equivalent too s := STON fromString: '"\b\f\n\r\t"'. s asArray "{Character backspace. Character newPage. Character lf. Character cr. Character tab}" > - escape $\ itself yes > > That leaves the question about $' and $". > > $' is used in STON as string delimiter, so it has to be escaped. > > - escape $' We already had discussion about $' and JSON http://forum.world.st/STON-doesn-t-produce-valid-JSON-it-shouldn-t-escape-quation-mark-td4923777.html It must not be escaped in JSON, but that raises question about STON being superset of JSON; is such thing achievable given this disparity? > > Right now, $" is also escaped. Should that remain the case, or only in JSON > compatibility mode (where $" is used as string delimiter) ? > > - do not escape $" > > In JSON mode, escape $" and not $' then ? That's how it should be in JSON. > When parsing, all named and other escapes are always accepted, as they are > now. 9. Parsers A JSON parser MUST accept all texts that conform to the JSON grammar. A JSON parser MAY accept non-JSON forms or extensions. My question about STON and JSON: What is the benefit of STON being superset of JSON? To me it feels like an arbitrary restriction for STON; would STON benefit from dropping this requirement and instead only worry about good smalltalk object representation? (And leave JSON to NeoJSON or something.) Peter > > On 18 Jan 2017, at 15:25, Peter Uhnak <i.uh...@gmail.com> wrote: > > > > On Wed, Jan 18, 2017 at 11:11:06AM +0100, Christophe Demarey wrote: > >> > >>> Le 18 janv. 2017 à 09:51, Sven Van Caekenberghe <s...@stfx.eu> a écrit : > >>> > >>> Hi Christophe, > >>> > >>>> STON toString: 'g...@github.com:foo/bar.git’ => > >>>> ''g...@github.com:foo\/bar.git’' > >>>> It used to be ''g...@github.com:foo/bar.git’’. > > > >>> In other words, it was an implementation error (omission). Note that JSON > >>> also has this escape. > > > > Yes and no for JSON. > > > > Only " and \ has to be escaped. Escaping anything else will give it special > > meaning with the exception of / which will just produce the same thing, > > because it is a special snowflake. :) > > > > quoted from https://tools.ietf.org/html/rfc7159#section-7: > > > > - Unicode characters may be placed within the quotation marks, except for > > the characters that must be escaped: quotation mark, reverse solidus, and > > the control characters (U+0000 through U+001F). > > - Alternatively, there are two-character sequence escape representations of > > some popular characters. > > > > "/" (U+002F) doesn't fall into control character range, but the alternative > > section does permit it escaping it. > > > > In other words, JSON strings "\/", and "/", and "\u002f" are equivalent. > > > > But JSON itself doesn't require you to escape "/" (just like you are not > > required to escape "hi" into "\u0068\u0069", although you can). > > > > Note that other systems do not escape / by default: > > > > (Pharo) > > NeoJSONWriter toString: 'g...@github.com:foo/bar.git' => > > "g...@github.com:foo/bar.git" > > > > (JavaScript) > > JSON.stringify('g...@github.com:foo/bar.git') => > > "g...@github.com:foo/bar.git" > > > > (Ruby) > > require 'json' > > puts 'g...@github.com:foo/bar.git'.to_json => "g...@github.com:foo/bar.git" > > > > Peter > > > >