I think we should consider this for a future version of YANG but not
now. I am not aware what implementors had problems to implement YANG
strings in YANG 1 or YANG 1.1 and we are at a point in the process
where I like to not run the risk to make bigger changes to the
specification that may turn out to introduce incompabilities.

/js

On Thu, Jun 09, 2016 at 06:03:50PM -0400, Dale R. Worley wrote:
> At this point, I think there are some aspects of the use of strings and
> identifiers that aren't completely specified, but I'd have to check the
> current text to know for certain.  However, that's a minor matter.
> 
> The issue that concerns me is that the ABNF doesn't specify what is
> allowed as a string.  I'm used to programming language definitions,
> where the grammar is specified quite rigidly, to the point that the ABNF
> can be input to a parser generator.  In this document, the ABNF is quite
> complete except for a specification of strings.  On the other hand, the
> text description of strings seems to be sufficient for an implementer,
> so we don't actually need to provide ABNF.  My strong preference is to
> provide a complete ABNF, as is the norm for programming languages.
> 
> The following is a complete ABNF for Yang strings.  Of course, it's a
> bit complicated, because the definition of strings in Yang actually is a
> bit complicated.
> 
>    string              = unquoted-string / quoted-string
> 
>    unquoted-string     = *unquoted-item ( unquoted-item /
>                                           "/" /
>                                           "*" *"*" )
>                          ;; a sequence of one or more characters from
>                          ;; ordinary-char / "/" / "*", not containing
>                          ;; "//", "/*", or "*/"
> 
>    unquoted-item       = ordinary-char /
>                          "/" ordinary-char /
>                          "*" *"*" ordinary-char
> 
>    ordinary-char       = < any character matching yang-char, except >
>                          < space, tab, newline, carriage return,    >
>                          < semicolon, left brace, right brace,      >
>                          < slash, and asterisk                      >
> 
> *** Hmmm, is an unaccompanied CR allowed in an unquoted string?  If
> so, "ordinary-char" and my previous text regarding line breaks need
> to be amended.
> 
>    quoted-string      = ( single-quoted-string / double-quoted-string )
>                         *( optsep "+" optsep
>                            ( single-quoted-string / double-quoted-string ) )
> 
> (I think you said that there can be whitespace around + but not comments.)
> 
>    single-quoted-string = SQUOTE *sq-char SQUOTE
> 
>    sq-char            = < any character matching yang-char, except >
>                       < SQUOTE                                   >
> 
>    double-quoted-string = DQUOTE *dq-item DQUOTE
> 
>    dq-item            = dq-char /
>                       "\n" /
>                       "\t" /
>                       "\" DQUOTE /
>                       "\\"
> 
>    dq-char            = < any character matching yang-char, except >
>                       < DQUOTE and backslash                     >
> 
> (The existing production for yang-string is removed.)
> 
>    ;; any Unicode or ISO/IEC 10646 character including tab, carriage
>    ;; return, and line feed, but excluding the other C0 control
>    ;; characters, the surrogate blocks, and the noncharacters.
>    yang-char = %x09 / %x0A / %x0D / %x20-D7FF /
>    [continuing as before]
> 
> Dale
> 
> _______________________________________________
> netmod mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to