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 > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
