Handling of non-body payloads per protocol binding

[egekorkan]

I had an offline chat with @lu-zero and we have a bit of a "lack of describabilty" problem when it comes to how the data is passed in a protocol. We are assuming the following:

• Data Schema refers to the body message
• uriVariables is always about the URI (self explanatory)

This has the following problem:

• No way to describe if input is required but should be in the header. This is of course not a good practice but it is not possible to describe.
• Protocols that do not have uriVariables (like MQTT or WS) cannot use that feature.
• For generic consumers, it is annoying to implement programming APIs to take payload+header+uriVariables into account. Even more annoying since this differs by protocol as well but the TD does not do this separation.

Proposal for 2.0: A way to map from forms to the data schema for building complex inputs. This means that we can have a single data schema and some keywords in the form describe where this kind of input should go. Some kind of JSON Path or JSONata rules can help with this kind of mapping language. This would not make the simple cases more complex (simple input in payload) but would allow other cases to be described inside forms, giving flexibility per protocol/form.

[egekorkan]

Also, this can actually solve the problem of the platforms/standards that send big objects but only one part of the object is relevant for the affordance. So we can think of a way to point to and map to different parts of the header or payload and say that this is what the affordance actually uses and the rest can be ignored.

[lu-zero]

This is similar to the problem we are tackling to have a precise mapping between elements of the input object and the risk/hazard system we are working on in @sifis-home, probably the same pattern can be used to address both.