Supporting bitmaps

[egekorkan]

There is a need to represent bitmaps, i.e. a list/array of bits, where each bit corresponds to a boolean value like alarm 1, alarm 2 or status like in-alarm (bit 0), fault (bit 1), overridden (bit 2), out-of-service (bit 3). This is very common in Modbus and BACnet and possibly other protocols.

The big question is how this looks in the data schema. This relates a lot to the recent discussions we had about uri variables in BACnet and HTTP (also slides from @lu-zero in TPAC23). My initial thought is that it should be an array or an object and then we map this to specific bits via forms.

Note: This is split from https://github.com/w3c/wot-binding-templates/issues/101 and https://github.com/w3c/wot/issues/119#issuecomment-219436032 . By splitting that binding template issue into multiple smaller ones, I will close that.

[lu-zero]

Extending the DataSchema to have a "type":"bitmap" that is logically an array of boolean would make easy to express that using plain jsonpointer, like this:

"properties": {
  "alarm": {
    "state": { "type": "boolean" },
    "forms": [
        {
          "op": "readproperty",
          "data": { 
            "type": "bitmap",
            "order":"msb",
            "bits":"16",
          }, 
          "map": { "thing": ["/properties/alarm/state"], "protocol": ["/data/0"] }

The assumptions

• the PropertyAffordance has a state DataSchema.
• the Form has a data DataSchema that represents the data, once deserialized from its contentType and contentCoding
• the map needs to take jsonpointers that are applied on the thing from one side and jsonpointers that apply on the form on the other and populate one side or the other depending on the op. (it accounts for the need of populating href, data and any other vocabulary term we came up with additional side-channels)