Subject: Re: [core] Status of SenML syntax

From: Christian Amsüss <[email-masked]>
Date: Wed, 2 Sep 2015 13:00:50 +0200

Hello,

On Wed, Aug 19, 2015 at 07:45:18PM +0300, Ari Keränen wrote:
> > [...] is using SenML for backup and replication purposes.
> 
> Interesting. I'd be inclined to say that perhaps SenML is not the right (or
> at least best) format then, but I'd be interested to hear more why you
> decided to use SenML for this.

It was mostly a "because it is there" decision (implementing that was
mainly a matter of having an all-resources batch). We'll probably switch
away from it for backups, but it seems the natural way to go for
replication.

> For sake of discussion (unless it's a typo or other very simple fix), I
> think it's better if you propose new text here on the list. Currently the
> XML at the SVN is the latest, but there was discussion that maybe we want to
> continue with github and/or markdown. No firm decisions yet on this.

As the modifications in -cabo look good, I've decided to start that
based on draft-jennings-core-senml-xx-cabo.mkd.

While fleshing things out, I've stumbled across some points that might
need further discussion:

* The trivial example:

    {"e":[{ "n": "urn:dev:ow:10e2073a01080063", "v":23.5, "u":"Cel" }]}

  becomes

    [{}, [{"n": "urn:dev:ow:10e2073a01080063", "v": 23.5, "u": "Cel"}]]

  and while not being any longer, the data structure is not as trivially
  obvious as the old one. We could allow skipping empty dictionaries,
  which might make some forms of concatenation more straightforward, but
  introduces a type-based switch into the decoder.

  If no strong opinions are voiced, I'm inclined to leave the
  alternating dict-list pattern as it was discussed, and maybe just
  change the first example to use bn and thus be less confusing.

* There is a section in the specification I don't fully understand:

  > Note that in some usage scenarios of SenML the
  > implementations MAY store or transmit SenML in a stream-like
  > fashion, where data is collected over time and continuously
  > added to the object. This mode of operation is optional, but
  > systems or protocols using SenML in this fashion MUST
  > specify that they are doing this. [...]

  Is this intended to apply to transports that technically allow
  stalling a transfer mid-stream, like HTTP with delays between
  segments? If so, this should be at least given as an example. In any
  case, we should add a way of specifying that this is done, because
  with the current text, different implementations of this are most
  likely not interoperable, making the whole section rather moot.

Attached, you'll find an overhauled version of the SenML draft, please
review it and consider it for adoption into the next draft revision.

If the development of the SenML specification document moves to a
git-based workflow, I'll happily rebase my patches to be available as
history; they can also come in handy if any of the changes I've applied
so far are more controversial than I had anticipated. My changes in
summary:

* Changed JSON examples to [{}, []] syntax
* Rephrased general semantics section (which was previously tightly
  coupled with the now obsolete syntax)
* Changed JSON serialisation description to reflect new syntax
* Updte CBOR serialisation description, numbers and CDDL
* Removed strict requirements for consumption and production of floats
  (Every JSON numeric is permitted, and consumers are only reqired to
  understand as much as they need).

I kindly ask for comments on the abovementioned open points and the new
draft version in general.

Best regards
Christian Amsüss

-- 
Christian Amsüss                      | Energy Harvesting Solutions GmbH
founder, system architect             | headquarter:
mailto:[email-masked]  | Arbeitergasse 15, A-4400 Steyr
tel:+43-664-97-90-6-39                | http://www.energyharvesting.at/
                                      | ATU68476614