On 17. 07. 20 12:03, Vladimir Vassilev wrote: > 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).
Why not? In XML, everything is encoded as text, and the annotation tells how to parse it and interpret. So either the text representation conforms to that precise type or otherwise it is an error. There is no ambiguity. Lada > > 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 >>>> >>> -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
