The embedded choice is clearly a case of over-complicating YANG. It was
a poor choice to allow such cases.
Sorry :-) couldn't resist.
But seriously, one reason we wanted to design a new modeling language
instead of reusing e.g. XSD was because XSD is too complicated, and then
we get embedded choice ?
Balazs
On 2015-10-06 09:56, Ladislav Lhotka wrote:
On 06 Oct 2015, at 09:38, Balazs Lengyel <balazs.leng...@ericsson.com> wrote:
Hello,
Thanks for the comments.
I WANT some clarification of this issue in te RFC. Preferably prohibiting
scenarios instead of explaining all the complexities :-(
Interestingly, choice was not allowed as a short-hand case statement in YANG
1.0 but it has been added in YANG 1.1 - see issue Y29:
https://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-30
Lada
The very least we should say in 6087: avoid embedded choices.
regards Balazs
On 2015-10-05 19:13, Ladislav Lhotka wrote:
On 05 Oct 2015, at 17:35, Balazs Lengyel <balazs.leng...@ericsson.com> wrote:
Hello,
What do the mandatory statements mean in the following model ?
choice scen8 { // Embedded choices with multiple mandatory cases;
invalid scenario
case A {
choice subChoiceA {
mandatory true;
case A {
leaf scen8-num1 { type uint8; }
}
case B {
leaf scen8-num2 { type uint8; }
}
}
}
case B {
choice subChoiceB {
mandatory true;
case A {
leaf scen8-num1 { type uint8; }
}
case B {
leaf scen8-num2 { type uint8; }
}
}
}
}
Answers:
A1) They mean nothing because the case around subChoiceA/B might not exist, in
which case its underlying statements are not valid.
A2) They mean that one case from both subChoiceA AND subchoiceB must exist
leading to two cases in choice scen8 which is not allowed, hence this is an
invalid model?
In the first place, it should be an error because of colliding names - all the
leaves defined in sub-cases have the same parent. However, pyang doesn't flag
it as an error.
Generally I find choices embedded in choices to be so complicated that IMHO
they SHOULD be immediately prohibited. If you think about all the variants of
embedded choices with mandatory and default placed on some or a bunch of them,
even understanding what they mean becomes a headache. BAD !!!! In the beginning
YANG was about easy-understanding. However these combinations are unclear even
after repeatedly reading the RFC :-(
Yes, it is quite complicated. Normally, such embedded choices shouldn't be
needed but they can happen if, e.g. the internal choices are defined in
groupings.
As the very least we SHOULD prohibit mandatory/default on the inside choice.
I think it would be better to ignore them (and tools may issue a warning).
Lada
regards Balazs
--
Balazs Lengyel Ericsson Hungary Ltd.
Senior Specialist
ECN: 831 7320
Mobile: +36-70-330-7909 email: balazs.leng...@ericsson.com
_______________________________________________
netmod mailing list
netmod@ietf.org
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: balazs.leng...@ericsson.com
--
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: balazs.leng...@ericsson.com
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
