Re: [Json] Proposed minimal change for duplicate names in objects

[Matthew Morley <[e-mail]>]

On Tue, Jul 2, 2013 at 7:25 PM, Paul Hoffman <[e-mail]> wrote:

> <chair hats on>
>
> Do either or both of these proposals work for people in the WG?
>
> --Matt Miller and Paul Hoffman
>
> The following are proposed minimal changes to make the JSON spec
> interoperable with respect to
> objects that have duplicate names.
>
> Proposal 1:
>
> In section 2.2 (Grammar -> Objects):
>   No change
> In section 4 (Parsers):
>   Add: "If a parser encounters an object with duplicate names, the parser
> MUST use only the last
>   name/value pair that has the duplicate name.
> In section 5 (Generators):
>   Add: "The names within an object SHOULD be unique."
>
> Proposal 2:
>
> Same as Proposal 1 *except* that a second sentence is added for section 4:
> "A parser that streams
>   its outputs MUST fail to finish parsing if it encounters more than one
> name/value pair with the
>   same name."
>

#1 I guess. Duplicate keys *SHOULD* fail, IMHO.

I feel like I am being disruptive by posting this, but I really think we
are going down a path of splitting hairs and missing the broader point of
this issue. All the same, I'm posting as a reply to the initial thread
post, instead of all along the chain of replies.

Perhaps I'm in the minority, but I don't want to see the validation around
this split depending on the style of the decoding code. "Use the last
value, except if you stream then fail" seems a strange position to hold.
Failure should be a correct behavior in general.

The meaning of *SHOULD* for unique keys within the specification provides
enough of an expectation about the behavior, as well as a warning for those
that "weighed" the choice to not follow it. *MUST* would have been better,
but the complications we have been discussing are reasonable to expect and
predict.

Relying on ordered behavior in addition to duplicate keys, within a
knowingly unordered structure that *SHOULD* have unique keys is clearly
grounds for reasonable interop. errors and issues. "Clever" uses for this
small gap in behavior changes do not warrant protection.

Are there really legitimate uses of duplicate keys that should be honored,
warrant this protection, and the level of effort going into this discussion?


As an aside, it seems to me that none of this removes the need for
streaming parsers to be aware of duplicate keys and to probably fail upon
encountering them within the scope of a not-yet-closed object. If valid
json should unique keys, parsers should fail on non-unique keys, stream or
otherwise.

A similar topic comes up with streaming json-rpc servers writers who are
trying this SAX style approach (usually with batch requests), and the
reality has always been that it must be valid json first. This means you
cannot fully process the data with confidence until you confirm the payload
is actually valid json. Doing otherwise is simply betting
against fulfillment of the JSON format. If you can isolate the impact of
the changes, process away until you can confirm, then merge those changes
into the world. Otherwise, you need to be prepared to strike the actions
from having an impact.


Duplicate keys also prevent the use any meaningful path style strings, that
are to be used as an either an reference point or as an identity/location
token within and across objects (JSON Pointer for example). If your json
object produces more than one value for an identity, that is concerning.

Perhaps I'm just in shock that `json` is pondering new wording to handle
something that clearly comes with such complications and disagreement in
practice. Rather than promoting the behavior that is less complicated
conceptually and clearly intended.

-- 
Matthew P. C. Morley