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

[Michal Vaško <[e-mail]>]

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.

Regards,
Michal
 
> 
> > 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
>