Subject: [Asdf] Composing sdfThings

From: Carsten Bormann <[email-masked]>
Date: Mon, 29 Mar 2021 18:13:34 +0200

After today’s OneDM discussion, I put together a quick strawman that shows how to put together a fridge-freezer out of two refrigeration components.

https://github.com/one-data-model/exploratory/blob/master/sdfThing/fridgefreezer.sdf.json

This demonstrate static named composition.
It does not show how to do Ari’s use case of numbered composition (an array of sdfThings or sdfObjects in an sdfThing).
It also doesn’t demonstrate dynamic composition.

Grüße, Carsten

---

From: Ari Keränen <[email-masked]>
Date: Wed, 31 Mar 2021 18:44:40 +0000

Here's another strawman, based on Carsten's example, of a potential design with array of sdfObjects:
https://github.com/one-data-model/exploratory/blob/master/sdfThing/fridgemultifreezer.sdf.json

It uses new "minItems" and "maxItems" qualities (similar to JSO min/maxItems for array type) to define how many freezer Objects can there be in the Thing.

This seems like a reasonable design, but there are still open questions like how to address those objects. One option is to use JSON pointer array syntax, e.g., a pointer to the 7th freezer object could look like:
#/sdfThing/FridgeMulti-freezer/sdfObject/freezer/6

However, given the definition is not an actual array (it's JSON object with two new qualities), something like additional processing steps on the model would need to be applied before the JSON pointers can be used as such.

Another question is whether we should have minItems quality or should we use only sdfRequired also here. Unless we want to invent new wildcard syntax for sdfRequired, seems that sdfRequired would need to have separate pointer for each required instance. That could result in excessively large sdfRequired blocks so minItems seems like a reasonable shorthand for that.

Cheers,
Ari

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 31 Mar 2021 21:13:48 +0200

> It uses new "minItems" and "maxItems" qualities (similar to JSO min/maxItems for array type) to define how many freezer Objects can there be in the Thing.

… the difference of course being that in JSO array types (as we also use them in sdfData) the type of the element is in the JSO “items” entry, while in your example it is in all the other qualities of the sdfObject that you import into the sdfObject declaration in the sdfThing.  This difference rules out nested arrays (which, however, tend to be surprisingly less useful than one thinks, so we don’t have them in sdfData either).

Grüße, Carsten

---

From: Michael Koster <[email-masked]>
Date: Wed, 31 Mar 2021 13:49:23 -0700

This looks a lot like "multiInstance" that we previously had as a quality that applies to objects and things when they are composed.

From the earlier discussion, we noted that multiple instances are not an inherent quality of an object definition, but depend on the context in which the definition is used. (discuss?)

One seeming exception is LWM2M where there is the idea of multi-instance resources (properties), but these are essentially arrays and can be modeled with JSO array. 

In that sense, ithe need for a new pattern comes in when we compose a thing out of objects or other things, and don't want to name them. I would suggest that we may not always want to index them either, and there may be some cases where we simply want a collection.

The statement we can make (whether we index the items or not) is that the items are all identical in terms of qualities and external semantics. 

This makes it problematic to try to make some of them mandatory and not others. A min-max scheme seems most reasonable as a constraint to apply to construction of a composed thing. An sdfThing representing a particular SKU outlet strip will have a fixed number of outlet instances. Maybe we could use min=max to describe a fixed number of instances.

One idea we explored earlier is a multi-instance quality that can take a parameter value. When you want to bound the range, you define minimum and maximum in the model. When you want to specify a fixed number of instances, you use a constant definition.

If we adopt a parameterized scheme, it could account for both indexed and non-indexed use cases. I will see if I can find some examples from the earlier discussion.

Best regards,

Michael

> On Mar 31, 2021, at 11:44 AM, Ari Keränen <ari.keranen=[email-masked]> wrote:
> 
> -- 
> ASDF mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/asdf

---

From: Michael Koster <[email-masked]>
Date: Wed, 31 Mar 2021 18:25:17 -0700

I don't have an example model but I think where we left off was (architecturally) something like this parameterized quality "multiInstance":

{
  "namespace": {
  "pg": "https://onedm.org/playground"
},
  "sdfThing": {
    "OutletStripSKU126442775": {
      "sdfRef": "#/sdfThing/GenericOutletStrip",
      "multiInstance": {
        "const": 6
      }
    },
    "GenericOutletStrip": {
      "sdfRef": "#/sdfThing/OutletUnit",
      "multiInstance": {
        "minimum": 1,
        "maximum": 20
      }
    },
    "OutletUnit": {
      "sdfObject": {
        "PowerSwitch": {
          "sdfRef": "pg:/#/sdfObject/On_Off_switch"
        },
        "OvercurrentTrip": {
          "sdfRef": "pg:/#/sdfObject/energy.overload"
        },
        "EnergyUsage": {
          "sdfRef": "pg:/#/sdfObject/energy.consumption"
        }
      }
    }
  }
}

> On Mar 31, 2021, at 1:49 PM, Michael Koster <[email-masked]> wrote:
>