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

[Lou Berger <[e-mail]>]

Kent and I discussed this.  We (as chairs) don't think there is
currently WG consensus on RegEx guidelines.  We do think there is
sufficient interest to continue the discussion, and would like to do so
both on list and in our next meeting in Singapore.

Thank you,

Lou and Kent

On 9/6/2017 1:01 PM, Lou Berger wrote:
> Thanks Rob.  I'll get with Kent and  then one of us will get back to the wg 
> on next steps.
>
> Lou
>
>
> On September 6, 2017 3:53:33 AM Robert Wilton <[e-mail]> wrote:
>
>> Hi Lou,
>>
>> This is the addition to 6087bis that I propose.   Note, this is the same
>> text in my email on the 31st of August.
>>
>> I propose adding the following 2 paragraphs to 6087bis section on
>> pattern and ranges:
>>
>> NEW:
>> To ensure patterns are easy to read and implement, authors SHOULD
>> restrict themselves to the parts of the XML schema regular expression
>> language that are common across most regular expression languages.  In
>> particular, pattern statements SHOULD avoid using 'character class
>> subtraction' (e.g. '[a-z-[aeiou]]').  They SHOULD avoid matching
>> unicode properties and blocks (e.g. '\p{L} or \p{IsBasic_Latin}').
>> They MAY use the '\d', '\w', '\s' character class shorthands and their
>> negated versions, where appropriate, but SHOULD avoid other character
>> class shorthands.  To match ASCII digits 0-9 the character class
>> '[0-9]' MUST be used instead of the '\d' character class shorthand
>> that matches Unicode digits in all scripts.
>>
>> Pattern statements do not have to strictly restrict numerical values,
>> and a simple less specific pattern may be preferable over a more
>> complex and precise pattern, e.g. as illustrated in the
>> 'ipv4-address-no-zone' example pattern below.
>>
>>
>> Or, put in context of the existing text 6087bis text:
>>
>> *** Patterns and Ranges
>>
>> For string data types, if a machine-readable pattern
>> can be defined for the desired semantics, then
>> one or more pattern statements SHOULD be present.
>> A single quoted string SHOULD be used to specify the pattern,
>> since a double-quoted string can modify the content.
>>
>> To ensure patterns are easy to read and implement, authors SHOULD
>> restrict themselves to the parts of the XML schema regular expression
>> language that are common across most regular expression languages.  In
>> particular, pattern statements SHOULD avoid using 'character class
>> subtraction' (e.g. '[a-z-[aeiou]]').  They SHOULD avoid matching
>> unicode properties and blocks (e.g. '\p{L} or \p{IsBasic_Latin}').
>> They MAY use the '\d', '\w', '\s' character class shorthands and their
>> negated versions, where appropriate, but SHOULD avoid other character
>> class shorthands.  To match ASCII digits 0-9 the character class
>> '[0-9]' MUST be used instead of the '\d' character class shorthand
>> that also matches Unicode digits in all scripts.
>>
>> Pattern statements do not have to strictly restrict numerical values,
>> and a simple less specific pattern may be preferable over a more
>> complex and precise pattern, e.g. as illustrated in the
>> 'ipv4-address-no-zone' example pattern below.
>>
>> The following typedef from ^RFC6991^ demonstrates the proper
>> use of the "pattern" statement:
>>
>>      typedef ipv4-address-no-zone {
>>        type inet:ipv4-address {
>>          pattern '[0-9\.]*';
>>        }
>>        ...
>>      }
>>
>> For string data types, if the length of the string
>> is required to be bounded in all implementations,
>> then a length statement MUST be present.
>>
>> The following typedef from ^RFC6991^ demonstrates the proper
>> use of the "length" statement:
>>
>>      typedef yang-identifier {
>>        type string {
>>          length "1..max";
>>          pattern '[a-zA-Z_][a-zA-Z0-9\-_.]*';
>>          pattern '.|..|[^xX].*|.[^mM].*|..[^lL].*';
>>        }
>>        ...
>>      }
>>
>> For numeric data types, if the values allowed
>> by the intended semantics are different than
>> those allowed by the unbounded intrinsic data
>> type (e.g., 'int32'), then a range statement SHOULD be present.
>>
>> The following typedef from ^RFC6991^ demonstrates the proper
>> use of the "range" statement:
>>
>>      typedef dscp {
>>        type uint8 {
>>           range "0..63";
>>        }
>>        ...
>>      }
>>
>> Thanks,
>> Rob
>>
>>
>> On 05/09/2017 22:37, Lou Berger wrote:
>>> Rob,
>>>
>>> (as chair)
>>> On 9/5/2017 1:17 PM, Robert Wilton wrote:
>>>> However, I have thrown in the towel on my regex crusade.
>>> I'm sorry, I've lost the thread here a bit. in order to guage consensus
>>> on this topic, it would be helpful to send the latest text that you are
>>> proposing for inclusion in the the bis.  If you are willing to do these,
>>> we can poll to see if there is/is not support for inclusion of this
>>> text.  Are you willing, i.e., can you send the current proposed text change?
>>>
>>> Thank you,
>>> Lou
>>>
>>> .
>>>
>>