Re: [yang-doctors] YANG dialects?

[Ladislav Lhotka <[e-mail]>]

On Thu, 2019-12-19 at 18:36 +0100, Jan Lindblad wrote:
> > > > > > Not so easy for all of them.
> > > > > > (1)
> > > > > > The pattern-stmt disaster cannot be addressed.
> > > > > 
> > > > > I think the solution is trivial, and it has been proposed to
> > > > > OpenConfig -
> > > > > introduce a new extension statement oc:posix-pattern.
> > > > > This will make the modules *legal*, and tools can use existing
> > > > > mechanisms
> > > > > to deal (or not) with this new statement.
> > > I don't think it is legal, because
> > > 
> > > o  extension: An extension attaches non-YANG semantics to statements.
> > > 
> > > This is not the case here, it is only syntactically compatible. If tool A
> > > says
> > > that some instance data is valid, but tool B says it isn't, then the
> > > standard is
> > > gone.
> > > 
> > > Lada
> 
> Of course it would be legal. It's always legal for a NETCONF server to reject
> an edit-config for no apparent reason (from a YANG perspective), so all device
> YANG models would still be legal if all pattern statements were removed, but
> the same string pattern constraints still enforced by the devices. The OC
> group could therefore remove their pattern statements and introduce a YANG
> extension oc:posix-pattern (or oc:go-pattern, or whatever) that gives a hint
> to some clients what is expected. The clients that don't understand this
> extension would just se a rejection for no apparent reason (from a YANG
> perspective).

I strongly disagree. Why then do we have so much text about constraints,
validity etc. in RFC 7950? The benefit of schema validation is that an
implementation can rely on an external validator and needn't clutter the code
with all kinds of input data checks. But if the validation result depends on
whether I choose library A or B, this concept simply falls apart.

Lada
> 
> > But, as I understand it, the regex implementations are not POSIX either.
> >  E.g. I think that they are using RE2 for Go, which is somewhat derived from
> > PCRE which is derived from POSIX regex, but not exactly compatible either.
> > 
> > So, it would end up replacing one regex language that can't be 100% directly
> > implemented with another regex language that can't be 100% directly
> > implemented.  This seems to make the life more complex not less.
> > 
> > I still believe that the only solution is to define as subset of XML regex
> > that can easily be translated into common regex engines. Although, as
> > Juergen has stated previously, this effectively defines a new regex language
> > ...
> 
> I don't think a subset is possible here. The subset would be the null set,
> since basically all the posix expressions have caret+dollar ^(...)$
> surrounding the actual expression, which are interpreted very differently than
> intended in the W3C world. So two separate pattern statements will be needed.
> 
> /jan
> 
> _______________________________________________
> yang-doctors mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/yang-doctors
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67