Hi Andy,
On 02/09/2017 17:46, Andy Bierman wrote:
On Sat, Sep 2, 2017 at 4:28 AM, Juergen Schoenwaelder
<[email protected]
<mailto:[email protected]>> wrote:
On Sat, Sep 02, 2017 at 10:39:57AM +0000, Acee Lindem (acee) wrote:
>
> This is not an effort to change or bifurcate the YANG 1.1. It is
simply to
> RECOMMEND a proper subset of XSD pattern that is more portable.
>
If you implement YANG as it is defined, pattern are portable. Given
this, I do not understand the notion of 'more portable'.
Anyway, it seems that those who want a more portable subset do not
even agree on what that subset is. Perhaps people pushing for this
should go and write an I-D that explains why a 'more portable' subset
is needed (which problems are we fixing), that defines such a 'more
portable subset', and which includes the reasoning how the subset has
been determined.
I do not agree that the YANG pattern contains a string that is both a
POSIX and XSD regular expression.
The RFC is very clear it contains an XSD expression. Pretending it is
both is a hack that does not even seem
to work 100%, so it is not reliable.
I am not suggesting that the YANG pattern is both a POSIX and XSD
regular expression.
I am only suggesting that the guidelines recommend that authors use a
subset of XSD, to make it easier to programmatically *convert* the 'XSD
subset compliant regular expression' into a functionally equivalent
regular expression for whatever regular expression engine the tooling
decides to use.
E.g. this seems to be the approach used by "libyang" that uses libpcre
as the backend RE library rather than libxml. Unfortunately, I think
that the libyang library would currently fail if the pattern statement
contained "[[A-Z]-[P-R]]" because it looks like the PCRE2 language does
not support character class subtraction. ACAICT, no standard YANG
modules currently support character class subtraction, so the authors of
libyang have a choice here:
(i) write a block of code that most likely nobody is going to use, or
(ii) document the limitation, spot character class subtraction in the
regex, and flag that it is not supported (or perhaps just ignore it).
If the community wants to support both XSD and POSIX expressions, then
the proper engineering
solution is to introduce a new statement that is defined to contain a
POSIX expression.
This can be done with a YANG extension now and added to YANG 2.0 later.
I think that this is an inferior solution:
- there are many languages that YANG tools could be written in: C/C++,
Python, Java, Go, Rust, Javascript are all reasonably plausible choices.
- they all have similar, but with small differences regular expression
flavours (according to http://www.regular-expressions.info/reference.html).
- Personally, I see no inherent advantage of the POSIX Extended Regex
over XML RE. In fact, given that it doesn't support Unicode at all, it
would seem to be a somewhat strange choice for a second pattern statement.
- Nor does it seem pragmatic to introduce lots of different flavors of
pattern statements into YANG each supporting a different regex syntax.
I also don't like the solution that every YANG tool maker has to either
link against libxml2, or write their own efficient regular expression
engine. I'm not convinced that what the world needs is yet more regular
expression implementations :-)
So, I still see that the better technical solution is always only define
the pattern statements in XML RE language, but to strongly encourage
folks to use a subset of that language for standards models (which they
appear to be doing anyway) to make it easier to covert the regular
expression into compatible versions for other engines.
Thanks,
Rob
/js
Andy
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <http://www.jacobs-university.de/
<http://www.jacobs-university.de/>>
_______________________________________________
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
