Subject: [Asdf] Mapping files: Which way should the arrows go?

From: Carsten Bormann <[email-masked]>
Date: Sun, 28 Feb 2021 08:05:50 +0100

Jan Romann, a student who is looking at using SDF models plus SDF mapping files for deriving information about communication characteristics (think MUD), prepared a strawman for a mapping file:

https://gist.github.com/JKRhb/e3def2cf049e90e43f533132b6fb7467

As you can see, this is essentially based on WoT structures, describing for each SDF affordance how this affordance is implemented in the protocol.

Looking at the example, this got me thinking.  While this approach certainly works, an alternative would be to describe the mapping in terms of protocol concepts, and point back to the SDF from there.  So, you might have a description of the URI /switch/value, and point to the property that this realises (in this case, there would be four transactions on this URI, read/write/observe/unobserve, pointing back to the sdfProperty /sdfObject/Switch/sdfProperty/value.
Maybe the example is too simple for seeing how this could be better, but as soon as you add, say, security properties, concentrating those around URIs is likely to be easier to model.

(There, of course, is the class-vs-instance problem, which the example skirts around by implicitly assuming a base URI instantiation parameter and using relative URIs to describe the absolute URIs that an instance would need.  Some weirdness comes from the fact that it is the base URI that carries the URL scheme, so the mapping file has to carry that part separately, and the parameter really is a URI authority == transport address.)

I think Jan's example is great input to the Hackathon we are starting tomorrow, in addition to the mapping file strawmen we already have.

Grüße, Carsten

---

From: Michael Koster <[email-masked]>
Date: Sun, 28 Feb 2021 09:28:16 -0800

Very interesting. I have been working on a mapping strawman also. I have come to see it as instance binding, by adding scheas for data formatting, and adding protocol instructions.

My approach is to create the mapping as inline extension points, using extension schemas. There is an extension point for schemas, one for protocol instructions, and one for hyperlinks (not used yet). These can eaily be stripped out to mapping files and re-inserted when generating the instance. I find it easier to edit the bindings inline and also am reusing sdfRef for addresses etc., but hte program generated bindings could ust as easily use jsonpointer or jsonpath references.

I have created some working examples using the modbus models I am preparing for the IETF Hackathon/WoT Plugfest tomorrow. These are actual hardware products that use Modbus for control:

https://github.com/mjkoster/onefb-sdk/blob/main/control-models/modbus/sdfthing-modbus-ehd-rtu.sdf.json
https://github.com/mjkoster/onefb-sdk/blob/main/control-models/modbus/sdfthing-modbus-dcpowersupply.sdf.json

I am also generating WoT TD instances, so I have also essentially used the WoT DataSchema and Forms elements from Thing Description as the extension vocabulary (crude but efficient).

I think it will be good to collect our experiences with the embedded bindings and work toward what Carsten suggests as a more descriptive approach using a common SDF extension.

I have also described the Modbus protocol using SDF (WIP, needs some work still), so perhaps something like this could be part of the descriptive approach, with a low level protocol model that the binding has entry points into.

https://github.com/mjkoster/onefb-sdk/blob/main/control-models/modbus/sdfobject-modbus-message.sdf.json

Finally, I made some slides to describe the implementations with emphasis on the SDF and instance binding parts of the workflow

https://github.com/mjkoster/onefb-sdk/blob/main/documents/onedm-plughackthonfest.pdf

Today I am depoying the modbus RTU=>TCP bridge and starting on the SDF => TD processing based on this work: 

https://github.com/roman-kravtsov/sdf-object-converter

Looking forward to tomorrow,

Michael

> On Feb 27, 2021, at 11:05 PM, Carsten Bormann <[email-masked]> wrote:
> 
> -- 
> ASDF mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/asdf