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
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
