Re: [yang-doctors] YANG dialects?

["Rob Wilton (rwilton)" <[e-mail]>]

From: Jan Lindblad <[e-mail]>
Sent: 19 December 2019 17:36
To: Rob Wilton (rwilton) <[e-mail]>
Cc: Martin Bjorklund <[e-mail]>; [e-mail]; [e-mail]
Subject: Re: [yang-doctors] YANG dialects?


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).

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.
[RW]
Adding beginning/end anchors before processing a regex is trivial.  I.e. if the pattern is defined in XML regex, where the anchors are missing, implementations that want to put them into a POSIX regex need to add the anchors before processing the regex.

Thanks,
Rob



/jan