Re: [netmod] JSON to XML lossy conversion

Carsten Bormann <cabo@tzi.org> Fri, 17 July 2020 06:45 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 491D53A12E1 for <netmod@ietfa.amsl.com>; Thu, 16 Jul 2020 23:45:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Level:
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 iKv8-JKK_eac for <netmod@ietfa.amsl.com>; Thu, 16 Jul 2020 23:45:11 -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 2AB213A0F68 for <netmod@ietf.org>; Thu, 16 Jul 2020 23:45:10 -0700 (PDT)
Received: from [192.168.217.116] (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 4B7M7Q57Kfz103h; Fri, 17 Jul 2020 08:45:05 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <87mu3z4gum.fsf@nic.cz>
Date: Fri, 17 Jul 2020 08:44:57 +0200
Cc: Michal Vaško <mvasko@cesnet.cz>, netmod <netmod@ietf.org>
X-Mao-Original-Outgoing-Id: 616661097.163286-e3aba04ff84010214b46dbd973024086
Content-Transfer-Encoding: quoted-printable
Message-Id: <3A6BD609-92FE-4646-8CDA-6EF514353012@tzi.org>
References: <15dd-5f106300-3d-41094600@245675998> <87mu3z4gum.fsf@nic.cz>
To: Ladislav Lhotka <ladislav.lhotka@nic.cz>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/OlP-n457y93OXMamMNTsrH97g3U>
Subject: Re: [netmod] JSON to XML lossy conversion
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Jul 2020 06:45:14 -0000

> In my view, if it is a bug, it is in the design of the union type in YANG - there is no general way to signal the actual union member type for an instance.

Right.  The ambiguity is normally not a problem for a type choice (which is just a union of the possible values of all types given), unless what specific alternative was chosen is intended to carry semantics.

> I believe it is a good thing that some encodings allow for at least partial signalling.
> 
> Note that similar issues may arise even more often in CBOR, see e.g. comments for section 5.12 in
> 
> https://mailarchive.ietf.org/arch/msg/core/Zrb2yhSSdlouS6PI9qfsA1bsDB4/

In the original YANG (XML-only), everything was represented as a text string, so the ambiguity was the highest we see now.  YANG-JSON and YANG-CBOR provide progressively more disambiguating information, so the interpretation (which chosen alternative) may be different from the one after converting to YANG-XML.

It gets slightly worse if the non-text type has a conversion to text that is not fully nailed down; I don’t know if that is a problem with the current set of YANG types, but any new type could of course worsen the situation.

The onus is now on the author of the YANG module to make sure that the varying levels of ambiguity do not cause a problem.  I would be interested to know whether there is any tool support for this.

Grüße, Carsten