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?
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.
If explicitly putting this in the YANG author guidelines is not liked,
then another possible option could be a softer recommendation in the
guidelines RFC, with some more explicit examples of stuff to avoid on an
YANG FAQ Wiki page.
Thanks,
Rob
On 29/08/2017 17:15, Andy Bierman wrote:
Hi,
I agree with Juergen that these proposed guidelines are not a good idea.
The priority order for YANG is (1) readers (2) writers and (3) toolmakers.
It seems trivial for group (3) to convert the XSD pattern to some
other format.
It seems difficult to train all the people in groups (1) and (2) that
there are lots of
special new rules to learn.
Andy
On Tue, Aug 29, 2017 at 7:27 AM, Robert Wilton <[email protected]
<mailto:[email protected]>> wrote:
On 28/08/2017 16:46, Juergen Schoenwaelder wrote:
On Mon, Aug 28, 2017 at 12:58:59PM +0000, Xufeng Liu wrote:
[Xufeng] [0..9] is still compliant with the XSD pattern specified by
YANG 1.0 and 1.1. Using [0..9] instead of [\d] will make the
implementations with native POSIX RegEx easier without the need for
a tool to inspect every element of the RegEx pattern.
Yes, but then \d is legal in YANG (and it is used in a couple of
published RFCs).
I entirely agree that YANG regular expressions must be legal XML
Schema regular expressions.
However, I don't think that the majority of YANG implementations
are going to want to either use libxml or write their own
implementation of the XML RE language. Instead it is desirable
that they can use whatever standard regex implementation comes
with their language, or is readily available in a library.
Most of the pattern statements I see in YANG modules use a basic
subset of regular expressions, and hence it looks like they can
often be used by most RE engines, perhaps with some trivial tweaks
or conversions. However, there is no formal guidance recommending
that pattern statements in standard modules are restricted to a
subset of XML RE.
Hence, ideally I would like 6087bis to state that pattern
statements SHOULD also conform to the following additional RE
syntax restrictions, which I think should make them easy to
convert to most other standard regex implementations (subject to
unicode support limitations):
(1) Allow \d, \D, \s, \S, \w and \W; but not inside character classes.
(2) Disallow \i, \c; and their negative equivalents.
(3) Disallow character class subtraction (e.g. "[A-Z-[RW]]").
(4) Limit the supported unicode categories to only the following
8. Both \p and \P syntax is supported, but not inside character
classes:
\p{L} or any kind of letter from any language.
\p{Ll} a lowercase letter that has an uppercase variant.
\p{Lu} an uppercase letter that has a lowercase variant.
\p{Z} any kind of whitespace or invisible separator.
\p{Zs} a whitespace character that is invisible, but does take
up space.
\p{Zl} a line separator character U+2028.
\p{N} any kind of numeric character in any script.
\p{Nd}: a digit zero through nine in any script except ideographic
(5) Disallow matching of unicode blocks.
Thanks,
Rob
Educating _all_ module authors to write [0..9] instead of \d will
likely be more expensive than improving the code of implementations
that did not implement YANG entirely to accept \d.
/js
_______________________________________________
netmod mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/netmod
<https://www.ietf.org/mailman/listinfo/netmod>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
