[Json] Upgrading SHOULD to MUST

[Paul Hoffman <[e-mail]>]

On Feb 18, 2013, at 5:12 PM, Joe Hildebrand (jhildebr) <[e-mail]> wrote:

> On 2/18/13 5:26 PM, "Bjoern Hoehrmann" <[e-mail]> wrote:
> 
>> * Joe Hildebrand (jhildebr) wrote:
>>> A *very* important goal would be to minimize change, and to ensure strict
>>> backward-compatibility.
>> 
>> A Working Group will also likely have to look at revising the rules to
>> detect the character encoding in application/json resources (there is a
>> lack of consensus whether to auto-detect UTF-32 and whether to honour a
>> Unicode signature, whether to support UTF-32 when it is detected, and so
>> on, partly due to how people load JSON resources; a generic "load text"
>> API for instance might detect and remove a Unicode signature before the
>> data is passed to a JSON parser; this used to be true for XMLHttpRequest
>> for instance, I haven't checked the current situation there though).
> 
> (individual)
> 
> Yeah, that probably needs to be dealt with.  If 4627 had been written as
> "JSON SHALL always be encoded as UTF-8 when transmitted or stored", then
> this would not be a problem.
> 
> I wonder if it's too late for that?  
> If we said that the
> backward-compatibility rule was that any document that was valid 4627bis
> would be correctly parsed by a 4627 parser, going all-in on UTF-8 would be
> ok.  Since this is currently valid and proposed to no longer be valid:
> 
> {"foo": "bar", "foo": "baz"}
> 
> clearly the reverse is not going to be true anyway.

If we are supposed to be keeping backwards compatibility, then yes, it's too late. The same is true for changing SHOULD not have duplicate names in objects.

OTOH, if we want a cleaner standard going forwards, by all means let's take out the over-cautious SHOULDs, and make a clear statement in the Introduction where we changed the requirements.

I'm strongly in favor of the latter.

--Paul Hoffman