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. 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 >> > > > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
