[Cbor] CDDL modules and Semantic labels
Carsten Bormann <cabo@tzi.org> Fri, 10 July 2020 16:21 UTC
Return-Path: <cabo@tzi.org>
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 C26B33A0C57
for <cbor@ietfa.amsl.com>; Fri, 10 Jul 2020 09:21:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001,
RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001,
URIBL_BLOCKED=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 LF9-RMAzn0Xh for <cbor@ietfa.amsl.com>;
Fri, 10 Jul 2020 09:21:46 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de
[134.102.50.17])
(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
(No client certificate requested)
by ietfa.amsl.com (Postfix) with ESMTPS id AB3513A0C46
for <cbor@ietf.org>; Fri, 10 Jul 2020 09:21:46 -0700 (PDT)
Received: from [172.16.42.100] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4B3JG10D0CzycY;
Fri, 10 Jul 2020 18:21:45 +0200 (CEST)
From: Carsten Bormann <cabo@tzi.org>
Content-Type: text/plain;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Mao-Original-Outgoing-Id: 616090904.268791-18b6bfe9dfda615522275424a0b53e86
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Fri, 10 Jul 2020 18:21:44 +0200
Message-Id: <8E326169-AB6E-4447-8D45-73AEB210866B@tzi.org>
To: cbor@ietf.org
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/8iot5AeY46IXdt5HYWORHjxcl28>
Subject: [Cbor] CDDL modules and Semantic labels
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: Fri, 10 Jul 2020 16:21:50 -0000
A CDDL specification can not only be used for validating an instance (which is yielding a yes/no decision and nothing else), but also to annotate the instance tree with semantic labels (resulting in an annotated "post-validation instance"). (A not very well-developed version of semantic labels becomes visible as comments in the CDDL tool when using the secret "vp" or "gp" features.) There are two main sources for semantic labels in CDDL: -- rule names -- keys in group entries When validating an instance successfully(*) matches a subtree against a rule, the name of the rule can be used as a semantic identifier for that subtree. This means that rule names can have an impact beyond serving as an internal identifier in a CDDL specification. We currently do not have a way to indicate that a rule name is *intended* to serve as a semantic identifier; so rules that only exist to structure or factor some specification may accidentally introduce an unwanted semantic identifier. Of course, a simple convention such as capitalizing semantic identifiers and using lower case rule names for rules without such identification intent works. Once we are putting together specifications from modules coming from different sources, we'd need to agree on such a convention though, or be able to indicate it separately for each module. Keys in group entries have an implicit identifying meaning (obvious for maps, where they actually occur in the data item), or their meaning can be buried in the specification (for arrays and "&" choices -- see Section 2.2.2.2 of RFC 8610 [1] for an example of the latter). Since they generally are redundant, some identifying intent could be implied from the latter use. However, often the identification is local to the array/choice; it would be beneficial to be able to anchor these in their context: steak = &(bleu: 0, a-point: 1, incinere: 2) couleur = &(rouge: 0, jaune: 1, vert: 2, bleu: 3) Grüße, Carsten (*) Where "successfully" here means that there is not only a match, but that this match is the one that is actually used in the enclosing construct (i.e., it is not undone through backtracking). [1]: https://tools.ietf.org/html/rfc8610#section-2.2.2.2
- [Cbor] CDDL modules and Semantic labels Carsten Bormann