Question about regex

YANG
1

Hi ConfD team,

I encountered a regex in a YANG model with pattern:
^([0-9]+\.\.[0-9]+)|exact$
and ConfD 6.2 seems to interpret character ^ and $ literally. I’ve searched about the YANG RFC, and as stated in XSD flavor regex documentation, it

implicitly anchors all regular expressions at the head and tail

So the correct regex above should be ([0-9]+\.\.[0-9]+)|exact instead?

Thanks so much for your time and help!
Xiaoqin

2

Correct. Your string pattern would allow for example “0…99” or “exact” to be a valid input.

3

Thanks a lot!
I found this issue in openconfig repository, it seems like the $ and ^ is introduced because they adopted POSIX not XSD regular expressions.

4

That’s a plain bug in the OpenConfig case - the YANG spec is perfectly clear on the issue. It’s not up to an implementor to “take a pick”, such an attitude reveals a complete lack of understanding of the concepts of standards and interoperability. (And it seems to me that one “widely available software implementation for the W3C standard” (i.e. libxml2) is entirely sufficient.)

As for rationale, anchors are great when 'grep’ing arbitrary text files. But that is not how regexps are used in YANG (or XSD). The ‘pattern’ statement specifies a restriction on a leaf value (or leaf-list element), and 99% of the time you want the regexp to match the complete value - having to add the anchors is just a nuisance. In the rare cases where you want a non-anchored regexp, you just need to add “.*” at one or both ends.

5

Thanks so much for the explanation, and it seems that both ConfD and libyang disapprove explicit anchors, I’ll go with what states in YANG RFC.

6

Thank you for the clarification on this, Per. At Developer Days, it was mentioned that an upcoming confdc version will allow some of these non-compliant regex expressions. Will this sort of thing (explicit anchoring) be supported by confdc in the near future? If so, do you know what version?

7

Sorry, I’m not aware of any such changes being planned - which doesn’t mean that they aren’t, it might just be that I don’t know about them. From a technical point of view, I think any form of “combined” support that would allow variants would be a very bad idea though - it opens up for incorrect interpretations and undetected mistakes.