Re: [netmod] JSON to XML lossy conversion

Carsten Bormann <cabo@tzi.org> Fri, 17 July 2020 16:09 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 345963A0829 for <netmod@ietfa.amsl.com>; Fri, 17 Jul 2020 09:09:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.918
X-Spam-Level:
X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, 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 oG2jyl9IlFp1 for <netmod@ietfa.amsl.com>; Fri, 17 Jul 2020 09:09:56 -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 E62AE3A0807 for <netmod@ietf.org>; Fri, 17 Jul 2020 09:09:55 -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 4B7bg53GLYzyW7; Fri, 17 Jul 2020 18:09:53 +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: <ec0176fd-7b37-f356-825a-c90e86f8f1c3@lightside-instruments.com>
Date: Fri, 17 Jul 2020 18:09:52 +0200
Cc: Ladislav Lhotka <ladislav.lhotka@nic.cz>, "netmod@ietf.org" <netmod@ietf.org>
X-Mao-Original-Outgoing-Id: 616694992.782456-e415e8c2063a59b5910d0278443b416d
Content-Transfer-Encoding: quoted-printable
Message-Id: <7DBC7BE2-0A54-4F2F-BD89-93BED7CB60EF@tzi.org>
References: <1da7-5f114c00-115-50d47000@26535751> <2a3fe9be-9319-2f19-e18d-be723379953f@nic.cz> <ec0176fd-7b37-f356-825a-c90e86f8f1c3@lightside-instruments.com>
To: Vladimir Vassilev <vladimir@lightside-instruments.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/o9vc9hwttTI3S1oU5hpMK8XrE1I>
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 16:09:58 -0000

On 2020-07-17, at 12:03, Vladimir Vassilev <vladimir@lightside-instruments.com> wrote:
> 
> IMO this does not solve the problem that XML can not encode all values of the value space in certain awkward unions (JSON and CBOR can't do that either only the constraints are alternative supersets).

The reason YANG-CBOR cannot do that is that the union can evolve, and might gain or lose some branches in this evolution.  (Otherwise we would have done something crude like numbering the branches.)

The term “union” of a set of types means that all values in all these types can be used.
It does not mean that any actual value identifies which of the branches it is in.

Apparently, this is not what YANG means with “union”.  ASN.1 has “choice”, but leaves the onus of all the branches looking different (usually using ASN.1 “tags”) to the specification writer.

The text in 9.12 of 7950 seems to say there is some sequential matching that does identify the branch.  It nicely ties this to the specifics of an XML encoding, and 6.10 of 7951 tells us it’s different in JSON.  

YANG-CBOR goes the extra mile here and defines special encodings that are only used within unions (6.6, 6.7, 6.12), which are meant to be a bit closer to the text-based encodings, so the outcome of all the above is closer to XML/JSON than it would be with the more optimized encoding we use otherwise.  This is a rather ugly rucksack, but we didn’t find a better way to keep compatibility with random YANG specs.  If you redesign unions (e.g., turning them into explicit choices), please do this in a way that allows YANG-CBOR to return to its more optimized ways.

Grüße, Carsten