On Wed, Nov 25, 2015 at 5:15 AM, Martin Bjorklund <[email protected]> wrote:
> Juergen Schoenwaelder <[email protected]> wrote: > > On Wed, Nov 25, 2015 at 01:31:01PM +0100, Martin Bjorklund wrote: > > > Juergen Schoenwaelder <[email protected]> wrote: > > > > On Wed, Nov 25, 2015 at 09:48:55AM +0100, Ladislav Lhotka wrote: > > > > > Hi, > > > > > > > > > > I'd like to resolve this issue. Here is a complete example (valid, > I believe): > > > > > > > > > > > > > Sorry for asking a stupid question but what is the use case of > > > > referencing state data from an xpath expression in RPC input or > > > > output parameters? > > > > > > It all started with leafrefs in notifications. The algorithm in RFC > > > 6643 produces leafrefs from notifications to state data. See Y04. > > > > > > For the same reason, you may want to reference let's say an interface > > > name in the /interfaces-state/interface list from an RPC input > > > parameter. > > > > > > > Yes, but where does xpath come into play? > > The leafref's path is XPath. See the example in Y04. It might be > surprising that this is illegal (if we do Y04-04): > > rpc foo { > input { > leaf ifref { > type leafref { > path "/if:interfaces-state/if:interface/if:name"; > } > must "/if:interfaces-state/if:interface[if:name = > current()/ifref]" > + "/if:enabled"; > } > } > } > > The leafref is legal, but the must expression would be illegal. > > > I agree with Juergen about questioning the need for this new feature. The path expression is limited. XPath is not limited at all. The code to find the "pointed-at" leaf is much simpler than full XPath. > /martin > > Andy > > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
