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

[John Cowan <[e-mail]>]

Stefan Drees scripsit:

> "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.

"Deserves to lose" is an idiom meaning "deserves the unfortunate
consequences of one's actions."

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

My view is that this application design (as opposed, say, to using an
array of single-element objects) is an inappropriate way to use JSON,
depending as it does on a feature (support for duplicate names) that is
not widely provided.

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

It's not much more convenient than [{"Stefan" : "male}, {"Stefan" :
"native German", ...], which is entirely safe.

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

True.  I wanted it to represent in a machine-processable way all the
information in your version (which is not very machine-processable).

-- 
Overhead, without any fuss, the stars were going out.
        --Arthur C. Clarke, "The Nine Billion Names of God"
                John Cowan <[e-mail]>