Re: [Cbor] CDDL Module Design

[Carsten Bormann <[e-mail]>]

Hi Jim,

let me pick on your example some more :-)

> This is the case that I was thinking of.  
> 
> Module A
> group = (
>   element1 : string
> )
> 
> Module B
> group //= ( element2 : int )
> 
> Module C
> group //= (element3 : float )
> 
> Module D
> myArray = [ group ]

Right.  Note that `group` is a group choice, so only one (and exactly one) of the alternatives can be chosen.  As the types “element1", “element2", “element3” (yes, the bare words turn into strings) do not overlap, the sequence in the choice is irrelevant.  If they did overlap, the first match would win, and the implied cut makes sure the alternatives are not tried.

So this is different from “adding entries to the group”, which would allow multiple of the entries to go into the array.

>>> 2.  Are there places where the current definitions of anything get
>>> messed up with multiple modules and ordering.  I am thinking of cuts
>>> in maps (where I can't remember which hill things died on) or maybe
>>> the newly proposed ..feature control.
>> 
>> Ordering within a group (different from the above) is important.
>> (That order controls cuts and other forms of prioritized choice, even if the
>> group creates a map that by definition is not order-sensitive.) But composition
>> from separate rules needs to be explicit here, e.g. in SDF:
>> 
>> sdfinfo = {
>> title: text
>> version: text
>> copyright: text
>> license: text
>> EXTENSION-POINT
>> }
>> 
>> EXTENSION-POINT = ( * text => any )
>> 
>> Putting the extension point first would enable the use of values that do not
>> match `text` in title, version, copyright, and license entries.
>> But the specifier put EXTENSION-POINT last explicitly, so there is no such
>> danger.
> 
> The question comes if you add more elements to the end of the map.  We have had this discussion during the cut process and I think that I lost that round but I would need to do a deep read on this to figure that out. Things become interesting if you do
> 
> sdfinfo = {
>  title: text,
>  version: text,
>  copyright: text,
>  license: text,
>  More-attributes,
>  EXTENSION-POINT
> }
> 
> More-attributes = ()

I would expect you are trying to build a group choice that is called More-attributes, so that we then can say:

More-attributes //= (foo: “bar”)

Starting that choice with () doesn’t work very well — the empty group always matches, and because of prioritized choice, nothing of the other alternatives is tried.

So let’s start it with something that never matches.  There is no idiomatic way to do this in CDDL yet, so let me invent one:

More-attributes = (1 .eq 2 => 3)

(This stochastically breaks the little brain of the CDDL tool, but let’s ignore that for now; maybe there are better ways to build impossible group choices.)

Now I can add 
More-attributes //= (foo: “bar”)
And
More-attributes //= (3: 4)

For good measure.

The way this is used in the maps means that only exactly one of the choices is ever added, which is not what I would call “adding entries"; if you want to be able to add from all of them (and optionally so), use

 * More-attributes,

in the map.

This is all a bit tedious, why it is not a very idiomatic way to build up maps.

Grüße, Carsten