Re: [Cbor] CDDL Module Design

[Jim Schaad <[e-mail]>]

Adding new issues to the list:

1.  Are there any items for which the order of evaluation of the modules is
going to be important.  I think the answer is yes - consider adding elements
to a group and then using the group in an array.

2.  Are there places where the current definitions of anything get messed up
with multiple modules and ordering.  I am thinking of cuts in maps (where I
can't remember which hill things died on) or maybe the newly proposed
.feature control.

Jim


> -----Original Message-----
> From: CBOR <[e-mail]> On Behalf Of Jim Schaad
> Sent: Tuesday, June 30, 2020 10:17 PM
> To: 'Michael Richardson' <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [Cbor] CDDL Module Design
> 
> 
> 
> > -----Original Message-----
> > From: Michael Richardson <[e-mail]>
> > Sent: Tuesday, June 30, 2020 8:54 PM
> > To: Jim Schaad <[e-mail]>
> > Cc: [e-mail]
> > Subject: Re: [Cbor] CDDL Module Design
> >
> >
> > Jim Schaad <[e-mail]> wrote:
> >     > 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.
> >
> > Doesn't the version problem also include the "DLL hell" problem?
> > That is:
> >      module A includes module B.1 which includes C.1
> >             A includes module D.1 which includes C.2
> >
> > and who knows if C.1 and C.2 can be used at the same time?
> >
> > So I totally agree that this is a problem.
> >
> >     > I think therefore it
> >     > would be nice to have a naming system that recognizes version
> numbers,
> > 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.
> >
> > I think that this is probably a very elegant solution.
> >
> >     > 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?
> >
> > A think that I dislike about the ENTITY stuff in XML is that the URLs
> > are
> way
> > too specific.   Do you want avoid that?  Will it be some URN space?
> 
> I was thinking about the question of doing a URN instead of a URL - hence
the
> term naming scheme.  The interesting question is how should the naming be
> done and what short of mapping is needed.  One of the nice things about
DOIs
> is that they can be used as an indirect reference with a well known server
to
> get actual URLs
> 
> >
> >     > 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.  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.
> >     > *  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
> >
> > Can you give an example of (b)?
> > I think that Python mostly got this process right.
> 
> (b) is just - don't define any conflicts between what I am importing and
what I
> have written in the text.  If I am going to use COSE_Signed as an import,
then I
> really should define a different symbol in the current CDDL file by that
name.
> 
> >
> >     > 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?
> >
> > No. It just leads to stupid work arounds.
> > _ for things that should not be exported, but not enforced.
> 
> I tend to agree with this.  One of the interesting questions would be
transitive
> imports though.  If module A imports COSE_Signed from module B can module
> B import COSE_Signed from module B or must it reference module A.
> I remember the first time I figured out that ASN.1 allows this and to be
frank I
> found it somewhat irritating.  It does allow moving symbols between
modules,
> but that has the potential to break other modules suddenly.
> 
> >
> >     > 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.
> >
> > I prefer that the statement not be a pre-processor-like hack.
> 
> The interesting question then, is how much do we want to change the CDDL
> language.  If we do pragmas this is a standalone document.  If we do
changes in
> the grammar then it is harder to make this standalone.
> 
> >
> >     > 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.
> >
> > I don't understand.
> 
> Suppose I write a CDDL compiler - called my_great_cddl_compiler and
Carsten
> writes one called no_so_good_cddl_compiler.  I could reference pragmas as
> ME:UseInt32 and CB:UseInt32 as separate pragmas in the same file and each
> compiler would recognize that one that it implements and do the right
thing
> (which is to use some int sized at least 32 bits?)  They could have
different
> behavior for the same name.
> 
> >
> >     > 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).
> >     > 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.
> >
> > This is useful at the top-level file.
> > Particularly for a group of people who are working together.
> > For "location on my machine", I think that I'd rather be providing a
> command
> > flag, but I don't object to having ../.. paths or
> https://my.little.server.example/
> > in a file.
> 
> Another one at the top level might be to use one of the more interesting
things
> that the OSS compiler does is to allow one to say - This is the list of
symbols to
> emit which can be used rather than either emit everything or emit the
first
> symbol in the file which made me do some really strange things in the COSE
> CDDL.
> 
> Jim
> 
> 
> >
> > --
> > Michael Richardson <[e-mail]>, Sandelman Software Works
> > - = IPv6 IoT consulting =-
> 
> _______________________________________________
> CBOR mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cbor