Changing the choice syntax to be more source code friendly

[oliviermartin]

What I am looking at is mapping the CDDL to my source code. Choices can currently be expressed in different forms with different syntax.
And it looks to me CDDL is more orienting towards CBOR validation rather than CBOR description. Am I right? Is it intented?

Here are examples from the current CDDL specification:

attire = "bow tie" / "necktie" / "Internet attire"
protocol = 6 / 17
delivery = (
	street: tstr, ? number: uint, city //
	po-box: uint, city //
	per-pickup: true
)

attire /= "swimwear"

delivery //= (
	lat: float, long: float, drone-type: tstr
)

basecolors = (
                black: 0, red: 1,  green: 2,  yellow: 3,
                blue: 4,  magenta: 5,  cyan: 6,  white: 7,
              )
extended-color = &(
                basecolors,
                orange: 8,  pink: 9,  purple: 10,  brown: 11,
              )

To clean it, first I will remove the choice define as a group (used by basecolors in the examples). The CDDL spec defines groups in the context of map or array. While the example basecolors would not have a sense at all in the context of map or array. If you want to keep the syntax, we could use =&(...) to always define "complex" choice.

While the example attire and protocol are only defined for CBOR data validation, the other examples are more used to structure CBOR data.

My suggestion would be to redefine the "choice" definition and have only two types of choices:

• the (validation) choice mainly uses for CBOR data validation. The syntax choice1 / choice2 / ... could be kept
• the named choice mainly uses for CBOR data representation. The named choice would cover all other choices and would require an annoted name for each entry. The name would not be used in the CBOR representation. The syntax |name1: choice1 | name2: choice2 | ... | could be used to represent named choice (| is often used to represent or operation in programming language).

So the examples above would be converted into:

delivery = | full-address: ( street: tstr, ? number: uint, city)
           | po-address: (po-box: uint, city)
           | pickup: per-pickup: true

delivery =| coordonate: (lat: float, long: float, drone-type: tstr)


basecolors =| black: 0 | red: 1 |  green: 2 |  yellow: 3 | blue: 4 |  magenta: 5 |  cyan: 6 |  white: 7
extended-color =| basecolors | orange: 8 | pink: 9 | purple: 10 | brown: 11

Using this syntax I would easily link these definitions to my source code. For instance in C, I would have:

enum basecolors { BLACK = 0, RED = 1, GREEN = 2, ...}
enum extended_color { BLACK = 0, RED = 1, GREEN = 2, ..., ORANGE = 8, ...}
struct delivery {
	enum { FULL_ADDRESS, PO_ADDRESS, PICKUP, DRONE } type;
	union {
		struct { char* street; int number, char* city; } full_address;
		struct { int po_box; char* city; } po_address;
		struct { bool per_pickup } pickup;
		struct { float lat; float long; char* drone_type; } drone;
	}
}

Using the current CDDL syntax, it is impossible to link group choice to source code. And it makes hard to maintain the changes.

[cabo]

CDDL is in wide use in a number of SDOs at this point and has already been used in a number of RFCs. Proposals to make major changes its syntax would need to meet a very high bar now.

As of today, the cddl tool contains a basic mechanism to extract C code (in the form of #define statements). There is no attempt to map group choices to union structures, but I don't see why this would be impossible with the current syntax.