Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents


Tasks

Update the vspec2graphql exporter in vss-tools.

  •  Change the mapping
    from (current): (VSS leaf → Specific GraphQL type)
    to (desired): VSS leaf → Specific field within a GraphQL type, where a type is then the immediate parent branch
  •  Use graphene pydantic for proper data validation
  •  

    Support current VSS feature set functional requirements:

Functional requirement

VSS item

GraphQL correspondance

  •  Model can be specified in multiple files.

Include

  • It is possible to specify schema across multiple files.
  • Command Line tool has to include all files/links.
  •  Human-friendly context is provided.

Concatenated path

  • docs/_TYPE
  • Hierarchy outside GraphQL (context, field...)
  •  Properties can be grouped. Hierarchical concept scheme to group properties belonging to the same area of interest is supported.

Branch type

Aggregate

Struct

  • type based
  • grouping is implicit
  •  Properties whose values do not change often can be specified.

Attribute type

  • A field is specified.
  •  Properties whose value might change often can be specified as observable or actuatable.

Sensor type

Actuator type

  • A field is specified. The associated value is assigned with the instance data
  •  Definitions can be reused when there are multiple occurrences.

Instances

  • It is possible to specify that a field can have multiple instances. 
    enum CarDoorPosition {
      FRONT_L
      FRONT_R
      REAR_L
      REAR_R
    }
    
    type Car {
      id: ID!
      make: String!
      model: String!
      doors: [CarDoor!]!
    }
    
    type CarDoor {
      id: ID!
      position: CarDoorPosition!
    }
  •  Arrays or lists are supported.

Arrays (i.e., datatype[])

  • supported by the language with [ ]
    type Vehicle {
      id: ID!
      make: String!
      model: String!
      doors: [String!]!
    }
  •  Extended list of primitive datatypes is supported.

(u)intX, boolean, float, double, string

  • Custom scalars can be defined as an extension. In the GraphQL schema we might have something like:
    scalar Int8 @specifiedBy(url: "xsd:byte")
    scalar UInt8 @specifiedBy(url: "xsd:unsignedByte")
    scalar Int16 @specifiedBy(url: "xsd:short")
    scalar UInt16 @specifiedBy(url: "xsd:unsignedShort")
    scalar UInt32 @specifiedBy(url: "xsd:unsignedInt")
    scalar Int64 @specifiedBy(url: "xsd:long")
    scalar UInt64 @specifiedBy(url: "xsd:unsignedLong")

    # Here xsd is the namespace <http://www.w3.org/2001/XMLSchema#>.
  •  Units and quantity kind can be specified.

Unit

Dimension

  • via types and enums
  •  Default values can be specified.

Default

  • handling of default values depends on your server-side implementation
  • It can be added for informative purposes as a comment in the schema
  •  Allowed values can be specified.

allowed: [‘value1’, ..., ‘valueN’]

  • Use enums
    enum Color {
      RED
      GREEN
      BLUE
    }
    
    type Car {
      id: ID!
      make: String!
      model: String!
      color: Color!
    }
  •  A custom redefinition of the concepts is possible.

Overlay

  • schema stiching
  • schema extension
  •  Min and max expected values can be specified.

min: 0

max: 100

  • custom scalar type and directive
  • implementation of the necessary validation logic on the server-side
  • Alternative: include the information in the comment.
  •  Concepts in the model can evolve.

deprecation

  • @deprecated directive


Create a graphql2vspec mechanism for backward compatibility

  •  Take the resulting GraphQL schema and create back the vspec version
  •  Test that the resulting specified information is exactly the same. For example, by comparing the static IDs.