> On 02 Feb 2016, at 18:25, Andy Bierman <a...@yumaworks.com> wrote:
> 
> 
> 
> On Tue, Feb 2, 2016 at 4:04 AM, Jernej Tuljak <jernej.tul...@mg-soft.si> 
> wrote:
> Ladislav Lhotka je 2.2.2016 ob 12:25 napisal:
> On 02 Feb 2016, at 12:16, Martin Bjorklund <m...@tail-f.com> wrote:
> 
> Ladislav Lhotka <lho...@nic.cz> wrote:
> On 02 Feb 2016, at 09:51, Jernej Tuljak <jernej.tul...@mg-soft.si> wrote:
> 
> Martin Bjorklund je 1.2.2016 ob 20:48 napisal:
> Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de> wrote:
> If a specification is not explicit enough, then people often implement
> what they find implemented in other similar contexts. This means the
> code often ends up reflecting which tools an implementor was familiar
> with. In a shell, echo f\"oo gives you f"oo (and the same is true for
> Tcl, which has otherwise the behavior you implemented for pyang,
> treating " as a regular character in an unquoted string.)
> 
> It would help to know what implementations do with identifiers like
> f"o"o and f\"o\"o. If they do different things, then there is likely
> some evidence that implementors arrived at different conclusions.
> I don't mind a clarification.  How about:
> 
> OLD:
> 
>   If a string contains any space, tab, or newline characters, a
>   semicolon (";"), braces ("{" or "}"), or comment sequences ("//",
>   "/*", or "*/"), then it MUST be enclosed within double or single
>   quotes.
> 
> NEW:
> 
>   If a string contains any space, tab, or newline characters, a
>   semicolon (";"), braces ("{" or "}"), or comment sequences ("//",
>   "/*", or "*/"), then it MUST be enclosed within double or single
>   quotes.  If a string does not contain any of these characters, it
>   MAY be unquoted.
> 
>   Within an unquoted string, every character is preserved.  Note that
>   this means that the backslash, single quote, and double quote
>   characters can occur in an unquoted string.
> I don't think this can be implemented, like I did not in the linked archive. 
> It does not make clear whether these are two statements or a single one:
> 
>   default ";
>   units ";
> 
> 
> What about this:
> 
>   default ";//foo";
>   units \";
> 
> 
> This is not the C and C++ way of doing things (possibly not even SMIng way). 
> These are the only languages mentioned in the document (Section 6). It also 
> does not promote readability and makes lexers unnecessarily complex.
> +1
> 
> I think the safest solution would be to disallow in unquoted strings
> all characters that have a special meaning anywhere in YANG
> syntax. This can hardly cause any troubles to module authors.
> Fine with me.  Something like:
> 
> NEW:
> 
>   If a string contains any space, tab, or newline characters, a single
>   or double quote, semicolon (";"), braces ("{" or "}"), or comment
>   sequences ("//", "/*", or "*/"), then it MUST be enclosed within
>   double or single quotes.  If a string does not contain any of these
>   characters, it MAY be unquoted.
> 
>   Within an unquoted string, every character is preserved.  Note that
>   this means that the backslash character does not have any special
>   meaning in an unquoted string.
> I like this.
> 
> +1
> 
> 
> 
> I don't understand this text.
> The parser looks for certain tokens in specific contexts. 
> 
> 
>   container A;container B;container C;
> 
>   container foo{container bar{container baz;}}
> 
>   augment /foo/bar/baz{container Z;}
> 
> pyang and yangdump-pro handle these unquoted strings correctly.
> 
> I think your text is supposed to mean that chars with special meanings
> in specific contexts need to be quoted to use them as plain chars without
> any special meaning.
> 
> I strongly object to this new text since it tells the YANG author they
> cannot use unquoted strings like the examples above.

Why do you think there is anything in the new text to this effect? All of your 
examples remain perfectly OK. The only change compared to 6020bis-09 is that 
the newline, single- and double-quote characters cannot appear in unquoted 
argument strings.

Lada 

> 
> 
> Andy
> 
> 
> It should be noted that this may be viewed as a backwards incompatible
> change, but I think it is similar to the change for escaped characters
> in double quoted string ("backwards incompatible bugfix").
> Yes, I think so.
> 
> This is nothing compared to the change of the accessible tree for output.
> 
> Jernej
> 
> 
> Thanks, Lada
> 
> 
> 
> /martin
> 
> 
> 
> BTW, if we wanted to be extremely liberal, I don't understand why the 
> end-comment sequence "*/" is not allowed.
> 
> Lada
> 
> Jernej
> 
> /martin
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
> 
> 
> 
> 
> 
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to