Question: Why json versus a notation that has an escape for comments?

[40Grit]

Title says it all.

[gerickson]

+1

[40Grit]

@mjkoster

[WAvdBeek]

because we decided to use JSON a long time ago and there are ways to include comments in json.

[mjkoster]

In practical terms, SDF is as much of a config file format as a language. We are using JSON to take advantage of the ubiquity, language support, and plentiful tools, as well as suitability for machine processing. We're using JSON Schema for validation and formal definition.

For comments and developer friendliness, we are discussing front end formats including YAML, HJSON, txt2json. Please see issue #2

We also will recommend liberal use of the "description" element.

Do you have some specific recommendations that go beyond these?

[40Grit]

I do not.

Language and tooling are reasonable considerations.

And the reccomendations for developer friendliness seem suitable as well.

I'm still getting a grasp on what oneDM's part is related to lwm2m etc.

[40Grit]

Coming back to this.

Are there scenarios where any of these syntaxes will be sent over the wire? Or are they just specifying how to interpret one syntax into another?

I have always wished json and other human readable notations would specify how to convert them to a compact binary equivalent.

This way you could programmatically convert back and forth for debug purposes but still maintain reasonable data length do over the wire.

You could even have provisions to send comments over the wire if desired.

[WAvdBeek]

depends on the architecture that wants to send the data. but in general the data of a request/response is just the data described by the models. the models are not even describing the request/responses, although it that is achieved implicitly. read/update are implicit on the "variables" defined as tag under odmProperty. if there are other functions needed, actions can be used to define an input document and an output document.

note that ODM only describes what needs to be conveyed, semantically, not what is actually on the wire required by the architecture.

JSON can be automatically converted to a binary format: CBOR. https://tools.ietf.org/html/rfc7049

Another good thing of JSON is that we can verify if the definition is correctly written up by means of JSON schema validation.

[mjkoster]

CBOR is a Concise Binary Object Representation, but it still needs external direction to compress string identifiers to unique compact binary IDs. I suppose some hash could approximate this, but the approach so far in OneDM is to provide binary ID numbers in the definitions (the "id" quality) as well as binary index numbers for enums e,g,:

"onoffData": {
  "enum": [ {"on":1, "off":0} ]
}

Then a CBOR serialization generator would be able to build a map of the ID numbers to terms and make over-the-air representations that use the numbers as CBOR tags and as enum values.

[40Grit]

Being in the embedded MCU space I have often been forced into situations where I need to implement a JSON parser in MCU applications. String parsing and encoding in C is a nightmare on all fronts (memory, flash, clock cycles, security)

A trend I have seen is that developers for platforms with less resource restrictions tend to not mind sending large strings "over the medium", getting them to switch to using a binary protocol can be a struggle. It makes sense from an ease of use and debug standpoint for them, but it is bad for the system as a whole.

I do understand that OneDM is not defining the actual data sent over the medium but I wanted to bring the point up in a place where it will at least be understood since I have never seen it addressed explicitly.

I have briefly exchanged emails with @hannestschofenig on this topic.

[mjkoster]

Currently, SDF only describes the data elements and not the representation format that is used to communicate them.

We expect there to be protocol bindings that specify how to use the communications medium, including over-the-air schemas and transfer layer methods and options.

The idea is to provide the minimum constraint that would enable interoperable applications, given that the application can adapt to content formats and encodings. For very constrained environments, there may need to be a fixed protocol binding chosen so as to minimize the resource use.

[40Grit]

Currently MCU's are not often used for protocol translation (gateway).

This is however something my team is pursuing now that MCUs with at least 512kB of ram are readily available and IoT operating systems have matured.

[mjkoster]

One thing to consider; as IP networking becomes ubiquitous, the requirement for protocol adaptation becomes more a matter of transfer layer and content format. It may be feasable to perform some adaptation on the constrained network device itself, by on including a compact definition of a protocol binding which could be based on hypermedia controls, e.g. CoRAL.

Also, if you are using OMA LWM2M, which you can indicate with a content format, the protocol binding is implicit and you should be able to generate over-the-air transactions from the OneDM semantic information and a base URI.