Type choice semantics for targets and controllers

[anweiss]

For some control operators, there are implied semantics on targets and controllers. For example, with .cat, both the target and controller MUST be strings. However, in the event that the target and/or controller are parenthesized types with multiple type choices between strings or bareword identifiers that resolve to type choices between strings, it isn't clear whether a validation implementation should attempt to concatenate each of the type choices, or if type choices should be disallowed altogether when used with control operators.

So for example, should:

a = ( "foo" / "foo " ) .cat b
b = "bar" / "baz"

be valid against any of the JSON strings"foobar", "foobaz", "foo bar" and "foo baz"? Or should this use of a type choice with a control operator be disallowed altogether due to potential overcomplexity on the part of the CDDL author?

[core-bot]

On 2020-11-17, at 23:04, anweiss ***@***.***> wrote: For some control operators, there are implied semantics on targets and controllers. For example, with .cat, both the target and controller MUST be strings. However, in the event that the target and/or controller are parenthesized types with multiple type choices between strings or bareword identifiers that resolve to type choices between strings, it isn't clear whether a validation implementation should attempt to concatenate each of the type choices, or if type choices should be disallowed altogether when used with control operators. So for example, should: a = ( "foo" / "foo " ) .cat b b = "bar" / "baz" be valid against any of the JSON strings"foobar", "foobaz",

Yes, yes.

"foo bar" and "foo baz”?

No, no.

Or should this use of a type choice with a control operator be disallowed altogether due to potential overcomplexity on the part of the CDDL author?

I think we should not build mechanism to enforce some (a little dubious) policy. The meaning of .cat as the set of values resulting from application of concatenation to the cross-product of its two input types is clear. I can easily imagine cases where that is useful: Option = “staple” / “fold” / “emboss” / “crumple” / “burn” Switch = Option / “no-” .cat Option Now, implementing that may be considered too hard for a tool implementer, and I must admit that the implementation I did tonight is focused on singletons (it can generate examples for, but not yet validate the above) — I sure will fix this if I get a bug report from someone who actually uses this case. Grüße, Carsten

[anweiss]

Thanks for the clarity here @cabo. This is helpful.