Re: [Cbor] CDDL Module Design

[Carsten Bormann <[e-mail]>]

So here are a few terms (and items of thought) that I would like to propose as a ground structure:

Symbols: Rule names as defined in RFC 8610.  This namespace is used within a specification and should stay reasonably clean of considerations on where the name came from.  E.g., a CDDL specification today can use symbols from prelude and from itself.

External names: Names that go into a larger name space, some of which may be global.  A CDDL spec can import definitions associated with an external name (mapping that into symbols local to the spec) and export into (make its symbols available in) the global namespace.  

Global namespace: external names that are curated in such a way that there are no conflicts.  It probably makes sense to allow for “ecosystem namespaces”, i.e., a way to partition off subspaces of the global namespace that can be used in an SDO without the need for coordination with others.

Revision: a specific instant in the progression of a specification.  Revisions may or may not semantically differ (a new revision could have a better copyright statement, a new license, better acknowledgements, reordered rules, etc. without any semantic implications).

Module reference: a name that, at a particular point in time, identifies a set of specifications that make up a module (if that term makes sense).  Module references are intended to allow for evolution of the modules; they may also be frozen to specific revisions (which doesn’t allow for bug fixing).  Module references need to cope with the fact that a specific implementation may be bound to a state of the module that is earlier in time than the one considered most recent by a contributing entity; whether that state is compatible with the desired use of the module will have to be expressed in the module reference (e.g., by using feature identifiers).

Feature name: Name for a (potentially upwardly compatible, potentially not) state of a module that incorporates certain additions/changes.  A feature name can take the form of a version (≠ revision), or it can be more granular.

Semantic name: a name that interfaces with the world outside CDDL, e.g., an RDF class name.  These often will be URIs.  Often, a symbol in a specification will be annotated with a semantic name; this is of no consequence to the structural semantics of CDDL, but might turn up in a post-validation instance.

(It is not clear to me whether there needs to be a shortcut between semantic names and external names — I’d like to keep them separate for now.)

Note that keys (the name part of a name/value pair) in groups are often used as abbreviated semantic names (whether they are ignored at the CDDL level as in arrays or &-choices, or actually used as map keys).  There probably needs to be some way to map these to fully fleshed out semantic names.  (Note that these keys often are written as barewords, so they may look like symbols, but aren’t!)

Grüße, Carsten