Currently, the Technology Modeling Language does not provide full MIME type support.
While it is possible to model protocols with data formats, e.g.,
technology Example {
protocols {
sync rest data formats json default with format json;
async amqp data formats json default with format json;
}
}
the following is not possible
technology ExampleWithMimes {
protocols {
sync rest data formats "application/json" default with format "application/json";
async amqp data formats "application/json" default with format "application/json";
}
}
I pushed a branch called mime_type_support to change the DataFormat production rule in the Technology Modeling Language's grammar specification (and the cross-references to it, e.g., from the Service Modeling Language's grammar) to not rely on ID, but Xtext's STRING terminal rule instead. While this change seems to be working on the grammar level, it needs further testing.
If there are no obvious issues, the following issues need to be addressed (and maybe some more):
Testing/possible adaptation of code generators.
Adaptation of intermediate metamodels' documentations.
Finally, this change should make it into master together with the OpenAPI feature when it's ready.
Currently, the Technology Modeling Language does not provide full MIME type support.
While it is possible to model protocols with data formats, e.g.,
the following is not possible
I pushed a branch called mime_type_support to change the
DataFormat
production rule in the Technology Modeling Language's grammar specification (and the cross-references to it, e.g., from the Service Modeling Language's grammar) to not rely onID
, but Xtext'sSTRING
terminal rule instead. While this change seems to be working on the grammar level, it needs further testing.If there are no obvious issues, the following issues need to be addressed (and maybe some more):
Finally, this change should make it into
master
together with the OpenAPI feature when it's ready.