Re: [Cbor] CDDL Module Design

[Carsten Bormann <[e-mail]>]

Hi Jim,

On 2020-07-01, at 16:30, Jim Schaad <[e-mail]> wrote:
> 
> 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.

What do you mean by “adding elements”?

CDDL was designed to be insensitive to the order of rules, with the exception of the special meaning of the first rule.
I would expect that we compose at the level of rules.

However, prioritized choice and  “/=“/"//=“ conspire against that original design.  So, yes, where a choice is composed from multiple “/=“/"//=“ rules, the order is indeed relevant.

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

Ordering within a group (different from the above) is important.
(That order controls cuts and other forms of prioritized choice, even if the group creates a map that by definition is not order-sensitive.)
But composition from separate rules needs to be explicit here, e.g. in SDF:

sdfinfo = {
 title: text
 version: text
 copyright: text
 license: text
 EXTENSION-POINT
}

EXTENSION-POINT = ( * text => any ) 

Putting the extension point first would enable the use of values that do not match `text` in title, version, copyright, and license entries.
But the specifier put EXTENSION-POINT last explicitly, so there is no such danger.


I can’t imagine at the moment how .feature would introduce new order sensitivities.

Grüße, Carsten


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