> On 29 Apr 2016, at 17:46, Per Hedeland <[email protected]> wrote: > > On 2016-04-29 17:07, Ladislav Lhotka wrote: >> >>> 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. > > Agree with the first paragraph, but I do think the second is superfluous > - it just says "if there is no restriction statement, the type isn't > restricted". This is true for all types.
OK, Lada > > --Per > >> 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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
