Additional Control Operators for the Concise Data Definition Language (CDDL)
Extracted elements (20)
Leaving out an extension point entirely would mark instances using extensions as invalid; leaving it in without .feature marking would render mistakes (e.g., 'organisation' vs 'organization') invisible. The .feature operator threads between these two failure modes.
The .det operator was introduced because multi-line string literals for embedded ABNF need to be set flush left, but having indentation in source code promotes readability. Using .cat alone would preserve the indentation, making the embedded ABNF invalid.
The .feature operator can support a JSON/CBOR switch idiom (e.g., JC<J,C> = J .feature "json" / C .feature "cbor"), though CDDL currently has no way to enforce mutually exclusive use of features as would be required for such a switch.
The .feature operator was introduced because Boolean valid/invalid validation is too simplistic for rapidly evolving data models. It allows a specification to identify extension points and accept extensions while marking them as such, rather than treating unknown extensions as wholesale invalid.
The name .det was chosen as a shortcut for 'dedenting cat' rather than the more obvious .dedcat, which was rejected for being longer and invoking unpleasant images.
Two ABNF operators (.abnf and .abnfb) are needed because ABNF can define both byte sequences and UTF-8 text strings interpreted as Unicode scalar sequences, requiring distinct semantics for the two interpretations.
All rules referenced in an ABNF operator controller string must be defined within that string — there is no implicit import of core ABNF rules from RFC 5234 or other rule sets. Composition of shared rules must be done explicitly via .cat or .det.
The ABNF syntax within .abnf/.abnfb controllers is relaxed to allow a single line feed as a newline (CRLF = %x0A / %x0D.0A), as is customary for ABNF itself, though CDDL text strings make specifying newlines tedious.
For .abnf and .abnfb operators, the controller string MUST be a string. When a byte string, it MUST be valid UTF-8 and is interpreted as the text string with the same sequence of bytes.
For the .cat operator, the target and controller both MUST be strings. If the target is a text string, the result of the concatenation MUST be valid UTF-8.
For the .plus operator, the target and controller both MUST be numeric.
The ABNF controller string for .abnf/.abnfb must be one valid ABNF 'element' followed by zero or more valid 'rules' separated from the element by a newline, allowing the element to select from the ABNF rule list.
The .cat control operator identifies a string built from concatenation of the target and the controller. The concatenation is performed on the bytes in both strings, and the result has the same type as the target.
The .det control operator works like .cat except that both arguments (target and controller) are independently dedented before concatenation. Dedenting is defined as removing the smallest amount of leftmost blank space present in all non-blank lines from each line.
The .feature control operator annotates the target as making use of the feature named by the controller (usually a string). A validation tool may mark an instance as using a named feature and include the controller as the feature name and the target as feature detail in diagnostic output.
The .plus control operator identifies a number constructed by adding the numeric values of the target and the controller. If target and controller are of mixed numeric types (float and integer), the sum is converted to the type of the target; converting from float to integer selects the floor.
Two ABNF control operators are defined: .abnf for ABNF denoting sequences of Unicode scalar values (code points) represented as UTF-8 text strings, and .abnfb for ABNF denoting byte sequences. Both can be applied to targets of either string type.
When the .feature controller is an array, the first element is the feature name and the second element is the detail (usually a string), allowing the specification to hint that more limited detail than the full target is appropriate for diagnostic output.
IANA has registered six new entries in the 'CDDL Control Operators' registry: .plus, .cat, .det, .abnf, .abnfb, and .feature, all referencing RFC 9165.
The security considerations of RFC 8610 apply. The use of formal description techniques such as ABNF can not only simplify but sometimes also complicate a specification, potentially leading to security problems in implementations and the specification itself. ABNF should be judiciously applied and overly complex constructions avoided.