On Wed, Feb 2, 2022 at 2:41 AM Ladislav Lhotka <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
> https://www.ietf.org/mailman/listinfo/yang-doctors
>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
