From: netmod <netmod-boun...@ietf.org> on behalf of Andy Bierman <a...@yumaworks.com> Sent: 02 February 2022 21:46
<tp> Agreeing with Andy, Lada and so on but adding a contextual note. This augment/when construct is widely used in TEAS and CCAMP modules, of which there are a very large number, and in any one module, the augment/when can appear over 100 - yes one hundred - times because of the way that the base module that is being augmented has been structured so the potential gain in simplicity, readability is considerable. Tom Petch On Wed, Feb 2, 2022 at 2:41 AM Ladislav Lhotka <ladislav.lho...@nic.cz<mailto:ladislav.lho...@nic.cz>> wrote: On 02. 02. 22 11:15, Jan Lindblad wrote: > 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. This is a slippery slope. It's quite likely that none of existing modules has ever used other XPath features, such as some built-in functions. Does it mean that implementations may ignore them and fail upon encountering such features. Who is going to decide what is esoteric and what not? RFC 8470 lists some XPath features that should not be used for good reasons (including some axes), but the rest should IMO be OK to use. I think you mean RFC 8407. I checked and it does not say to avoid using the ancestor axis. I checked our tools which support full XPath and no problems. Looking at the actual usage (below), the 'ancestor' approach is more readable and easier for the writer to generate correctly. Given that the "network" node must be present in the augment-stmt, it is not a concern that it is used directly in the when-stmt. augment "/nw:networks/nw:network/nw:node/tet:te/" + "tet:te-node-attributes/tet:connectivity-matrices/" + "tet:label-restrictions/tet:label-restriction" { when "ancestor::nw:network/nw:network-types/" + "tet:te-topology/flexgt:flexi-grid-topology"; /* when "../../../../../../nw:network-types/tet:te-topology/" + "flexgt:flexi-grid-topology" { description "Augmentation parameters apply only for networks with flexi-grid topology type."; } */ description "Augment TE label range information for the TE node connectivity matrices."; uses l0-types:flexi-grid-label-range-info; } Andy > > 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 In my experience, the complexity is not so much in XPath itself but rather in brittle semantics of 'when'. Lada > > Best Regards, > /jan > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ yang-doctors mailing list yang-doct...@ietf.org<mailto:yang-doct...@ietf.org> https://www.ietf.org/mailman/listinfo/yang-doctors _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
