> On 29 Apr 2016, at 16:32, Per Hedeland <[email protected]> wrote: > > On 2016-04-29 16:15, Ladislav Lhotka wrote: >> >>> 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. > > Yes, fixed in 1.1 - but 6020 (which I "happened" to look at as I was > flipping between the two) has: > > type-stmt = type-keyword sep identifier-ref-arg-str optsep > (";" / > "{" stmtsep > type-body-stmts > "}") > >>>> 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. > > I think some text would be appreciated if you think it is needed.
OLD When an existing enumeration type is restricted, the set of assigned names in the new type MUST be a subset of the base type's set of assigned names. The value of such an assigned name MUST NOT be changed. NEW When an existing enumeration type is restricted by means of one or more "enum" statements (even if any or all of them are disabled through an "if-feature" statement), the set of assigned names in the new type MUST be a subset of the base type's set of assigned names. The value of such an assigned name MUST NOT be changed. If a new type is derived from an existing enumeration type and no "enum" restrictions are specified, then the sets of permitted values are the same for both types. And the same for bits type, mutatis mutandis. Lada > >> In a way, solution Y10-02 would have been more straightforward. > > Please don't do that. > > --Per > >> 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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
