Re: [Json] Minimal edit proposal, second round

[Carsten Bormann <[e-mail]>]

On Jun 26, 2013, at 17:47, Paul Hoffman <[e-mail]> wrote:

> there is disagreement about whether this document prohibits 

I'm not sure that we should have a standards track document where we can't figure out what it means.
(Explicitly stating that then just adds insult to injury.)

1) The confusion needs to be captured.

a) Then, if we really can't nail the specific items down, we at least need to say which alternative interpretations there are.
b) We probably need to give names to the various JSONs resulting, and 
c) specify them in enough detail that there is no further seed for divergence.

2) Simply always choosing the widest possible interpretation is exactly the way soup is being made.
In this context, condoning the widest possible interpretation is equivalent to choosing it. *)

3) The discussion MUST NOT be based on what weird interpretations can be assigned to existing words, but instead of what the interoperability implications are.

Grüße, Carsten

*) Today, if someone sends me a document with duplicate keys, I'll say "this has duplicate keys, can you send me valid JSON please?".  Once the standards track specification condones duplicate keys, that feature has effectively become part of "JSON", and (outside tightly managed environments) *all* receivers will have to adapt.  That is the soup process of protocol evolution at work.