New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve modeling of annotations in Ion Schema #51
Comments
In the course of modeling PartiQL test cases in ion text, one proposal for a way to model the test cases was something like:
In attempting to model this in Ion Schema, it doesn't currently seem possible to:
|
ProposalThe The existing Syntax
Evaluation
Sample ImplementationThis is an example of one way of implementing the constraint to serve as a reference for the correct behavior. There is no requirement that it must be implemented this way. This example covers only the new logic. Actual implementations should also include the existing annotations logic. private fun test(value: IonValue, typeRef: Type): Boolean {
val annotationsList = value.typeAnnotations.mapTo(ionSystem.newEmptyList()) { ionSystem.newSymbol(it) }
return typeRef.isValid(annotationsList)
} Alternatives ConsideredIt would be possible to completely eliminate the existing annotations syntax since this is going into a new major version of Ion Schema and therefore is not required to be backwards compatible. However, the reasons for keeping the old syntax are twofold
|
The behavior of some of the ISL 1.0 syntax is unexpected and/or not useful, so perhaps only part of the old syntax should be retained. By removing |
Resolved by #76 in Ion Schema 2.0 |
Problem
The
annotations
constraint has some confusing interactions between the modifiers (ordered::
,closed::
,required::
, andoptional::
); and without any modifiers, theannotations
constraint actually does nothing, which is a really confusing default behavior. Theannotations
constraint is also unable to model things like:Possible Solution
We could model annotations (approximately) as a list of symbol tokens, and allows the
annotations
constraint to take a<TYPE_REF>
as its argument.For example:
This can be done in a backwards compatible way that preserves the existing syntax because all
<TYPE_REF>
are either asymbol
or astruct
, which can be clearly distinguished from the existing syntax that is alist
of symbols.The text was updated successfully, but these errors were encountered: