Re: [Json] Counterproposal #2 on work items

Vinny A <jsontest@yahoo.com> Thu, 21 February 2013 04:02 UTC

DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=m1mur2sn/a7hs3ivf+/mJsMpBVKjFo8izDhBbv6uNGwx7eNyRnLgy2/z6hWohYzrSyQD7wqt5bWxUbqs1uJ1R5ly6V68WjLxHIvwmiIsePuZL71vmbG6+IW/ldV+DIHx3CH/L2hKoaWZszSyKMM64CtdIYEcV7L0ygI9Kdn/4lM=;
References: <CALcybBC87P7FT7n5d8xmXMxSFU1LBS9eJUsRX4hfYP5CUJr3QA@mail.gmail.com> <A723FC6ECC552A4D8C8249D9E07425A70F89B751@xmb-rcd-x10.cisco.com> <CALcybBBSL3w1-JRzUVWMmfS+jzytKNOv6omD1cR+_CLjze6WsA@mail.gmail.com> <12CE5BFB-49C5-48D0-96DF-F78F0D60578A@yahoo.com> <CALcybBCJ=z6u=1CGURB4ECoOaOA1igDy0H64fRm5Sj1HWQcRCg@mail.gmail.com>
Message-ID: <1361419333.51990.YahooMailNeo@web125604.mail.ne1.yahoo.com>
Date: Wed, 20 Feb 2013 20:02:13 -0800
From: Vinny A <jsontest@yahoo.com>
To: Francis Galiegue <fgaliegue@gmail.com>
In-Reply-To: <CALcybBCJ=z6u=1CGURB4ECoOaOA1igDy0H64fRm5Sj1HWQcRCg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-685807438-367120970-1361419333=:51990"
Cc: Tim Bray <tbray@textuality.com>, "Joe Hildebrand (jhildebr)" <jhildebr@cisco.com>, "json@ietf.org" <json@ietf.org>
Subject: Re: [Json] Counterproposal #2 on work items
Precedence: list
Reply-To: Vinny A <jsontest@yahoo.com>

> On Feb 20, 2013, at 2:39 PM, Francis Galiegue <fgaliegue@gmail.com> wrote:
>Isn't that org.json? I recall having seen that as well... I know for sure that Jackson picks the last key/value pair. But the problem is indeed that the "append to an array" parser does nothing illegal per se -- basically, as RFC 4627 stands today, the behaviour of parsers with regards to duplicate object member names is undefined.

I believe org.json throws a exception if it hits a duplicated key; at least the documentation [ http://json.org/javadoc/org/json/JSONObject.html#JSONObject(java.lang.String) ] suggests that to be the case. I don't remember where I saw the append to array parser - but it's such a good idea it's worth bringing up in this conversation.

>And some existing I-Ds, such as JSON Patch, as a result, have felt compelled to say that a JSON Patch operation, for instance, must have one and only one member named "op". Which imposes constraints on _parsing_ that RFC 4627 does not...

Which is precisely why I'd like to see a recommendation regarding duplicated keys. To be honest, I like the idea of array conversion, but I can understand if others dislike it. I work with JSON quite a bit, and it would be nice to be able to point to a documented, recommended spec.

-----------
-Vinny A

[Json] Counterproposal #2 on work items Tim Bray
Re: [Json] Counterproposal #2 on work items Francis Galiegue
Re: [Json] Counterproposal #2 on work items Tim Bray
Re: [Json] Counterproposal #2 on work items Joe Hildebrand (jhildebr)
Re: [Json] Counterproposal #2 on work items Francis Galiegue
Re: [Json] Counterproposal #2 on work items Joe Hildebrand (jhildebr)
Re: [Json] Counterproposal #2 on work items Francis Galiegue
Re: [Json] Counterproposal #2 on work items Philipp Kewisch
Re: [Json] Counterproposal #2 on work items Joe Hildebrand (jhildebr)
Re: [Json] Counterproposal #2 on work items Vinny A
Re: [Json] Counterproposal #2 on work items Francis Galiegue
Re: [Json] Counterproposal #2 on work items Robert Sayre
Re: [Json] Counterproposal #2 on work items Vinny A
Re: [Json] Counterproposal #2 on work items Cyrus Daboo
Re: [Json] Counterproposal #2 on work items Robert Sayre
Re: [Json] Counterproposal #2 on work items Tim Bray
Re: [Json] Counterproposal #2 on work items Robert Sayre
Re: [Json] Counterproposal #2 on work items Paul Hoffman
Re: [Json] Counterproposal #2 on work items Joe Hildebrand (jhildebr)
Re: [Json] Counterproposal #2 on work items Paul Hoffman