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

[Stefan Drees <[e-mail]>]

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}}