Create new charter proposal for binding templates #1035
Conversation
| 2. gRPC | ||
| 3. OPC-UA (also see https://github.com/w3c/wot/blob/main/liaisons/opcf/tech_reqs.md) | ||
| 2. Payload Formats | ||
| 1. JSON |
There was a problem hiding this comment.
I am not opposed to see "CBOR" on the list... but in my understanding JSON, XML are formats and there are default textual serializations of it. On the the other hand there a more efficient serializations like CBOR for the JSON format...
There was a problem hiding this comment.
I also think that CBOR can be "simply used". This binding should simply show its usage via examples. I would not expect that we define an ontology for it. @ektrah any opinions?
There was a problem hiding this comment.
I agree that CBOR is useful to have. I'm not sure if I understand the rest of the question... Let's say there is a Thing that exposes a Property value in application/senml+cbor format over CoAP. What's needed (in terms of payload bindings) to make that work?
There was a problem hiding this comment.
So first of all, senml dictates a certain payload structure, so that will go into the data schema. Then, this should be the payload in the JSON way (as data schema describes a JSON), then encoded into CBOR when the payload is being prepared. From my point of view, the developer of Scripting API compliant Thing or Consumer would see no difference in their code when the format is application/senml+cbor or application/senml+json. However, I have no practical experience with SenML nor CBOR.
There was a problem hiding this comment.
If you check out section 6 (and in particular table 4) of RFC 8428, you'll see that application/senml+cbor is not just application/senml+json encoded into CBOR. Would that table need to go into the Thing Description? Or would we need a separate SenML payload binding?
There was a problem hiding this comment.
IMHO, if the goal is to convert a JSON payload (as described by the data schema in JSON Schema terms) into some random CBOR structure, then, yes, you can simply encode it into CBOR. However, if the goal is to convert it into the CBOR structure that people actually use, I think a different approach is needed: The payload binding would need to specify (1.) how to express arbitrary CBOR/XML/... payloads in JSON and (2.) how to convert the CDDL/XML Schema/... that describes the CBOR/XML/... payload to JSON Schema.
|
Call of 16.11: We have agreed to merge. This is only the proposal and changes can be requested via PRs later on. |
This is the initial proposal of the charter proposal. Before agreeing on it, we need to check with the editors of the current protocol binding documents such as @relu91, @ektrah, @mjkoster and @JKRhb (not an editor but is involved in the discussions) since going for a normative track such as REC or Registry would imply changes to the documents they have written or contributed to.