> On 21 Oct 2015, at 10:13, Martin Bjorklund <[email protected]> wrote:
>
> Ladislav Lhotka <[email protected]> wrote:
>>
>>> On 21 Oct 2015, at 09:50, Martin Bjorklund <[email protected]> wrote:
>>>
>>> Ladislav Lhotka <[email protected]> wrote:
>>>>
>>>>> On 21 Oct 2015, at 09:17, Martin Bjorklund <[email protected]> wrote:
>>>>>
>>>>> Ladislav Lhotka <[email protected]> wrote:
>>>>>> Martin Bjorklund <[email protected]> writes:
>>>>>>
>>>>>>> Andy Bierman <[email protected]> wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I updated the YANG guidelines draft.
>>>>>>>
>>>>>>> I have a couple of comments.
>>>>>>>
>>>>>>> --------------------------
>>>>>>>
>>>>>>> Section 5.14 says:
>>>>>>>
>>>>>>> The "choice" statement is allowed to be directly present within a
>>>>>>> "case" statement in YANG 1.1.
>>>>>>>
>>>>>>> It is allowed in YANG 1 as well.
>>>>>>>
>>>>>>> This needs to be considered
>>>>>>> carefully. Consider simply including the nested "choice" as
>>>>>>> additional "case" statements within the parent "choice" statement.
>>>>>>>
>>>>>>> Ok, but I don't think people use nested choice by accident. I have
>>>>>>> seen it used a handful of times, and there was always a good reason
>>>>>>> for doing it. If you think some warning text like this is needed, I
>>>>>>
>>>>>> But isn't it that in these legitimate cases the inner choice is always
>>>>>> accompanied by other nodes within the same case? The solution to Y29
>>>>>> enables choice as a short-hand case, and this can always be
>>>>>> flattened. Do I miss something?
>>>>>
>>>>> No you're right. It should also be noted that an implementation can
>>>>> choose to flatten such nested choices.
>>>>
>>>> So maybe this was the reason for not allowing choice as a short-hand
>>>> case. I wonder, is Y29-01 a good idea after all? We are encouraging
>>>> people to do convoluted things that have a simpler alternative.
>>>
>>> IMO Y29 is about having consistent rules in the language. Allowing
>>> short hand cases for just a subset of the nodes seems like a CLR.
>>
>> It would be practically useful in cases like this:
>>
>> grouping foo {
>> choice foo {
>> ...
>> }
>> }
>>
>> choice foobar {
>> uses foo;
>> leaf bar;
>> }
>>
>> However, this is not possible because of another CLR that doesn't
>> allow "uses" as a substatment of "choice". So if we want consistency,
>> we should simply remove short-case-stmt from the ABNF and use
>> data-def-stmt instead.
>
> The problem with allowing uses as a shorthand is that it is not
> directly obvious what it means. For example:
>
> grouping foo {
> leaf a { ... }
> leaf b { ... }
> }
>
> choice x {
> uses foo;
> }
>
>
> could be equivalent to:
>
> A:
>
> choice x {
> leaf a { ... }
> leaf b { ... }
> }
>
> or
>
> B:
>
> choice x {
> case foo {
> leaf a { ... }
> leaf b { ... }
> }
> }
>
The text in sec. 7.13 makes it quite clear that it would be A (The effect of a
"uses" reference to a grouping is that the nodes defined by the grouping are
copied into the current schema tree, … ).
Moreover, you have a similar dilemma if you augment a choice:
augment x {
leaf a { ... }
leaf b { ... }
}
But my point is different: choice as a short-hand case is only possible
directly, not via "uses":
choice foo {
choice bar { ... }
...
}
However, this really begs the question "Why don't you simply make the cases of
'bar' into cases of 'foo'?" I can't see any reasonable answer.
Balazs wanted to add CLRs to ban "complex" choices. I don't know how to do it
in general but here we are removing one obstacle for defining choices that are
*needlessly* complex.
Lada
>
>
> /martin
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
