Allowing default in structs

[UlfBj]

VSS does not support default being defined in structs, as stated in https://covesa.github.io/vehicle_signal_specification/rule_set/data_entry/data_types_struct/index.html#default-values There is an exception for empty arrays of structs, and there is also the possibility to define the default in the property nodes defining the struct.

Even if the latter makes it possible to declare default values for all members of a struct it comes with the limitation that all usages of this struct definition will get the same default values as a consequence of the structs being defined in a separate Types tree. So to enable a generic default support it should be allowed to define the default in the struct node itself.

The question then is what syntax should be used to define the default value?

Using JSON could provide compatibility with VISS where the value of a struct has the format {“elementname1”:“value1”, …, “elementnameN”: “valueN”}.

The exporter tool may validate this by parsing of the Types tree but it should be possible to disable this validation to support also other syntax models.

[erikbosch]

Some information/examples on how we already today handle json/yaml struct info for extended attributes. As you can we support both Yaml and JSON constructs, but I do not know if there are corner cases that gives problem

VSPEC:

VersionVSS.Major:
  datatype: uint32
  type: attribute
  default: 3
  erik: {"a":2,"b":3, "C": "8"}
  description: Supported Version of VSS - Major version.

VersionVSS.Minor:
  datatype: uint32
  type: attribute
  default: 0  
  erik:
    C: '8'
    a: 2
    b: 3
  description: Supported Version of VSS - Minor version.

VersionVSS.Patch:
  datatype: uint32
  type: attribute
  default: 0
  erik: {"a":2,"b":3, "C": [1, 6, 5]}
  description: Supported Version of VSS - Patch version.

Generated YAML:

Vehicle.VersionVSS.Major:
  datatype: uint32
  default: 3
  description: Supported Version of VSS - Major version.
  erik:
    C: '8'
    a: 2
    b: 3
  type: attribute

Vehicle.VersionVSS.Minor:
  datatype: uint32
  default: 0
  description: Supported Version of VSS - Minor version.
  erik:
    C: '8'
    a: 2
    b: 3
  type: attribute

Vehicle.VersionVSS.Patch:
  datatype: uint32
  default: 0
  description: Supported Version of VSS - Patch version.
  erik:
    C:
    - 1
    - 6
    - 5
    a: 2
    b: 3
  type: attribute

Generated JSON:

 "Major": {
            "datatype": "uint32",
            "default": 3,
            "description": "Supported Version of VSS - Major version.",
            "erik": {
              "C": "8",
              "a": 2,
              "b": 3
            },
            "type": "attribute"
          },
          "Minor": {
            "datatype": "uint32",
            "default": 0,
            "description": "Supported Version of VSS - Minor version.",
            "erik": {
              "C": "8",
              "a": 2,
              "b": 3
            },
            "type": "attribute"
          },
          "Patch": {
            "datatype": "uint32",
            "default": 0,
            "description": "Supported Version of VSS - Patch version.",
            "erik": {
              "C": [
                1,
                6,
                5
              ],
              "a": 2,
              "b": 3
            },

[sschleemilch]

Since every JSON is also a valid YAML (but not vice versa), most YAML parsers also just accept JSON. But I do not see a reason why you would mix that as a user except for being able to define something in a single line. Even then, I am not sure if it is good for readability. Nethertheless the parser would support it anyway

Regarding validation: I think we might be able to generate a jsonschema out of the type and then check the given value against that. That is the solution that I can think about which might scale good. I can have a look how hard it would be to do something like that.