Re: [netmod] JSON to XML lossy conversion

[Carsten Bormann <[e-mail]>]

On 2020-07-17, at 12:03, Vladimir Vassilev <[e-mail]> 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