Re: [netmod] Pattern statements [was Re: Query about augmenting module from submodule in YANG 1.0]

[Robert Wilton <[e-mail]>]

On 23/08/2017 14:36, Juergen Schoenwaelder wrote:
> On Wed, Aug 23, 2017 at 02:23:12PM +0100, Robert Wilton wrote:
>> 1) Email address.  I understand that the full regex to validate all email
>> addresses is very complex, but checking that it at least contains an @
>> symbol still has benefit.  It would seem that a short imperfect regex is
>> better than a complete perfect regex.
> What is your definition of 'better'? A stricter pattern catches more
> errors. An imperfect pattern is better than none.
My definition of 'better' is:
- is relatively easy for a human to read/review.
- doesn't exclude any valid values.
- doesn't check numerical ranges, only the number of digits.
- is simple enough to trivially work with most normal regex engines.
- otherwise the pattern is as strict as possible given the constraints 
above.

>
>> 2) A list of VLAN ranges, e.g. want to allow strings that look like this:
>> "1-10,20-400,600,2000-3000", but only with non overlapping values in
>> ascending order.  It is easy to write a regex to check that the structure is
>> right, but AFAIK it is hard (impossible?) to write a regex that ensures that
>> the ranges don't overlap and are specified in ascending order.
> So what. Does this provide a helpful argument whether patterns should
> be strict or imperfect?
My point is only that it is very easy to produce invalid config that 
passes whatever regex is used so it is better to produce a simpler and 
more human readable regex rather than expand it to perform range 
checking of numerical values as well.

>
>> So, I propose that we use regexes for checking that the string is
>> structurally correct, but don't use regexes to perform numerical range
>> checks of string encoded numbers, since it makes the regexes hard to
>> read/verify, and doesn't improve the readability of the YANG file either.
> So here is the point I think:
>
>     It is desirable that regexes are as strict as they can be.
>     However, if regexes become so complicated that they become a
>     verification and maintenance problem by themself, then less strict
>     regexes may be a better choice.
I partly agree, but the line of where I would define a regex as being 
too complicated may be different from you ;-).

Thanks,
Rob

>
> /js
>