Re: [Cbor] CDDL Module Design

[Jim Schaad <[e-mail]>]

> -----Original Message-----
> From: Carsten Bormann <[e-mail]>
> Sent: Wednesday, July 1, 2020 7:50 AM
> To: Jim Schaad <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [Cbor] CDDL Module Design
> 
> 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.

This is the case that I was thinking of.  

Module A
group = (
   element1 : string
)

Module B
group //= ( element2 : int )

Module C
group //= (element3 : float )

Module D
myArray = [ group ]


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

The question comes if you add more elements to the end of the map.  We have had this discussion during the cut process and I think that I lost that round but I would need to do a deep read on this to figure that out. Things become interesting if you do

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

More-attributes = ()

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

I am not sure that I do either, it just is something that raises questions about what happens if I add new fields to a map.   In the above, does the .feature on EXTENSION-POINT always come into effect if I add something to More-attributes in a different module?

Jim

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