Subject: [Asdf] Syntax idea for SDF 1.1

From: Michael Koster <[email-masked]>
Date: Fri, 4 Dec 2020 10:23:23 -0800

An obvious simplification occurred to me whilst refactoring some of the models, wrt the way we define the input and output data for actions and events.

the current 1.1 feature syntax example:

{
  "sdfAction": {
    "setOvenMode": { 
      "description": "Action to set the oven mode",
      "label": "Set Oven Mode",
      "sdfInputData": {
        "required": [ "ovenMode" ],
        "type": "object",
        "properties": {
          "ovenMode": {
            "sdfRef": "ex:#/sdfData/OvenMode"
          }
        }
      }
    }
  }
}

The idea is to factor out the redundant construct "type": "object","properties": {} and have the properties be JSON properties of the sdfInputData object, (also changing how "required" works):

{
  "sdfAction": {
    "setOvenMode": { 
      "description": "Action to set the oven mode",
      "label": "Set Oven Mode",
      "sdfRequired": [ "sdfInputData/ovenMode" ],
      "sdfInputData": {
        "ovenMode": {
          "sdfRef": "ex:#/sdfData/OvenMode"
        }
      }
    }
  }
}

This removes an extra level from the JSON and enables a consistent use of "sdfRequired". 

Since sdfRequired now only refers to something inside its parent scoped block, we could adopt a simple locally scoped pointer scheme which is a hybrid of jso required property name and sdf 1.0 json-pointer scheme. We would need to add a pointer type for this in the schema.

This will work also for the required Properties, Actions, and Events in a sdfObject, which makes it much more readable.
...
  "sdfObject": {
    "ovenMode": {
      "label": "Oven Mode",
      "sdfRequired": [
        "sdfProperty/ovenMode",
        "sdfProperty/supportedOvenModes",
        "sdfAction/setOvenMode"
      ],
      "sdfProperty": {
        "ovenMode": {
(etc.)

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 7 Dec 2020 14:57:34 +0100

Hi Michael,

On 2020-12-04, at 19:23, Michael Koster <michael.koster=[email-masked]> wrote:
> The idea is to factor out the redundant construct "type": "object","properties": {} and have the properties be JSON properties of the sdfInputData object,

That is similar to my original proposal, which we seemed to move away from in favor of adopting jso type=object wholesale.

> (also changing how "required" works):

Actually, not really wanting to change that really was the motivator to go for the jso variant.

> This removes an extra level from the JSON and enables a consistent use of "sdfRequired". 

That is really the interesting question that pops up: What does sdfRequired mean?
So far we have the wholesale requiredness of affordances, as well as the requiredness of specific substructures in the data models.

Should these be handled the same?

Can you have an optional (SDF) property that, when present, has a required map entry (jso property)?   How would this map into sdfRequired?  (It maps easily into a jso required for the data model part.)

.oOo.

Then there is this whole can of worms, which we can reopen once we have a good grasp on what we want to do about the former.

>         "sdfProperty/supportedOvenModes",

Grüße, Carsten