Numeric addition with JSON keys

[anweiss]

In the numeric addition example:

interval<BASE> = (
  BASE => int             ; lower bound
  (BASE .plus 1) => int   ; upper bound
  ? (BASE .plus 2) => int ; tolerance
)

rect = {
  interval<X>
  interval<Y>
}
X = 0
Y = 3

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:

{
  "0": 10,
  "1": 10,
  "3": 10,
  "4": 10,
  "5": 10
}

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.

[anweiss]

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.

[cabo]

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

[cabo]

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.