Re: [netmod] The when-choice loop

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 <balazs.lengyel@ericsson.com> 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: Balazs.Lengyel@ericsson.com
> 
> <choice-when-interaction.yang>_______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C