Re: [netmod] JSON to XML lossy conversion

[Vladimir Vassilev <[e-mail]>]

On 17/07/2020 09.11, Ladislav Lhotka wrote:

>
> On 17. 07. 20 8:57, Michal Vaško wrote:
>> 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.
> What you can do is to define a metadata annotation specifying the union
> member for a particular instance, and implement it in your tools. This
> would be a solution independent of instance representation.


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

If the XML representation rules in the YANG definition were provided as 
an inherent constraint to the value space of the union type there was 
not going to be ambiguity and there would have been a bug in any 
encoding that does not enforce this exact constraint. This is not 
spelled out in RFC7950 but is a good rule of thumb to avoid unions that 
have value space that can not be represented in XML.

The alternative is to rework the XML representation to not have such 
limitation in a next version of YANG (e.g. adding XML attributes with 
the active member type index and name).

That said I think there is one underestimated feature of the union type 
being entirely mapped to a string also for integer types as it is in the 
current XML encoding definition. Without requirement for resolving which 
member type the data actually is representing but just validating there 
is at least one match allows implementations to encode the data without 
resolving a possibly complex logical relationship. For example a union 
of interface index and leafref to interface name (for whatever reason 
someone would design such a union). You really do not need to know if 
there is an interface named "2" in the candidate configuration when you 
send <edit-config> in XML. With JSON you have to resolve this.

/Vladimir


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