The current OSI spec deals with dialects in a very heavyweight way:
- Expressions allow for multiple implementations, since they can have different ones for each dialect
- Expressions are commonly used for Fields and Metrics.
This has a number of long term implementations that may make these untenable:
- Any new concept with an expression will need to add this as well
- We don't have any semantics around what to do if there are multiple dialects for an expression. Which should get run?
- We don't have any way to ensure they all act the same.
This may ultimately make this standard untenable to implement and unreliable for using. If there is drift across the different dialect implementations, then depending on which is chosen, the user may get different results. Since, they are all setup with the same name this adds inherent fragility into the spec.
This issue proposes a different approach:
- Each expression has only one implementation
- There is a dialect at the document level
- Semantic View Composability will support documents crossing dialects (providers can provide errors in the case they cannot support the included dialect).
This will make dialect optional. If it is not filled in. If OSI determines a common expression language, than the default will be that. If not, then the provider should assume its own dialect.
The current OSI spec deals with dialects in a very heavyweight way:
This has a number of long term implementations that may make these untenable:
This may ultimately make this standard untenable to implement and unreliable for using. If there is drift across the different dialect implementations, then depending on which is chosen, the user may get different results. Since, they are all setup with the same name this adds inherent fragility into the spec.
This issue proposes a different approach:
This will make dialect optional. If it is not filled in. If OSI determines a common expression language, than the default will be that. If not, then the provider should assume its own dialect.