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

[Robert Wilton <[e-mail]>]

On 23/08/2017 15:22, Ladislav Lhotka wrote:
> 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.
I agree.

>
> Also, I don't see any need for replacing existing patterns unless they are
> wrong.
I also agree.  I'm not trying to retroactively change existing regexes, 
just tweak the guidance when new regexes are being constructed so that 
they end up being a bit simpler.

Thanks,
Rob


>   We have descriptions to tell human readers about the permitted value set.
>
> Lada
>
>> /js
>>