Re: [Cbor] CDDL Module Design

[Jim Schaad <[e-mail]>]

> -----Original Message-----
> From: CBOR <[e-mail]> On Behalf Of Carsten Bormann
> Sent: Tuesday, June 30, 2020 10:33 PM
> To: Jim Schaad <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [Cbor] CDDL Module Design
> 
> 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.

There is also nothing to prevent the reuse of the same name in the in the same namespace by multiple contributors.  

> 
> > 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.)

I am happy with the term revision number here.  Without having a better description of what you think is the difference, I am not sure that I see a significant one.  I do have a potential problem with the use of feature identifiers as we would not be tagging it with two different meanings that need to be distinguished.  At one point were we going to use this for differences in the CDDL language and now you are also using it for differences in CDDL sources.

> 
> > 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.)

And yet C++ does end up with header files which need to be included (or duplicated) in order to have the same consistent view of what any class does.   It also will end up with problems if two different source files declare (and define) a single name in the same namespace.

> 
> > 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
> 
> 
> _______________________________________________
> CBOR mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cbor