-
Notifications
You must be signed in to change notification settings - Fork 31
Project: DSL JSON like syntax for instantiating data types
There is currently no way to explicitly instantiate a data type. As an example, suppose we want to describe an employee of a company.
type Employee:
name string (1..1)
salary number (1..1)
isSeniorMember boolean (1..1)
mentor Employee (0..1)
Currently, the only way to actually make an instance of this data type, is to define a function that returns an Employee
. This is quite verbose, i.e.,
func CreateEmployee:
inputs:
name string (1..1)
salary number (1..1)
isSeniorMember boolean (1..1)
mentor Employee (0..1)
output:
result Employee (1..1)
set result->name: name
set result->salary: salary
set result->isSeniorMember: isSeniorMember
set result->mentor: mentor
With this function, we can instantiate an Employee
by calling CreateEmployee(...)
. We have to write such a function each time we want to actually instantiate some data type.
We intend to introduce an intuitive JSON-like syntax to instantiate a data type. For example, we could instantiate an Employee
called Dwight Schrute who has a mentor called Michael Scott as follows.
Employee {
name: "Dwight Schrute",
salary: 4800.00,
isSeniorMember: False,
mentor: Employee {
name: "Michael Scott",
isSeniorMember: True,
salary: 6300.00,
mentor: empty
}
}
Furthermore, these expressions will be validated automatically by our type system to guarantee correctness, i.e., no attributes were forgotten and each attribute is of the right type.
Note that properties may be written in any order (see the salary
and isSeniorMember
properties of Michael Scott).
In many Rosetta models such as the CDM, it is common practice to have data types with many optional properties, e.g., with a cardinality constraint (0..1)
. In such cases, it is inconvenient to set most of them to empty
explicitly. We'll therefore add a shorthand, ...
, which stand for "assign empty
to every other attribute". An example taken from the CDM:
type ProductIdentification:
productQualifier productType (0..1)
primaryAssetData AssetClassEnum (0..1)
secondaryAssetData AssetClassEnum (0..*)
externalProductType ExternalProductType (0..*)
productIdentifier ProductIdentifier (0..*)
To instantiate this data type, we could then write
ProductIdentification {
primaryAssetData: AssetClassEnum->Credit,
...
}
which would be equivalent with
ProductIdentification {
primaryAssetData: AssetClassEnum->Credit,
productQualifier: empty,
secondaryAssetData: empty,
externalProductType: empty,
productIdentifier: empty
}
Note that if assigning empty
to absent attributes would be done implicitly instead, it would be easy to accidentally forget to assign an attribute. The benefit of making this explicit with ...
is that validation will be more thorough and might prevent additional mistakes.
- Constructor-like functions such as
CreateEmployee
can be removed from the CDM and other Rosetta models. - It becomes possible to instantiate empty data types such as the
Zero
type described above. - The triple-dot syntax improves validation, preventing mistakes from sneaking up in the CDM and other Rosetta models.