Re: [netmod] JSON to XML lossy conversion

Hi Michal,

Michal Vaško <mvasko@cesnet.cz> writes:

> Hello,
> it seems that there are cases when YANG data represented in JSON include more information than when converted to XML. Example:
>
> YANG:
>
> module a {
>   leaf l {
>     type union {
>       type string;
>       type uint8;
>     }
>   }
> }
>
> JSON:
>
> {
>   "a:l": 20
> }
>
> These data will be parsed as the leaf "l" of type "uint8" based on the JSON specs [1]. Then, when printed again
>
> XML:
>
> <a:l>20<a:l>
>
> this XML would be parsed as leaf "l" of type "string".
>
> Similar problem occurs also for boolean. So I am just wondering, is this a known bug/feature, is it intentional? It is true that applications usually choose one format and stick to it but it is not a requirement and I can see this having possibly quite nasty consequences.

This has already been discussed several times in the past, for example in this thread:

https://mailarchive.ietf.org/arch/browse/netmod/?gbt=1&index=dqNrvzOV2Ur6RoX6rTW-ZzsV65g

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

Lada

>
> Regards,
> Michal
>
> [1] https://tools.ietf.org/html/rfc7951#section-6.10
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka 
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67