Subject: [Cbor] CDDL modules and Semantic labels

From: Carsten Bormann <[email-masked]>
Date: Fri, 10 Jul 2020 18:21:44 +0200

A CDDL specification can not only be used for validating an instance (which is yielding a yes/no decision and nothing else), but also to annotate the instance tree with semantic labels (resulting in an annotated "post-validation instance").

(A not very well-developed version of semantic labels becomes visible as comments in the CDDL tool when using the secret "vp" or "gp" features.)

There are two main sources for semantic labels in CDDL:

-- rule names
-- keys in group entries

When validating an instance successfully(*) matches a subtree against a rule, the name of the rule can be used as a semantic identifier for that subtree.  This means that rule names can have an impact beyond serving as an internal identifier in a CDDL specification.

We currently do not have a way to indicate that a rule name is *intended* to serve as a semantic identifier; so rules that only exist to structure or factor some specification may accidentally introduce an unwanted semantic identifier.  Of course, a simple convention such as capitalizing semantic identifiers and using lower case rule names for rules without such identification intent works.  Once we are putting together specifications from modules coming from different sources, we'd need to agree on such a convention though, or be able to indicate it separately for each module.

Keys in group entries have an implicit identifying meaning (obvious for maps, where they actually occur in the data item), or their meaning can be buried in the specification (for arrays and "&" choices -- see Section 2.2.2.2 of RFC 8610 [1] for an example of the latter).  Since they generally are redundant, some identifying intent could be implied from the latter use.  However, often the identification is local to the array/choice; it would be beneficial to be able to anchor these in their context:

steak = &(bleu: 0, a-point: 1, incinere: 2)
couleur = &(rouge: 0, jaune: 1, vert: 2, bleu: 3)

Grüße, Carsten

(*) Where "successfully" here means that there is not only a match, but that this match is the one that is actually used in the enclosing construct (i.e., it is not undone through backtracking).
[1]: https://tools.ietf.org/html/rfc8610#section-2.2.2.2