> 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 [email protected] https://www.ietf.org/mailman/listinfo/netmod
