[Cbor] CDDL Module Design
Jim Schaad <ietf@augustcellars.com> Wed, 01 July 2020 00:52 UTC
Return-Path: <ietf@augustcellars.com>
X-Original-To: cbor@ietfa.amsl.com
Delivered-To: cbor@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F9843A0842 for <cbor@ietfa.amsl.com>; Tue, 30 Jun 2020 17:52:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gRKsIHS4IHqo for <cbor@ietfa.amsl.com>; Tue, 30 Jun 2020 17:52:26 -0700 (PDT)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E3153A083F for <cbor@ietf.org>; Tue, 30 Jun 2020 17:52:26 -0700 (PDT)
Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 30 Jun 2020 17:52:21 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: cbor@ietf.org
Date: Tue, 30 Jun 2020 17:52:19 -0700
Message-ID: <03c701d64f41$e1763fa0$a462bee0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-us
thread-index: AdZPP7lFcxcs7rTWQ96MobGVRLmIuA==
X-Originating-IP: [73.180.8.170]
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/BayziLDbvL8zghvYYqsdJpiTp-0>
Subject: [Cbor] CDDL Module Design
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <cbor.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cbor>, <mailto:cbor-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cbor/>
List-Post: <mailto:cbor@ietf.org>
List-Help: <mailto:cbor-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cbor>, <mailto:cbor-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Jul 2020 00:52:28 -0000
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, 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? 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 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? 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. 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. 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. Jim
- [Cbor] CDDL Module Design Jim Schaad
- Re: [Cbor] CDDL Module Design Michael Richardson
- Re: [Cbor] CDDL Module Design Jim Schaad
- Re: [Cbor] CDDL Module Design Carsten Bormann
- Re: [Cbor] CDDL Module Design Carsten Bormann
- Re: [Cbor] CDDL Module Design Jim Schaad
- Re: [Cbor] CDDL Module Design Carsten Bormann
- Re: [Cbor] CDDL Module Design Jim Schaad
- Re: [Cbor] CDDL Module Design Carsten Bormann
- Re: [Cbor] CDDL Module Design Michael Richardson
- Re: [Cbor] CDDL Module Design Jim Schaad
- Re: [Cbor] CDDL Module Design Carsten Bormann
- Re: [Cbor] CDDL Module Design Michael Richardson
- Re: [Cbor] CDDL Module Design Carsten Bormann