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

Stefan Drees <stefan@drees.name> Thu, 04 July 2013 05:38 UTC

Return-Path: <stefan@drees.name>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC42821F9EF5 for <json@ietfa.amsl.com>; Wed, 3 Jul 2013 22:38:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.799
X-Spam-Level:
X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 81XS9VU040bi for <json@ietfa.amsl.com>; Wed, 3 Jul 2013 22:38:24 -0700 (PDT)
Received: from mout.web.de (mout.web.de [212.227.17.11]) by ietfa.amsl.com (Postfix) with ESMTP id A8FBB21F9EF0 for <json@ietf.org>; Wed, 3 Jul 2013 22:38:22 -0700 (PDT)
Received: from newyork.local.box ([93.129.68.96]) by smtp.web.de (mrweb004) with ESMTPSA (Nemesis) id 0LyOuM-1U7vgP3WMw-015uHv; Thu, 04 Jul 2013 07:38:17 +0200
Message-ID: <51D50A46.6000501@drees.name>
Date: Thu, 04 Jul 2013 07:38:14 +0200
From: Stefan Drees <stefan@drees.name>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: John Cowan <cowan@mercury.ccil.org>
References: <B86E1D4B-1DC8-4AD6-B8B3-E989599E0537@vpnc.org> <CAK3OfOj3MNNhjwo2bMa5CgoqynzMRVvviBXC8szxt5D17Z7FDg@mail.gmail.com> <51D3C63C.5030703@cisco.com> <CAK3OfOg5ErNO5zozaCB-qchSaUb-dy4Da5b1KKJNTM0Bnpm+1A@mail.gmail.com> <51D3DC41.4020808@drees.name> <20130703165810.GF32044@mercury.ccil.org>
In-Reply-To: <20130703165810.GF32044@mercury.ccil.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:vovpNk7jDt3rFQcH1LhLOU0kOBBsPX8wUt100jnhtR2QKaVsfD9 B9fxRAUMTJZN9S3iR0oA2ONm18Zb/gVH5N57m1iR8Tp91b9Jg9ms5NRGWl/v4glI07w3T9a blxcFtlhis6Pl703jcAfdsabZm1ZIWRsOzyA/NpUvErj2YOQuxIIsPM9IJo7XDugnQJXtqX iphD+Kd3sBp1TWPC1oCvQ==
Cc: Nico Williams <nico@cryptonector.com>, Paul Hoffman <paul.hoffman@vpnc.org>, Eliot Lear <lear@cisco.com>, "json@ietf.org WG" <json@ietf.org>
Subject: Re: [Json] Proposed minimal change for duplicate names in objects
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: stefan@drees.name
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Jul 2013 05:38:29 -0000

On 2013-07-03 18:58 +02:00, John Cowan wrote:
> Stefan Drees scripsit:
>
>> JSON in the role of data interchange format allows at that point the
>> multiset use case. Bad behaviour IMO is when misusing this.
>>
>> The expectation, that the unordered list of names in a single object
>> must form a set and not a multiset is questionable.
>
> Nevertheless, anyone who generates JSON with duplicate names in order to
> represent a multimap deserves to lose, because many, many JSON parsers
> will simply throw away all but the last as an unintended consequence of
> their implementation strategies.

"lose" what? If this "anyone" (it) wants a self-describing robust form 
to interchange data, it will annotate it with metadata accordingly, 
publish the dictionary, or choose microxml or the like.

We might share the view, that many applications exchanging data do also 
share information that is not inside the data. It may well be a one to 
one communication, not necessarily a one to many.

A say sensor automat observing some features, serializing the extracted 
info into JSON and pushing this to another collecting automat first 
finds some name for the subject ("Stefan") than estimates from 
processing further, that this should be tagged with attribute A 
("male"), starts a json object (to wrap it), enters the first member 
"Stefan":"male", eventualy pushes the json text part upstream, processes 
next observation B "native German", notes it linked to the same subject 
as member "Stefan": "native German" and pushes ...

Why not leave this possibility open, more human like bots might act this 
way very conveniently, mixing some serial processing somewhere along the 
way.

Even I sometimes overwrite observations on other people in my personal 
storage ...

> I assume you mean a multimap rather than a multiset: a multiset would be
> most naturally represented as a JSON object whose values are integers
> representing the number of occurrences of a particular object in the
> multiset.  By the same token, the natural representation of a multiset
> is a JSON object whose values are arrays. whose order is semantically
> irrelevant.

hm, no, I wanted to focus on the "no-keyspace" not on what is associated 
with the names. Often a boundary condition enforces wrapping inside an 
object. It is often natural for me (as a person) to express my thoughts 
and feelings, but in some situation I better do not do it naturally.

>> {"Stefan":"male","Stefan":"native German","could not resist":true}
>
> {
>    "given name" : "John",
>    "gender" : "male",
>    "citizenship" : {"country" : "US", "source" : "jus soli"},
>    "ethnicity" : ["German", "Irish"],
>    "annotations" : {
>      "verbose" : true,
>      "machine-processable" : true
>    }
> }

That's very nice, John, thanks. But you gave it some thought, 
backtracked mayb, edited and it is very deep nested for a record missing 
the family name ;-) That could be some digested output of the receiving 
end in my "HumBotTalk" scenario above.

My "signature" was adhoc, expecting the JSON "reader" to strip the 
"last" member. The use case (described in more detail above) is more of 
the kind: Tag with a variable whatever (sha256 of an image?), associate 
predefined attributes with this "whatever" and push upstream as the 
analyzer detects.

{"Stefan":{"Greetings":true}}