Open anweiss opened 3 years ago
Also, unless I'm reading the example wrong:
rect = {
interval<X>
interval<Y>
}
might result in ambiguity if the value inserted for the Y
generic parameter overlaps with any of the values computed from X
, no? I guess that's on the CDDL author to avoid.
Probably not much ambiguity (prioritized choice takes that away), but dead code.
On your point about using text strings to represent integers: there is an infinite amount of conversions and other operations that might be needed in a spec. Also, we probably need some expression capability to get assertions, co-occurrence constraints etc. into the language. So I think it will be worthwhile to collect a set of use cases (preferably not just synthetic ones) and start a design based on those.
(Some form of assertions also could help find consistency errors within a spec, like choosing X and Y so the intervals overlap.)
»Experience also indicates that simplified or specialized extension languages often have more features added and grow until they resemble a full programming language.« https://www.usenix.org/legacy/publications/compsystems/1994/fall_laumann.pdf#page=3
I'm not closing this issue: I think that we need a .json (equivalent to .cbor, maybe also a .jsonb64) anyway, and I think conversions like this could come with that package.
In the numeric addition example:
the computed member keys in the struct become unsigned integers. If one wants to use this when validating a JSON object, the validation should presumably fail because JSON doesn't allow keys that aren't strings. With that being said, it may still be useful to use the string equivalent of a computed member key from numeric addition when validating a JSON key.
For example, it may be useful to use the CDDL above to validate:
but there exists no way in CDDL to denote that the string representation of a numeric value should be used instead. A tool could certainly allow for that (e.g. via some sort of
--allow-member-keys-as-strings
flag), but then there are all sorts of implied semantics for the string representations of those numbers, byte strings, etc.So, at the end of the day, there should be a bit more info regarding the use of these control operators with JSON.