Re: [Json] On flat vs nested JSON encoding style

[Carsten Bormann <[e-mail]>]

Anders Rundgren wrote:
> Anyway, isn't CBOR what people are targeting for constrained devices?

Yes, but the desire to be able to do sequential (as opposed to
DOM-based) processing goes beyond constrained devices.

But talking about those:

The original design of SenML <draft-jennings-core-senml-04.txt> had a
top level map (what is called "object" in JavaScript, but then arrays
are also objects in JavaScript) of the form:

{ "metadata1": "value",
  "metadata2": 4711,
  "contents": [
     ... potentially many measurements
     ... where the interpretation of those
     ... depends on the metadata.
  ]
}

This looks deceptively sequential on a napkin, and it creates no
problems for a DOM-based receiver implementation (until the measurements
don't fit into memory any more).  For an implementation that tries to do
sequential processing, this structure is a big problem:  The metadata
may occur before or after the measurement array, depending on the whims
of the encoder, so you may not have what you need to process the
measurements sequentially at the place they occur.

Requiring the encoder to send data in a particular sequence is
theoretically possible, but in practice just means you lose that part of
the ecosystem that happens not to do that, and often you don't even get
a guarantee (order may be dictated by hash values that may be randomized
in a good implementation).

So we are moving SenML to something like:

[ { ... metadata blob ... },
  ... measurements ...
]

(the details are still being discussed).

Of course, in CBOR we could do:

{ { ... metadata blob ... }:
  [ measurements ]
}

i.e., use the metadata as the key for the map.  Which is essentially
what PHB is proposing, but that works in JSON only if the metadata
happens to be a single string (which is the case in the example given by
PHB).

Back to the discussion about representation style:

Preferring

{ "foo":
  { ... }
}

over

{ "type": "foo",
  ...
}

may or may not be compatible with the "struct"-style (see section 2 of
<draft-greevenbosch-appsawg-cbor-cddl-07.txt> for a definition of
various styles of using JSON-like data models), depending on whether
"foo" happens to be a constant in your implementation or you expect to
encounter new values as you go along.

Grüße, Carsten