Re: [Json] Proposal: the minimal edit

[Carsten Bormann <[e-mail]>]

On Jun 25, 2013, at 07:45, Tim Bray <[e-mail]> wrote:

> I just can’t bring myself to see it that way.  Any reasonable person would read this statement in the introduction and conclude that a string is, you know, a sequence of Unicode characters.  The fact that the ABNF later on contradicts this does not “supplement” the introduction, it’s just a spec-drafting goof.  

I really have no idea where the "contradict" meme comes from.
(Well, actually, I do, see below.)

I'm much more interested in getting interoperability right than in
language lawyering, but where we are arguing from the existing specs,
we do have to read them right first.

Not trying to express every constraint in the ABNF is reasonable spec economy.  
Why try to express clumsily in the ABNF what can already be said referencing a well-defined concept?

Try writing the ABNF for surrogate pair escapes and you'll see what I mean.
(Sure, it *can* be done.  Would you want to?)
The specific objective of the ABNF here was to explain what must be escaped for *JSON* reasons.
Re-encoding the Unicode spec in the ABNF apparently wasn't the objective.

I'm writing this mainly because I have had to make the same kind of decision before:
Encode all possible restrictions in the ABNF or keep it readable?

Again, not everything allowed by the ABNF is a valid instance of the format.
I'm not aware of any usage of ABNF where that would be the case.
You always have to read the rest of the specification, too.

> This is reflected in the empirical reality that in JSON's sweet spot, chiefly in the kind of network protocols the IETF cares about, JSON strings are de facto used to interchange sequences of Unicode characters, and reasonable developers would regard a failure to do so, even though blessed by the spec, as a bug.

That is an important reality.
(It is hardly derived from a careful reading of RFC 4627, however.)

Our problem in this WG really is that this is only part of the reality.

There is another community that believes JSON is a format proprietary to JavaScript, so whatever is common (even if bad) practice in the JavaScript world needs to be within the JSON envelope.  Of course, if you believe that, you will grasp for straws like this "contradiction".
That clash of communities is why we even have the discussion here.  

Grüße, Carsten