I raised this topic in the VDM meeting a couple of weeks ago and @cpodalak requested I raise an issue. I noticed it as a result of work trying to generate DB schema definitions of VDM types.
Summary
Automated VSS translation to VDM
The current (initial) VSS to VDM translation tooling maps each VSS branch and the properties (leaf nodes) within it in VDM to a GraphQL SDL object type populated with fields taken from the VSS leaf nodes. For example the VSS root branch Vehicle becomes the VDM object type Vehicle and its VSS leaf node Vehicle.Speed in VDM becomes the field speed in the type Vehicle.
The potential problem
In VSS, vspec does not imply how leaf nodes are instantiated. It is not uncommon for nodes to be treated as key value pairs in data streams.
As stated the VDM tooling translates VSS branch nodes to a GraphQL SDL type. It would be common software engineering practice to instantiate the type as a complete structure, e.g. in a DB schema to instantiate the group of properties as a table. This causes an implementation issue as VSS mixes up different categories of data, with different attributes, from related but different domains within branches. For example, the VSS branch Vehicle contains both dimensional nodes such as Vehicle.Height whose values change infrequently and nodes such as Vehicle.Speed where the data changes very frequently. An implementation that needs Vehicle.Speed recorded at 1Hz or quicker would be extremely wasteful storing, processing and transmitting Vehicle.Height at the same rate.
This raises the question of whether the logical VDM types generated from VSS contain the right groups of fields for the domain being modeled? Are the types fit for purpose or is further decomposition needed?
In the interests of clarity, it is not suggested a wholesale reworking of the VSS domains is being called for. That would be something that would be done over time as domains evolve and needs change.
Further detail
It is true that APIs can selectively provide access only to the VDM fields that are needed, a GraphQL Query would be one example. It is also true that GraphQL SDL provides some mechanisms that could be used to select fields when generating schemas. These would provide one way to workaround the problems of 'fat' types like Vehicle.
That said, data-centric architectures treat data as a first class citizen and VDM is intended to provide greater ability to relate parts of the different models. One attribute of the VDM project is the opportunity to review what is good and what could be improved in VSS. This is similar to the domain review that took place when the capabilities project looked at the domain seat.
For example, whilst retaining the existing semantics for the particular properties, we might consider reworking groupings of properties in the types. In the example above dimensional vehicle data and quickly updating positional data in the Vehicle branch/type might become their own types, which the Vehicle type can reference. It would be sensible to consider whether that is something that can be applied consistently across the domains. Doing so would improve usability and coherence.
I raised this topic in the VDM meeting a couple of weeks ago and @cpodalak requested I raise an issue. I noticed it as a result of work trying to generate DB schema definitions of VDM types.
Summary
Automated VSS translation to VDM
The current (initial) VSS to VDM translation tooling maps each VSS branch and the properties (leaf nodes) within it in VDM to a GraphQL SDL object type populated with fields taken from the VSS leaf nodes. For example the VSS root branch Vehicle becomes the VDM object type Vehicle and its VSS leaf node Vehicle.Speed in VDM becomes the field speed in the type Vehicle.
The potential problem
In VSS, vspec does not imply how leaf nodes are instantiated. It is not uncommon for nodes to be treated as key value pairs in data streams.
As stated the VDM tooling translates VSS branch nodes to a GraphQL SDL type. It would be common software engineering practice to instantiate the type as a complete structure, e.g. in a DB schema to instantiate the group of properties as a table. This causes an implementation issue as VSS mixes up different categories of data, with different attributes, from related but different domains within branches. For example, the VSS branch Vehicle contains both dimensional nodes such as Vehicle.Height whose values change infrequently and nodes such as Vehicle.Speed where the data changes very frequently. An implementation that needs Vehicle.Speed recorded at 1Hz or quicker would be extremely wasteful storing, processing and transmitting Vehicle.Height at the same rate.
This raises the question of whether the logical VDM types generated from VSS contain the right groups of fields for the domain being modeled? Are the types fit for purpose or is further decomposition needed?
In the interests of clarity, it is not suggested a wholesale reworking of the VSS domains is being called for. That would be something that would be done over time as domains evolve and needs change.
Further detail
It is true that APIs can selectively provide access only to the VDM fields that are needed, a GraphQL Query would be one example. It is also true that GraphQL SDL provides some mechanisms that could be used to select fields when generating schemas. These would provide one way to workaround the problems of 'fat' types like Vehicle.
That said, data-centric architectures treat data as a first class citizen and VDM is intended to provide greater ability to relate parts of the different models. One attribute of the VDM project is the opportunity to review what is good and what could be improved in VSS. This is similar to the domain review that took place when the capabilities project looked at the domain seat.
For example, whilst retaining the existing semantics for the particular properties, we might consider reworking groupings of properties in the types. In the example above dimensional vehicle data and quickly updating positional data in the Vehicle branch/type might become their own types, which the Vehicle type can reference. It would be sensible to consider whether that is something that can be applied consistently across the domains. Doing so would improve usability and coherence.