On 04/09/2017 16:55, Andy Bierman wrote:
On Mon, Sep 4, 2017 at 7:05 AM, Robert Wilton <[email protected]
<mailto:[email protected]>> wrote:
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.
Looks like you want the expression to mean the exact same thing in
multiple expression languages
and you want to put the burden of this perfect subset on humans who
write YANG.
Again, no, that is not what I want.
I would like the rules to recommend that authors of standards based YANG
modules don't use the bits of the XML RE language that (i) they don't
use anyway, (ii) don't appear to have any compelling use case in
standard YANG modules, and (iii) are hard to convert to other RE languages.
There recommendations also have the additional advantage that the
pattern statements that follow these rules are likely to be much easier
to understand because they use the aspects of regular expressions
languages that folks are likely to be more familiar with.
This is a really unworkable plan.
Is my proposed 6087bis text really that complicated?
Thanks,
Rob
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
<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.
You seem to be confirming that picking 1 flavor of Posix would be
impossible.
All the more reason to keep the XSD pattern unburdened.
I see no reason XSD patterns should be constrained because some
implementors want to
ignore the RFC and pretend the string is some other expression language.
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 :-)
The write your own tools and don't use libxml2.
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
Andy
/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
