> On 15 Oct 2015, at 15:17, Balazs Lengyel <[email protected]> wrote: > > Hello Lada, > So can we start gathering support for limiting when/choice to the simple > cases by one of the 3 methods: > 1) prohibit them (backward incompatible)
I would personally restrict the use of "when" only as a substatement of "augment". This would solve most issues, including Y18 (missing context node). I other cases, "must" can be often used instead of "when" with the same effect - at least for validation purposes. I am not sure that benefits of "when" outweigh the complexity - both in YANG spec and server implementation. I also think servers should not automatically delete nodes whose "when" expression becomes false. Lada > 2) create a guideline not to use them in 6087, (easy to do, better then > nothing, but does not protect the application) > 3) declaring them as implementation dependent, thus making them backward > compatible, but unusable > > Complicated: In my view anytime a when or choice depends on another when or > choice it is complicated. So use the simple cases only. > regards Balazs > > On 2015-10-15 14:53, Ladislav Lhotka wrote: >> Hi Balazs, >> >> one lesson taken from early XML schema languages (DTD) was that modifying >> the validated document during validation easily leads to nasty race >> conditions. That's why RELAX NG avoids changing the XML infoset like plague. >> >> I've already got tired reiterating (and providing examples) that "when" >> statement is inherently broken - the schema should not depend on evaluating >> arbitrary expressions in the context of an instance document that is >> supposed to be validated with the schema. The standard disclaimer is that it >> works for simple cases, and more complicated corner cases are "garbage in - >> garbage out". >> >> Lada >> >> P.S. Note that XPath expressions like "not(../a2)" evaluate to false if >> ../a2 exists, even if its content is "false". So you'd need expressions like >> "not(../a2 = 'true')". >> >>> On 15 Oct 2015, at 13:59, Balazs Lengyel <[email protected]> >>> wrote: >>> >>> Hello, >>> In RFC6020bis we write: >>> "There MUST NOT be any circular dependencies in these "when" expressions." >>> How about a circular when-choice loop? >>> >>> leaf a1 { >>> type boolean; >>> when not(../a2); >>> } >>> choice c2 { >>> default case2; >>> case case1 { >>> when not(a1); >>> leaf b1 {type int8;} >>> } >>> case case2 { >>> leaf a2 { >>> type boolean; >>> default true; >>> } >>> } >>> } >>> >>> Initial state: a1=false, b1=5; >>> - Set a1=true >>> - case1 and b1 disapears >>> - case2 and a2=false are set as default >>> - a1 disappears >>> - if there is no a1 why did we delete case1/b1? >>> Did I miss something, is this really what happens? >>> >>> Even if someone can come up with the correct solution, operators will be >>> 100% sure to mess this up. Usability=0 !!! >>> >>> I want some of this multistep when/when, choice/choice, when/choice >>> scenarios prohibited in RFC 6020 or 6087. Or state in 6020 that the order >>> of evaluation is implementation dependent: that would make it unusable, so >>> practically prohibiting then while maintaining backward compatibility :-) >>> >>> I attached an even more complicated example, so go ahead have fun >>> understand it! >>> regards Balazs >>> >>> PS: Why did we make YANG so complicated? >>> >>> -- >>> Balazs Lengyel Ericsson Hungary Ltd. >>> Senior Specialist >>> ECN: 831 7320 >>> Mobile: +36-70-330-7909 email: [email protected] >>> >>> <choice-when-interaction.yang>_______________________________________________ >>> netmod mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/netmod >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >> >> >> >> >> > > -- > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > ECN: 831 7320 > Mobile: +36-70-330-7909 email: [email protected] -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
