Subject: [Asdf] Issues #2 and #5: sdfChoice

From: Carsten Bormann <[email-masked]>
Date: Mon, 7 Dec 2020 06:31:59 +0100

I have pushed text for the sdfChoice proposal, which should be addressing #2 and #5.

Please have a look at:

https://ietf-wg-asdf.github.io/SDF/sdf.html#name-sdfchoice

(Commit https://github.com/ietf-wg-asdf/SDF/commit/be0fd37 plus a typo commit.)

If this is accepted by the WG, we should be getting closer to declaring SDF 1.1.

Grüße, Carsten

---

From: <[email-masked]>
Date: Mon, 7 Dec 2020 09:02:59 -0000

Hi Carsten,

Thanks for doing this.
The discussion on "with what to extend the current enums" did not go further than mentioning that the current enum mechanism of JSON schema did not have the possibility of a description field. Hence no other additions have been identified.

I still do not like how sdfChoice is handling the none string enums. 
The none string value is multiple levels down in the description, which is frankly awkward. 
 
I rather want to go for the simpler model of having a table that extend the normal enum with additional fields.
So that the existing enum structure can be used and thus the enum values are directly known
e.g.
"myenum" :{
"type": "number",
"enum": [1, 2, 3]
}
"myenum2" :{
"type": "string",
"enum": [ "blah", "blahblah"]
}

By having a top level extension mechanism to add more info to these fields if needed/wanted:

sdfExtensions: {
".../myenum/1" : {
"description": "This is a foonly"
}
...
".../myenum/blah" : {
"description": "This is a blah"
}
}

Let's discuss this on the call today.

Kind Regards,
Wouter

-----Original Message-----
From: ASDF <[email-masked]> On Behalf Of Carsten Bormann
Sent: Monday 7 December 2020 05:32
To: [email-masked]
Subject: [Asdf] Issues #2 and #5: sdfChoice

Please have a look at:

Grüße, Carsten

-- 
ASDF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asdf

---

From: Michael Koster <[email-masked]>
Date: Mon, 7 Dec 2020 11:34:30 -0800

Taking this to some examples, we could start with an enum and an extension, call it sdfMap for now:

  "sdfData": {
    "SwitchState": {
      "enum": [
        "on",
        "off"
      ]
    }
  },
  "sdfMap": {
    "#/sdfData/SwitchState/enum/on": {
      "label": "On",
      "description": "The powered or functionally active state",
      "default": "on"
    },
    "#/sdfData/SwitchState/enum/off": {
      "label": "Off",
      "description": "The un-powered or functionally inactive state",
      "default": "off"
    }  
  }

But it isn’t clear how e.g. the pointer to a label would work in the above example. It’s not clear how the expected construct would resolve:

#/sdfData/SwitchState/enum/on/label

We could provide a local mapping for the enum instead:

  "sdfData": {
    "SwitchState": {
      "enum": [
        "on",
        "off"
      ],
      "sdfMap": {
        "on": {
          "label": "On",
          "description": "The powered or functionally active state",
          "default": "on"
        },
        "off": {
          "label": "Off",
          "description": "The un-powered or functionally inactive state",
          "default": "off"
        }
      }

Here the pointer could point to the sdfMap:

#/sdfData/SwitchState/sdfMap/on/label

Hmm, we could just change the name from sdfMap to sdfAny and we have a parallel construct for mapping enums (that we can also use for the anyOf use case):

  "sdfData": {
    "SwitchState": {
      "enum": [
        "on",
        "off"
      ],
      “sdfAny": {
        "on": {
          "label": "On",
          "description": "The powered or functionally active state",
          "default": "on"
        },
        "off": {
          "label": "Off",
          "description": "The un-powered or functionally inactive state",
          "default": "off"
        }
      }

The pointer works the same as with the local map:

#/sdfData/SwitchState/sdfAny/on/label

> On Dec 7, 2020, at 1:02 AM, <[email-masked]> <[email-masked]> wrote:
> 
> Hi Carsten,
> 
> Thanks for doing this.

---

From: <[email-masked]>
Date: Thu, 10 Dec 2020 12:10:16 -0000

Hi Michael,

What is the intent of the label? E.g. why is the external reference of that label needed?

Kind Regards,
Wouter

From: Michael Koster <[email-masked]> 
Sent: Monday 7 December 2020 19:35
To: [email-masked]
Cc: Carsten Bormann <[email-masked]>; [email-masked]
Subject: Re: [Asdf] Issues #2 and #5: sdfChoice

  "sdfData": {

    "SwitchState": {

      "enum": [

        "on",

        "off"

      ]

    }

  },

  "sdfMap": {

      "label": "On",

      "default": "on"

    },

      "label": "Off",

      "default": "off"

    }  

  }

 

  "sdfData": {

    "SwitchState": {

      "enum": [

        "on",

        "off"

      ],

      "sdfMap": {

        "on": {

          "label": "On",

          "default": "on"

        },

        "off": {

          "label": "Off",

          "default": "off"

        }

      }

 

  "sdfData": {

    "SwitchState": {

      "enum": [

        "on",

        "off"

      ],

      “sdfAny": {

        "on": {

          "label": "On",

          "default": "on"

        },

        "off": {

          "label": "Off",

          "default": "off"

        }

      }

 

On Dec 7, 2020, at 1:02 AM, <[email-masked] <mailto:[email-masked]> > <[email-masked] <mailto:[email-masked]> > wrote:

Hi Carsten,

Thanks for doing this.

sdfExtensions: {
".../myenum/1" : {

Kind Regards,
Wouter

-----Original Message-----
From: ASDF <[email-masked] <mailto:[email-masked]> > On Behalf Of Carsten Bormann
Sent: Monday 7 December 2020 05:32
To: [email-masked] <mailto:[email-masked]> 
Subject: [Asdf] Issues #2 and #5: sdfChoice

Please have a look at:

Grüße, Carsten

-- 
ASDF mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/asdf

-- 
ASDF mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/asdf

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 10 Dec 2020 14:15:51 +0100

> Taking this to some examples, we could start with an enum and an extension, call it sdfMap for now:

I don’t think we should come up with a contorted structure just to achieve some superficial similarity with the json-schema.org way of doing this.
This is much harder to generate and consume, as well as read/check, so there really is no benefit.

Grüße, Carsten

---

From: Michael Koster <[email-masked]>
Date: Fri, 11 Dec 2020 16:05:39 -0800

I agree, and I want to propose the third option in the above message, using sdfAny.

> On Dec 10, 2020, at 5:15 AM, Carsten Bormann <[email-masked]> wrote:
>