Details

    • Type: Improvement
    • Status: Closed
    • Priority: Minor
    • Resolution: Unresolved
    • Affects Version/s: CSD2
    • Fix Version/s: CSD2
    • Component/s: Profile-YAML
    • Labels:
      None
    • Proposal:
      Hide

      When specifying the type for entries in lists or maps, one has 2 options:

      1. Specify the name of an existing type
      2. Define the schema for a new (anonymous) type in-line.

      I propose that for the first option, we use a "shorthand" notation as follows:

      tosca.properties.PortSpec:
      properties:
      target:
      type: list
      entry_schema: PortDef

      For the second option (where a new anonymous type is defined in-line) I propose we use a simplified schema specification as follows:

      tosca.properties.PortSpec:
      properties:
      target:
      type: list
      entry_schema:
      derived_from: integer
      constraints:

      • in_range: [ 1, 65535 ]

      The only key names that should be supported for schema specifcations are "derived_from", "constraints", and "properties". Neither case requires a "type" keyword (if an existing type is specified we use the shorthand notation) and neither case requires a "name" keyword (since type names are assigned externally in the "datatype_definition")

      By the way, if we decide to adopt this proposal then I would also propose to rename entry_schema to entry_type

      Show
      When specifying the type for entries in lists or maps, one has 2 options: 1. Specify the name of an existing type 2. Define the schema for a new (anonymous) type in-line. I propose that for the first option, we use a "shorthand" notation as follows: tosca.properties.PortSpec: properties: target: type: list entry_schema: PortDef For the second option (where a new anonymous type is defined in-line) I propose we use a simplified schema specification as follows: tosca.properties.PortSpec: properties: target: type: list entry_schema: derived_from: integer constraints: in_range: [ 1, 65535 ] The only key names that should be supported for schema specifcations are "derived_from", "constraints", and "properties". Neither case requires a "type" keyword (if an existing type is specified we use the shorthand notation) and neither case requires a "name" keyword (since type names are assigned externally in the "datatype_definition") By the way, if we decide to adopt this proposal then I would also propose to rename entry_schema to entry_type
    • Resolution:
      Hide

      This issue was primarily intended to highlight modeling concerns, which were substantially addressed in the TOSCA Simple Profile for YAML TC discussion on 5 Mar 2015. The TC agrees, as per the reporter's suggestion, that the isssue be closed (see motion in minutes) and that, if needed, updated JIRA issues specific to the latest version of the spec be created.

      Show
      This issue was primarily intended to highlight modeling concerns, which were substantially addressed in the TOSCA Simple Profile for YAML TC discussion on 5 Mar 2015. The TC agrees, as per the reporter's suggestion, that the isssue be closed (see motion in minutes) and that, if needed, updated JIRA issues specific to the latest version of the spec be created.

      Description

      Property definitions can include an "entry_schema" key that is used to declare the schema definition for entries of “container” types such as the TOSCA list or map. The schema specification is currently somewhat confusing, since it seems to allow for 3 different ways to specify "names" associated with the schema:

      1. There is a "type" key in the specification that can refer to a named type (either a built-in type of a custom type created in the "datatype_definitions" section of a template).
      2. There is a "name" key in the specification that allows an arbitrary name to be associated with the schema
      3. The "datatypes_definitions" key of a template specifies a name for each newly created schema external to the schema specification itself.

      I believe there is room for simplification.

        Attachments

          Activity

            People

            • Assignee:
              mrutkows Matthew Rutkowski (Inactive)
              Reporter:
              lauwers Chris Lauwers (Inactive)
            • Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated: