Re: [Json] On characters and code points

[Stefan Drees <[e-mail]>]

On 2013-06-07 18:19, Tim Bray wrote:
> On Fri, Jun 7, 2013 at 9:15 AM, Stefan Drees ... wrote:
>
>     and what about { "Decorate my slash": "\/" } and "general-purpose
>     string processing software". Isn't this also a case, where you need
>     a "pre-conditioner" that replaces the JSON specific escape sequence
>     "\" with "/" before feeding it into "general-purpose string
>     processing software" :-?)
>
>
> Red herring.  JSON, just like XML, has ways to encode characters that
> are hard to type.  What we're arguing about is the actual content of the
> payload after the parser/pre-conditioner.  -T ...

I beg to differ. I probed the claim, that "general-purpose string 
processing software" would have problems with entity so-and-so but not 
with JSON text as is.

Also, when it comes to "typing" (as human-machine directed communication 
means) forward slashes, dot-ini files or YAML text in my experience are 
far more easy to type than JSON text ;-)

As John Cowan rightfully stated: "That[the general-purpose string 
processing software] would be the JSON parser." **but** it's task may be 
considered being anything from easy to hard.
We discuss here on these matters, so it's not a red herring, isn't it?



Personal motivation (if time and interest allow):

Any differences in expressing common "atomic" values or "core 
structures" (like type of inter atomic bindings) should be verified as 
each may introduce otherwise not needed hurdles or even traps in 
translation. It is data interchange we specify.

For a transformation source and target that look quite similar (as eg. 
JSON variables and corresponding language L "things") for some language 
L in (ECMAScript, PHP, Pyton, ...) one would expect, to not need any 
"heavy" lifting when transforming from one representation into another.

I observe, that "we programmers" more and more look at our code (esp. 
atomic variables and structures in some language L), compare these to 
the serialized (prettyprinted) JSON equivalent and then expect them to 
be essentially identical (some people even start to think eg. "JSON 
**is** Python syntax" as recently observed on the python-ideas mailing 
list when argueing in favour of a JSON serializer).

At least one should expect for a successful and proven data interchange 
format, that the atomic values simply "slip back and forth" and do not 
need special per-character handling.

So the more we extend basic escaping "C"ulture (as we further superset 
the C escape sequences), the wider this gap will become.

Interesting "structural" rule differences (not being candidate to 
change, I know) are:

* the trailing comma allowed (or even needed) in many programming
   languages for instances of list-like structures being not allowed in
   JSON objects nor arrays (I am sorry that this will not change)

* the JSON need for quoting the names (I am neutral here)

do bite us "machine instructing humans" once in a while, don't they?

The "might-look-like-a-babylonian" system of programming languages that 
evolved as solution attempts to the

* N humans instructing
* M machines with
* L languages utilizing
* F formats for data interchange or storage to handle
* P problems

is hopefully offering NP-complete solutions :-) but IMO some of the 
couplings should be reconsidered with passionate caution from time to time.

Maybe now is such a "time" to reconsider some regions of the space 
spanned by the cartesian product L x (F=JSON).

Thanks for reading this long opinionated message (which I also did 
before sending. Promised ;-)

Stefan.