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