Changing the choice syntax to be more source code friendly
Opened this issue · 1 comments
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 representor
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.
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.