> On 29 Apr 2016, at 15:51, Per Hedeland <p...@tail-f.com> wrote: > > On 2016-04-29 15:28, Ladislav Lhotka wrote: >> >>> On 29 Apr 2016, at 15:07, Juergen Schoenwaelder >>> <j.schoenwael...@jacobs-university.de> 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 netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod