[Cbor] CDDL modules: sockets and features

[Carsten Bormann <[e-mail]>]

CDDL provides a convention to indicate extension points by "sockets", Section 3.9 of RFC 8610 [1].  That section provides a few examples how sockets can be used for indicating extensibility for both type choices and group choices.

In practice, a specification will tend to provide the "plugs" (alternatives filled in for a socket) that exist at the time the specification, but of course cannot provide those that will be defined only in the future.

A common idiom to provide unlimited extensibility is to provide the general type of the alternatives expected in the socket as a last item in the choice:

foo = $foo / text
$foo /= "ant"
$foo /= "bat"
$foo /= "cat"

This can be combined with .within to restrict what can go into the socket:

foo = $foo .within text / text
...

(which is a bit non-DRY [2], but usually tolerably so).

The problem with this idiom is that anything validates now; there is no longer any help in identifying typos.  The .feature control operator comes to the rescue:

foo = $foo .within text / text .feature "foo-ext"
...

When the CDDL tool is asked to generate ten examples for this:

/foo/ "cat"
/foo/ "isolationist"
/foo/ "treater"
/foo/ "bat"
/foo/ "ant"
/foo/ "bat"
/foo/ "epigenist"
/foo/ "transpersonal"
/foo/ "recast"
/foo/ "uncompounding"

it tells us:

** Features potentially used: foo-ext: ["isolationist"]
** Features potentially used: foo-ext: ["treater"]
** Features potentially used: foo-ext: ["epigenist"]
** Features potentially used: foo-ext: ["transpersonal"]
** Features potentially used: foo-ext: ["recast"]
** Features potentially used: foo-ext: ["uncompounding"]

So we get warned (the warning is not a validation failure!) that there are six new words in the foo-ext extension point (some of which might be typos) besides the already sanctioned usage of ant, bat, and cat.

<aside>

foo = $foo .within text / text .feature "foo-ext"

is a rather verbose construct with only two actual pieces of information:

-- foo, the name of the choice, which generates $foo and "foo-ext", and
-- text, the type to be satidfied by all the alternatives.

Unfortunately, CDDL's generics are not powerful enough to construct other rule names ($foo) or text strings ("foo-ext") from an argument (foo); C language connoiseurs may remember the hacks that were used initially and then replaced by stringification (# operator) and concatenation/token pasting (## operator) [3] -- CDDL doesn't have those (and is clean enough not to support the earlier hacks).
Also, generics in CDDL defines types or groups, not entire rules.
So we cannot abbreviate

foo = $foo .within text / text .feature "foo-ext"
as
Make-Extension-Point<foo, text>

</aside>

Sockets have been defined already to allow composition, there is relatively little support needed to do that composition beyond single modules (some form of namespacing, I'd think).

A related question is how CDDL specifications might incorporate alternatives that are registered in an IANA registry; this could be modeled as a module import to a module that is generated from the current state of that registry.

Grüße, Carsten

[1]: https://tools.ietf.org/html/rfc8610#section-3.9
[2]: https://en.wikipedia.org/wiki/Don%27t_repeat_yourself
[3]: https://en.wikipedia.org/wiki/C_preprocessor#Token_stringification