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

[Andy Bierman <[e-mail]>]

On Wed, Aug 30, 2017 at 5:31 AM, Juergen Schoenwaelder <
[e-mail]> wrote:

> On Wed, Aug 30, 2017 at 12:48:19PM +0100, Robert Wilton wrote:
> >
> >
> > On 30/08/2017 11:29, Juergen Schoenwaelder wrote:
> > > On Wed, Aug 30, 2017 at 10:16:30AM +0100, Robert Wilton wrote:
> > > > 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?
> > > This is always difficult to judge but to be fair you have to show how
> > > you express _the same_ (and not a subset) with some other kind of
> > > regular expressions. (My understanding is that \p{Sc} is a currency
> > > symbol.)
> > Yes, the expression would cover a currency amount, along with associated
> > symbol (e.g. "$200.00").
> >
> > If I was writing a module, I would probably use the following pattern
> > statement instead, which I think a lot more people would likely be able
> to
> > comprehend:
> >
> > pattern "[A-Z]{3}\s?\d+\.\d{2}", using the 3 letter, ISO 4217, currency
> codes.  e.g. ("USD 200.00")
>
> But that is not the same. Apples versus oranges. (I expect people to
> tell me that (i) currency is irrelevant and (ii) that three ASCII
> letter currency acronyms are better than currency symbols anyway but
> this is a separate discussion I am not interested in.)
>
> > >
> > > > 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.
> > > What is 'esoteric' largely depends on your language environment. What
> > > you are saying by 'do not use \p{}' is essentially 'do not use any
> > > unicode long live ASCII'.
> > No, that is not my intention, i.e. I'm not suggesting banning all use of
> > \p{}, but instead limiting it to the character classes that seem like
> they
> > may plausibly be used in standardized YANG modules.
>
> This is entirely subjective. And if you still allow some \p{}, what is
> the point of the exercise?
>
> > I'm not trying to change what 6020/7950 defines the pattern statement as,
> > just give what I perceive as some pragmatic guidance as to what parts of
> XML
> > RE it makes sense to use in standardized YANG modules, making it easier
> for
> > readers and implementations.
> >
> > I think that it is fine for companies, vendors, etc to use the full
> breadth
> > of XML RE if they wish.
>
> Implementations have to be prepared to handle XSD pattern if they
> claim compliance to YANG 1.0 and 1.1. So all this only helps
> non-compliant implementations. This may indeed be a goal - but then we
> should spell this out as such - this helps non-compliant
> implementations (and they may still fail on the first \p{} that
> you still allow).
>
> If implementations do not implement the YANG pattern statement but
> something else, then then they should ignore patterns they can't
> understand and treat the pattern as if it would have been in a
> description clause - i.e., leave it to humans to write the code that
> implements the pattern correctly. Note that YANG does not say anything
> how stuff is implemented.
>


This does not work.
There are 3 outcomes from the regex compiler

1) proper syntax was used and accepted; pattern matches correctly
2) improper syntax was used and accepted; pattern matches incorrectly
3) improper syntax was used and rejected; compiler error generated

Case (2) is the really bad one and we have seen in in bug reports.

This issue was discussed in detail for almost 2 years and the conclusion was
that a YANG extension would be used to specify other pattern types than
the XSD pattern mandated by the standard.


> /js
>
>
Andy


> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <http://www.jacobs-university.de/>
>