Subject: [apps-discuss] Comments on draft-greevenbosch-appsawg-cbor-cddl-05

From: "Jim Schaad" <[email-masked]>
Date: Thu, 16 Apr 2015 13:14:50 -0700

I am finally getting around to transcribing the comments that I made on my
kindle so here they are:

Section 2.1 - "The parentheses for groups are optional" - This statement is
not always true.  There are a large number of cases where the grouping
parentheses are required.  Suggest "In this case the grouping parentheses
are optional"

Counter example is given in Figure 1.  Or maybe not after reading the ABNF.
It appears that the only place where the parens are mandatory for a group is
when following an '&' character.  However, parens are also used in rule
type2 where it can be confused with a group since it is using parens to
delimit things.

Section 2.1.2 - "The end of a group can be marked by a ')'" - I think that
this bullet should be combined with the previous bullet because you don't
want to be in the situation where people think that only one of these is
required.   Thus "Groups can be marked by wrapping them in '(' and ')'."

Section 2.2.2 - Choices:  In using the CDDL compiler with a syntax enforcer,
I have gotten very upset with the current gramper where you are using type1
and not type in the grpent rule.  The problem is that one comes up with a
very inconsistent view of the world where you get

Attire = a / b / c

Is legal but

Person = {

   name: tstr,

   attrire: a / b / c

}

Is not the same thing as using 'Attire' instead.  There is nothing that
tells a person why the first should be ok and the second not be ok.  I don't
know what other problems come into existence if this is changed however I
believe that a structure like

     (name:tstr) / ( bstr)

Is more understandable to a reader than

     name: tstr / bstr

The second to me says that both items are attached to 'name:' rather than
being what is stated in the first line.

Section 3.5.2 - In the example where you define 'x', you should highlight
for readers that 'int' is a defined type that includes a choice.  This is
not clear if you don't managed to remember it so that it does not seem on
first blush that this is really a multi-valued keytype.

Appendix E - I would like to be able to place groups into choices.  (See my
COSE draft for how I want to do this).

Open issues:  My expectation is that the following are going to do the same
thing:

[* groupname ]

[* (group elements)]

And I would have guessed that it works the opposite of how the tool is
described.  That is I would assume that the group would be multiplied and
not the individual elements of the group.  (Gets real confusing if there are
nested groups or the syntax changes later.)

Open Issue:  Should there be a convention - possibly a comment - to indicate
that there is a module from another specification that is to be appended to
this one.  I don't know that we want people to cut and paste this
specification into another specification just to get the same effect as the
Prelude.

Jim