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

[Ladislav Lhotka <[e-mail]>]

Juergen Schoenwaelder píše v St 23. 08. 2017 v 15:36 +0200:
> 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.
> 
> > 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?
> 
> > 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.

Either way, the regex must not produce false negatives, i.e. reject valid
values. For some regexes this is what makes them complicated.

Also, I don't see any need for replacing existing patterns unless they are
wrong. We have descriptions to tell human readers about the permitted value set.

Lada

> 
> /js
> 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67