> On 29 Apr 2016, at 15:51, Per Hedeland <[email protected]> wrote:
>
> On 2016-04-29 15:28, Ladislav Lhotka wrote:
>>
>>> On 29 Apr 2016, at 15:07, Juergen Schoenwaelder
>>> <[email protected]> wrote:
>>>
>>> On Fri, Apr 29, 2016 at 02:57:36PM +0200, Ladislav Lhotka wrote:
>>>>
>>>> Or are you saying that "type foo {}" is not the same as "type foo;"?
>>>>
>>>
>>> Yes, "type foo {}" has a restriction while "type foo;" does not have a
>>> restriction. OK, I think I see your point now that we have a case
>>> where there is a subtle difference between "{}" and ";" and so you
>>> suggest to interpret "type foo {}" as all values of foo?
>>
>> Now it becomes really interesting! :-) I wonder if there is any YANG parser
>> out there that is able to distinguish those two syntactic forms. I think
>> they must be considered identical by all means.
>
> +1. Though if I read the ABNF right, "type foo {}" is actually illegal
> if foo is an enum type.:-)
I don't think so:
type-stmt = type-keyword sep identifier-ref-arg-str optsep
(";" /
"{" stmtsep
[type-body-stmts]
"}") stmtsep
Everything inside the braces is optional.
>
>> My point was that the text about restrictions of the "enumeration" type is
>> unclear, and IMO the more logical answer to my original question is that the
>> "bar" set is empty. This is most likely not the 1.0 semantics though.
>
> No, it isn't - and I think the answer to your *original* question is
> quite clearly "bar is the same set as foo" in both 1 and 1.1, since 1.1
> says:
>
> An enumeration can be restricted with the "enum" (Section 9.6.4)
> statement.
>
> If there is no "enum" statement, there is no restriction, and thus foo
> and bar are identical. The "if-feature removes all the enum
> restrictions" case is perhaps ambiguous with an "extremely literal"
> interpretation of "if-feature", but to me (just having implemented
> if-feature for enums/bits in our compiler) it is obvious that this case
> too is a restriction and not an identity - the if-feature only modifies
> the specifics of the restriction.
Yes, this makes sense, too, but needs to be explained. In a way, solution
Y10-02 would have been more straightforward.
Lada
>
> But adding some text that clarifies this can't hurt I guess (just like
> the text that points out that the outcome of if-feature evaluation does
> not affect the value assignment).
>
> --Per
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
