On Thu, Feb 21, 2019 at 10:33 AM Martin Bjorklund <[email protected]> wrote:
> Andy Bierman <[email protected]> wrote: > > On Thu, Feb 21, 2019 at 10:07 AM Peter Loborg <[email protected] > > > > wrote: > > > > > > > > > > > Your example is fine – but the gammar is ch14 specifies something > > > different: > > > > > > > > > > > > enum-stmt = enum-keyword sep string optsep > > > > > > (";" / > > > > > > "{" stmtsep > > > > > > ;; these stmts can appear in any order > > > > > > *if-feature-stmt > > > > > > [value-stmt] > > > > > > [status-stmt] > > > > > > [description-stmt] > > > > > > [reference-stmt] > > > > > > "}") stmtsep > > > > > > > > > > > > It clearly states string, not quoted-string. These two have the > following > > > rules: > > > > > > > > > > > > quoted-string = (DQUOTE string DQUOTE) / (SQUOTE string SQUOTE) > > > > > > > > > > > > string = < an unquoted string, as returned by > > > > > > > < the scanner, that matches the rule > > > > > > > < yang-string > > > > > > > > > > > > > > > > The text in 9.6.4 is correct. > > The ABNF is wrong. > > No, the ABNF is correct. The ABNF doens't handle concatenation etc. > The idea is that the scanner handles quotes and concatenation and > returns a "string". > > OK -- it is confusing that the rule quoted-string exists, but it is only for key and leaf-list predicates. > > /martin > > Andy > > > > > > > > > > > …and in 6.1.3 we can read that: > > > > > > An unquoted string is any sequence of characters that does not > > > > > > contain any space, tab, carriage return, or line feed characters, a > > > > > > single or double quote character, a semicolon (";"), braces ("{" or > > > > > > "}"), or comment sequences ("//", "/*", or "*/"). > > > > > > > > > > > > Note that any keyword can legally appear as an unquoted string. > > > > > > > > > > > > Since the section so clearly writes about single quoted strings and > double > > > quoted strings, there can unfortunately be no interpretation that would > > > allow “identifier” to be called an unquoted string – even though it > follows > > > the rules about limited character contents. > > > > > > > > > > > > Hence – this is not a matter of opinion – it’s a matter of reading > what’s > > > actually written in the RFC. > > > > > > > > > > > > But on the subject of opinion… > > > > > > > > > > > > enum "This is also legal"; // should definitely always be > illegal > > > > > > > > > > > > …as we cannot create a language binding to enum constructs in any major > > > programming languages. > > > > > > > > > > > > > There are many aspects of YANG that do not map directly to programming > > languages, > > such as allowing '.' in identifiers. > > > > > > > > > Br, > > > > > > Peter > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > *From:* Andy Bierman <[email protected]> > > > *Sent:* den 21 februari 2019 18:45 > > > *To:* Martin Bjorklund <[email protected]> > > > *Cc:* RFC Editor <[email protected]>; Ignas Bagdonas < > > > [email protected]>; NetMod WG <[email protected]>; Peter Loborg < > > > [email protected]>; Warren Kumari <[email protected]> > > > *Subject:* Re: [netmod] [Editorial Errata Reported] RFC7950 (5642) > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Feb 21, 2019 at 8:53 AM Martin Bjorklund <[email protected]> > wrote: > > > > > > RFC Errata System <[email protected]> wrote: > > > > The following errata report has been submitted for RFC7950, > > > > "The YANG 1.1 Data Modeling Language". > > > > > > > > -------------------------------------- > > > > You may review the report below and at: > > > > http://www.rfc-editor.org/errata/eid5642 > > > > > > > > -------------------------------------- > > > > Type: Editorial > > > > Reported by: Peter Loborg <[email protected]> > > > > > > > > Section: 9.6.4 > > > > > > > > Original Text > > > > ------------- > > > > It takes as an argument a string that is the assigned name. > > > > > > > > Corrected Text > > > > -------------- > > > > It takes as an argument an unquoted string that is the assigned name. > > > > > > This is not correct. The enum argument is not different from any > > > other keyword's arguments in YANG. See e.g. the example in 9.12.4: > > > > > > type enumeration { > > > enum "unbounded"; > > > } > > > > > > The following is also legal: > > > > > > enum "unb" + 'ounded'; > > > > > > > > > > > > > > > > > > enum "This is also legal"; > > > > > > > > > > > > 9.6.4. The "enum" Statement > > > > > > > > > > > > The "enum" statement, which is a substatement to the "type" > > > > > > statement, MUST be present if the type is "enumeration". It is > > > > > > repeatedly used to specify each assigned name of an enumeration > type. > > > > > > It takes as an argument a string that is the assigned name. *The* > > > > > > * string MUST NOT be zero-length and MUST NOT have any leading or* > > > > > > * trailing whitespace characters* (any Unicode character with the > > > > > > "White_Space" property). The use of Unicode control codes SHOULD be > > > > > > avoided. > > > > > > > > > > > > > > > > > > This errata should be rejected. > > > > > > > > > > > > /martin > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > Notes > > > > ----- > > > > Readers are not beeing made aware that careful reading of section > 6.1.3 > > > and the detailed definition of string in section 14 must be consulted.. > > > > For comming versions of this RFC it would be preferable to use a more > > > specialized grammar token for these cases (e.g. unquoted-string). > > > > > > > > Instructions: > > > > ------------- > > > > This erratum is currently posted as "Reported". If necessary, please > > > > use "Reply All" to discuss whether it should be verified or > > > > rejected. When a decision is reached, the verifying party > > > > can log in to change the status and edit the report, if necessary. > > > > > > > > -------------------------------------- > > > > RFC7950 (draft-ietf-netmod-rfc6020bis-14) > > > > -------------------------------------- > > > > Title : The YANG 1.1 Data Modeling Language > > > > Publication Date : August 2016 > > > > Author(s) : M. Bjorklund, Ed. > > > > Category : PROPOSED STANDARD > > > > Source : Network Modeling > > > > Area : Operations and Management > > > > Stream : IETF > > > > Verifying Party : IESG > > > > > > > > > > _______________________________________________ > > > netmod mailing list > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
