Source: NASA ( Kevin Rice)
This is more for discussion. our syntax is ok but when the schema types that control the syntax in parameter/argument type are manifest into classes, the result is less than ideal.
Firstly all our parametertype/argumenttypes have NameDescriptionType as the root. It might for example make sense to have as a root "DataType" or something of that nature – and maybe to then ScalarDataType and ComplexDataType which seems natural.
Secondly we now have split the parameter type and argument types because we had to support looking up parameters and arguments in the latter. And these appear deep in the syntax trees. More ideally we'd just bolt on those latter in the hierarchy so as to show more schema types.
Finally somehow array and aggregate didn't get the message – and the time types have their own data encoding syntax.
The result is this:
BaseDataType – all the scalars on the parameter type side have this as a parent.
XXXDataType – next up the various scalars have this interim schema type. This is a vestige from 1.1. So for example IntegerDataType.
BaseTimeDataType – absolute and relative use this though.
ArrayDataTypeType and AggregateDataType – array and aggregate follow this line
Then on the argument side, this is mirrored but with "argument" stuck in front of it all:
ArgumentBaseDataType, ArgumentBaseTimeDataType – oddly Array and Aggregate on this side have ArrayDataTypeType and AggregateDataType as parents.
In the end we up with lots of "root" schema types that are all children of NameDescriptionType – BaseDataType, BaseTimeDataType, ArgumentBaseDataType, ArgumentTimeBaseDataType, ArrayDataTypeType and AggregateDataType.
There's no DataType, ScalarDataType or ComplexDataType which might more natural organize it.
Conclusion: this could all be better.
Reported: XTCE 1.2 — Fri, 10 Jul 2020 11:28 GMT
Updated: Tue, 1 Dec 2020 00:50 GMT