Hi Juergen,
On 02/09/2017 08:33, Juergen Schoenwaelder wrote:
On Fri, Sep 01, 2017 at 10:45:51AM +0100, Robert Wilton wrote:
Hi Alex,
On 01/09/2017 00:57, Alex Campbell wrote:
Hi,
I'd be very wary of adding guidelines that restrict the regex syntax.
A tool that supports YANG must implement the full regex language anyway
(or ignore regexes altogether if they are not relevant to the tool's
function).
This is true if the tool is designed to work with any arbitrary YANG
module. But if a tool only needs to work with a subset of YANG modules
(e.g. perhaps just IETF, OpenConfig, and Vendor models) then they only need
to support the subset of the XML RE language that is used by the YANG
modules that they load.
Rob,
you are on the path to create multiple flavours of YANG, an IETF
flavour, an OC flavour, a Vendor XYZ flavour - in my view this can't
be the goal of a standard.
This is the actually the polar opposite of my aim. My aim is to try and
stop the fragmentation that is already happening in the industry, via
what I perceive is a pragmatic compromise. I appreciate others
feel differently.
I.e. make XML RE easy enough to use that others in the industry don't
feel that they need to fork YANG for this reason. My understanding is
that for the OpenConfig YANG models authors, the "must use an XML RE
implementation argument" doesn't seem to be working, in that their
models are currently defined using POSIX regex pattern statements that
are certainly incompatible with XML RE (they have anchors). Although my
understanding is that they may move to define a separate "posix pattern"
statement instead, I would guess that they will probably only use the
"posix pattern" statement in their models and not define both the POSIX
and XML RE expressions.
So, as it stands today, I think that we will either already end up with
effective multiple flavours of YANG, or that YANG implementations will
need to support both XML RE and POSIX RE implementations. I think that
is a worse outcome for the wider industry than just encouraging people
to only use a pragmatic subset of XML RE for network management YANG models.
Rob
A compliant implementation of YANG 1.0 and YANG 1.1 must handle XSD
pattern.
/js
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
