Re: [Cbor] CDDL Module Design

[Carsten Bormann <[e-mail]>]

Hi Jim,

we have had a long discussion about namespacing in the SDF work, and came up with:
https://www.ietf.org/id/draft-onedm-t2trg-sdf-00.html#name-names-and-namespaces

Now SDF is not CDDL, but I think there are lessons to be learned.

For a while, we were thinking about using URIs to find referenced parts of a specification.  This is comparable to the way Java does its module naming; you essentially need to put the code into the place that is implied by its name.

Instead, we have decided to go for a push model, which is essentially the way C++, C#, and other languages maintain their namespaces.  A module declares into which namespaces its names go.  There is no automatic finding of modules, but there also is no pain about who can contribute to a namespace.

> On 2020-07-01, at 02:52, Jim Schaad <[e-mail]> wrote:
> 
> Here is a topic that we can potentially discuss tomorrow if there is extra
> time on the agenda.
> 
> When looking at a CDDL module design, there are a set of questions that I
> think need to be addressed:
> 
> 1.  What is the naming scheme to be used?  Both XML Schema and ASN.1 use
> unique identifiers for a module.  The problem with this approach is that a
> revised module has a new identifier even if all of the changes were
> preserving of the old module.  This can also present problems if two
> different versions of the same module are used as it can be difficult to
> know which version of a module is being provided.   I think therefore it
> would be nice to have a naming system that recognizes version numbers,

(I think you are talking about revision numbers.
Version numbers are often not what one wants; instead one should use feature identifiers.)

> but
> can be used with a "latest version" mode.  One possible way to do this would
> be to use a query parameter to get a specific version of a module while
> without the query parameter the compiler grabs the most recent version it
> has.
> 
> 2.  Do want the naming scheme to be used to access a module name from the
> web, and to create a server to host all of the IETF based CDDL modules?

That was what we decided we didn’t want to do in SDF.

> 3.  For any number of reasons we need to be able to state that some symbols
> are going to be imported from a different module.  

Note how C++ doesn’t really do that.
(Well, if you declare a name and don’t define it, it needs to be external.)

> There are some issues
> around doing a couple of other things:
> *  If all symbols are imported then you either need to have a module based
> naming system or you need to ensure that there are no collisions.

I would like to separate the external naming system from the internal one we use in a spec.

Note how a spec already today uses symbols from the prelude and from the spec itself.  (This of course works “automagically” only because the prelude is fixed and you simply cannot use the symbols that the prelude squats on.)

> *  If only specific symbols are imported, then they could either be a) made
> to be unique by renaming or b) made to be unique in the current module
> simply by how the module is written

Yes.

> 4.  ASN.1 has a method to say that only specific symbols can be exported
> from a module.  I have never used this capability and I am not clear that it
> would be useful to have here.  Should we support it anyway?

I think there might be a place for an advisory-level setting (as in “these names will normally be imported if this module is imported whole-sale”).  Experience shows that there are good reasons to violate any “encapsulation” attempt, so I would not disallow importing further names from a module explicitly.

> 5.  How should the system be setup to be able to recognize this capability.
> The suggestion in the freezer document currently is to use a pragma system.
> Introducing a pragma system can easily be seen as a step to allow for
> compilers of CDDL to be written.   The A2C compiler that I wrote used --#
> and #-- as the start and stop delimiters for pragmas as "--" is the
> start/stop comment character.  (ASN.1 is not line based so there is no
> comment till a return.)  A similar approach can easily be used here.

This is the approach I would prefer.

However, there also is semantics imparted by using a symbol.
In actual CDDL usage, the symbols used become annotations in the post-validation instance.  These annotations will need to be namespaced, and possibly be linked to RDF names (which are URIs not intended for dereferencing).

> 6.  If we use a pragma naming system, do we want to setup in advance for it
> to have namespaces so that a single module could be used with different
> compilers.  I ended up using a different string  than the OSS compiler did
> ("--<" ">--") to be able to do this but having a namespace could also
> support this.

Indeed, we could play around with more than one module/namespace management system, as long as there is a way to generate a basic CDDL specification from each.

> 7.  What set of pragmas are we looking at to start with.  XML Schema has
> some attributes that can be used for controlling the compiler.  One of this
> is a location hint attribute which can be used for giving alternate
> locations to use for finding a module (such as a location on my machine).

Tempting, but this leads us back into pull land.

> There might be some other pragmas that might be useful to specify as well.
> It might be easier to specify co-occurrence constraints using pragmas rather
> than trying to put it directly into the language.

I think that all constraints need to be part of the language.

Grüße, Carsten