Lada, >> While I agree that tools are easier to update than WG documents, and that a >> broken yanglint isn't a strong reason to avoid the proposed axis construct, >> I do think it will have a cost. In current YANG practice, XML axis >> constructs are esoteric, and many implementations will either not support >> it, or have not been tested properly in this area before. Many engineers >> will never have seen this before, and might stumble. >> >> Bottom line, this is valid YANG, and it is supposed to work. For many people >> it will definitely be less readable than a relative path. I expect choosing >> the axis solution will slow the uptake of this module. > > I disagree. Tools should faithfully implement the standard, and especially > those that are used as "authoritative" in RFC validation process. I don't see > how axes could be considered esoteric - in fact, they are very fundamental in > XPath and things like '..' or '//' are just syntactic sugar for axes > contructs.
I'm not going to argue with you when it comes to XPath in general. Axes are (a fundamental) part of it. I'm just speaking of current YANG practice. Out of the 45k YANG modules in the IETF YANG repo on Github (which includes standard, experimental and many vendor modules), I did not find any using axes today. I think that observation makes it reasonable to call them esoteric in YANG context. I have seen axes used in the real world YANG modules a handful of times. Each time it led to real world problems. They could be worked around and resolved, but it required YANG expert involvement and additional coding and testing efforts. My conclusion is that usage of axes is typically causing trouble and decreasing readability+understanding in the real world. Best Regards, /jan
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
