Re: [netmod] ?==?utf-8?q? JSON to XML lossy conversion

Michal Vaško <> Fri, 17 July 2020 06:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8F8653A12FB for <>; Thu, 16 Jul 2020 23:57:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.319
X-Spam-Status: No, score=-1.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id C9An4iohNNiy for <>; Thu, 16 Jul 2020 23:57:53 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 599BD3A12E5 for <>; Thu, 16 Jul 2020 23:57:52 -0700 (PDT)
Received: by (Postfix, from userid 999) id 949BC60287; Fri, 17 Jul 2020 08:57:50 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=kalendar; t=1594969070; bh=9l62UOQ2H5bfpB3PiFRfaeXhgZTNLdxdMfsTgxJ1raw=; h=In-Reply-To:From:Date:Cc:To:Subject; b=G9hWsD6b4+VdVBEqPMEA7rb9HKc6+NHTEQlVtliDZhpmnuIJPOq6Zmd9wPrtISGfR aOb3Fm8h3Z+SVXt4AOCTiDe88hwevlzlIGjDm1Dq36zG14bQWCKj1cPMzoABYvCrme Xqsw8RcEeJ0vAlFF98tAYjrP6m4dMCfktFnRweaQ=
Content-Type: text/plain; charset="utf-8"
In-Reply-To: <>
From: =?utf-8?q?Michal_Va=C5=A1ko?= <>
X-Forward: 2001:67c:1220:80c:b5:55d3:81d5:8636
Date: Fri, 17 Jul 2020 08:57:50 +0200
Cc: "Ladislav Lhotka" <>, "netmod" <>
To: "Carsten Bormann" <>
MIME-Version: 1.0
Message-ID: <1da7-5f114c00-115-50d47000@26535751>
User-Agent: SOGoMail 2.3.23
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [netmod] =?utf-8?b?Pz09P3V0Zi04P3E/ICBKU09OIHRvIFhNTCBsb3NzeSBj?= =?utf-8?q?onversion?=
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 17 Jul 2020 06:57:57 -0000

Hi Carsten,
you had an interesting idea to have tools that could warn about these problems (although that is hardly a proper solution) but it is not really possible because the problem may occur whenever there is union with a 'string' and 'int8' - 'int32', 'uint8' - 'uint32', or 'boolean', in any order. Meaning in lots of, if not most, unions. And I have considered only XML and JSON, I have not looked into CBOR, which may make it even worse.

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