Re: [netmod] Potential additions to rfc6087bis: RegEx guidelines

[Robert Wilton <[e-mail]>]

Hi Andy,

What I am suggesting makes it easier for readers, because I am a 
proponent of simpler regular expressions that are easy to read and 
understand.

For example, I wonder how many YANG model readers would immediately 
comprehend what this pattern statement means:

pattern "\p{Sc}\p{Zs}?\p{Nd}+\.\p{Nd}{2}"?

Does allowing such patterns really make it easier for model readers?

The proposes guidelines obviously make it easier (or at least no harder) 
for tool makers.

I agree that there is an minor impact to model writers, but really only 
in the sense that the guidelines would be telling them not to use the 
esoteric options of the XML regex syntax that they probably don't know 
about anyway.

If explicitly putting this in the YANG author guidelines is not liked, 
then another possible option could be a softer recommendation in the 
guidelines RFC, with some more explicit examples of stuff to avoid on an 
YANG FAQ Wiki page.

Thanks,
Rob


On 29/08/2017 17:15, Andy Bierman wrote:
> Hi,
>
> I agree with Juergen that these proposed guidelines are not a good idea.
> The priority order for YANG is (1) readers (2) writers and (3) toolmakers.
> It seems trivial for group (3) to convert the XSD pattern to some 
> other format.
> It seems difficult to train all the people in groups (1) and (2) that 
> there are lots of
> special new rules to learn.
>
>
> Andy
>
>
> On Tue, Aug 29, 2017 at 7:27 AM, Robert Wilton <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>
>     On 28/08/2017 16:46, Juergen Schoenwaelder wrote:
>>     On Mon, Aug 28, 2017 at 12:58:59PM +0000, Xufeng Liu wrote:
>>>     [Xufeng] [0..9] is still compliant with the XSD pattern specified by
>>>     YANG 1.0 and 1.1. Using [0..9] instead of [\d] will make the
>>>     implementations with native POSIX RegEx easier without the need for
>>>     a tool to inspect every element of the RegEx pattern.
>>     Yes, but then \d is legal in YANG (and it is used in a couple of
>>     published RFCs).
>     I entirely agree that YANG regular expressions must be legal XML
>     Schema regular expressions.
>
>     However, I don't think that the majority of YANG implementations
>     are going to want to either use libxml or write their own
>     implementation of the XML RE language.  Instead it is desirable
>     that they can use whatever standard regex implementation comes
>     with their language, or is readily available in a library.
>
>     Most of the pattern statements I see in YANG modules use a basic
>     subset of regular expressions, and hence it looks like they can
>     often be used by most RE engines, perhaps with some trivial tweaks
>     or conversions.  However, there is no formal guidance recommending
>     that pattern statements in standard modules are restricted to a
>     subset of XML RE.
>
>     Hence, ideally I would like 6087bis to state that pattern
>     statements SHOULD also conform to the following additional RE
>     syntax restrictions, which I think should make them easy to
>     convert to most other standard regex implementations (subject to
>     unicode support limitations):
>
>     (1) Allow \d, \D, \s, \S, \w and \W; but not inside character classes.
>     (2) Disallow \i, \c; and their negative equivalents.
>     (3) Disallow character class subtraction (e.g. "[A-Z-[RW]]").
>     (4) Limit the supported unicode categories to only the following
>     8.  Both \p and \P syntax is supported, but not inside character
>     classes:
>       \p{L} or any kind of letter from any language.
>       \p{Ll} a lowercase letter that has an uppercase variant.
>       \p{Lu} an uppercase letter that has a lowercase variant.
>       \p{Z} any kind of whitespace or invisible separator.
>       \p{Zs} a whitespace character that is invisible, but does take
>     up space.
>       \p{Zl} a line separator character U+2028.
>       \p{N} any kind of numeric character in any script.
>       \p{Nd}: a digit zero through nine in any script except ideographic
>     (5) Disallow matching of unicode blocks.
>
>     Thanks,
>     Rob
>
>
>>     Educating _all_ module authors to write [0..9] instead of \d will
>>     likely be more expensive than improving the code of implementations
>>     that did not implement YANG entirely to accept \d.
>>
>>     /js
>>
>
>
>     _______________________________________________
>     netmod mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/netmod
>     <https://www.ietf.org/mailman/listinfo/netmod>
>
>