> -----Original Message----- > From: netmod [mailto:[email protected]] On Behalf Of Ladislav > Lhotka > Sent: Wednesday, September 7, 2016 8:22 PM > To: Vladimir Vassilev <[email protected]> > Cc: [email protected] > Subject: Re: [netmod] Circular dependency in 'when' > > > > On 07 Sep 2016, at 19:44, Vladimir Vassilev <[email protected]> > wrote: > > > > On 09/07/2016 02:18 PM, Martin Bjorklund wrote: > >> Hi, > >> > >> Your example is not circular, and it is legal. However, the 'when' > >> expression refers to the node in which the when expression is defined. > >> Note that this expression will always evaluates to 'false' (see the > >> third bullet in 7.21.5 in RFC 7950). > > This is true for YANG 1.1 due to that 3rd bullet in 7.21.5. > > > > However it should be noted that in YANG 1.0 nothing says the data node > for which the "when" statement is defined will be replaced with dummy > node > without a value so that this expression always evaluates to 'false'. In > YANG 1.0 the expression can evaluate to 'true' when a+b=100. > > Using "when" expressions that refer to the context node or its descendants > could easily lead to deadlocks in YANG 1.0, so this part was underspecifed > and ill-defined. The new 1.1 procedure for evaluating "when" expressions > is thus a bug fix. Although it is somewhat tricky and sometimes (as in > your example) counter-intuitive at first sight, it leads to unambiguous > and stable results. > > >> > >> Take a step back and consider what the 'when' statement means - it is > >> used to indicate if the node can be present or not. As such, it > >> doesn't make any sense to refer to the node itself in the xpath > >> expression. > > > >> In your case, you probably want to use a 'must' expression. This is > >> evaluated once the node is present, in order to enforce some > >> constraint. > >> > > I agree. I think the conclusion can be generalized to: there is no point > in using "when" expressions directly depending on the value of the data > node for which the "when" statement is defined or its children when the > parent is not 'augment', 'uses', 'case' or 'choice' statement in YANG 1.1 > because the 'when' statement will always evaluate to 'false' and the data > node will never exist. > > Not necessarily. The following expression is always true: > > leaf foo { > when "."; > ... > } > > > > > Would be helpful if model validation tools could issue at least warning > in such cases. > > This is rather difficult to detect in general. XPath is a complicated > beast.
We've implemented partial evaluation of XPath expressions that operates on an "accessible tree skeleton" (schema of the accessible tree as defined by modules in scope). For the example given by Vladimir, our compiler would complain with: WARNING; test@2016-09-07:8; when: XPath construct '.' (at 2) references the initial context node or one of its descendants in a when expression since it is referring to the "leaf" for which the "when" statement is defined and this was discouraged by one of the 6087bis drafts. It would detect this (and other issues) no matter how "obfuscated" the expression is. Implementing it was mostly problematic due to poorly defined accessible trees or initial context nodes in some cases (YANG 1). Jernej > > Lada > > > > > Vladimir > >> > >> /martin > >> > >> > >> Vladimir Vassilev <[email protected]> wrote: > >>> Hi, > >>> > >>> Is there any practical value of 'when' statements with circular > >>> dependency to the value of the parent (in case it is a leaf) or any > >>> children of the parent? > >>> > >>> container circular-dependency-when { > >>> leaf a { > >>> when "(. + ../b) = 100"; > >>> type uint16 { > >>> range "0 .. 100"; > >>> } > >>> } > >>> leaf b { > >>> type uint16 { > >>> range "0 .. 100"; > >>> } > >>> } > >>> } > >>> > >>> > > > > _______________________________________________ > > netmod mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
