On Wed, Dec 16, 2015 at 7:17 AM, Jernej Tuljak <[email protected]> wrote:
> Ladislav Lhotka je 16.12.2015 ob 15:10 napisal: > >> On 16 Dec 2015, at 14:08, Jernej Tuljak <[email protected]> wrote: >>> >>> Martin Bjorklund je 16.12.2015 ob 13:48 napisal: >>> >>>> Jernej Tuljak <[email protected]> wrote: >>>> >>>>> Martin Bjorklund je 25.11.2015 ob 11:16 napisal: >>>>> >>>>>> Ladislav Lhotka <[email protected]> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I'd like to resolve this issue. Here is a complete example (valid, I >>>>>>> believe): >>>>>>> >>>>>>> module context { >>>>>>> namespace "http://example.com/context";; >>>>>>> prefix ctx; >>>>>>> >>>>>>> leaf foo { >>>>>>> config false; >>>>>>> type uint32; >>>>>>> } >>>>>>> rpc oper { >>>>>>> output { >>>>>>> must "/foo mod foo = 0"; >>>>>>> leaf foo { >>>>>>> type uint32; >>>>>>> } >>>>>>> } >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> 1. What does the accessible tree look like? >>>>>>> >>>>>> Note that the anser to this depends on the outcomne of Y04. Andy has >>>>>> strong objections to Y04-02, and proposed Y04-04 instead. >>>>>> >>>>>> Assuming Y04-02, and assuming /foo has the value 20 and the oper rpc's >>>>>> result has foo = 10, the accessible tree would look like this: >>>>>> >>>>>> <root> >>>>>> +-- oper >>>>>> | +-- foo = 10 >>>>>> +-- foo = 20 >>>>>> >>>>>> >>>>>> (If we instead move back to Y04-04, the accessible tree would be: >>>>>> >>>>>> <root> >>>>>> +-- oper >>>>>> +-- foo = 10 >>>>>> >>>>>> ) >>>>>> >>>>>> 2. What is the context node for the "must" expression? >>>>>>> >>>>>> /oper >>>>>> >>>>> This change to the accessible tree (1.0 --> 1.1) may break some >>>>> existing "when" XPath expressions (those under "output" statement). >>>>> >>>> Maybe. The old text said: >>>> >>>> o If the context node represents RPC output parameters, the tree is >>>> the RPC reply instance document. >>>> >>>> So this probably meant that for this definition: >>>> >>>> module ex { >>>> ... >>>> prefix x; >>>> ... >>>> rpc foo { >>>> output { >>>> leaf bar { ... } >>>> } >>>> } >>>> } >>>> >>>> The accessile tree was: >>>> >>>> nc:rpc-reply >>>> +-- x:bar >>>> >>>> This is very NETCONF-specifc. With 1.1, the tree would be: >>>> >>>> x:foo >>>> +-- x:bar >>>> >>>> which is protocol-neutral. >>>> >>>> Is >>>>> this compatible with 1.1 charter - "All compliant YANG 1.0 modules >>>>> must be accepted as compliant YANG 1.1 modules"? >>>>> >>>>> rpc my-rpc { >>>>> output { >>>>> uses my-stuff { >>>>> when "specific-param = 'foo'";// 1.0 >>>>> // when "my-rpc/specific-param = 'foo'" // 1.1 >>>>> >>>> This is not correct. If a relative path is used, it would be the same >>>> in 1.0 and 1.1. >>>> >>> I disagree due to current text: >>> >>> o data node: A node in the schema tree that can be instantiated in a >>> data tree. One of container, leaf, leaf-list, list, anydata, and >>> anyxml. >>> >>> o If the XPath expression is defined in a substatement to an >>> "output" statement in an "rpc" or "action" statement, the >>> accessible tree is the RPC or action operation instance, all state >>> data in the server, and the running configuration datastore. The >>> root node has top-level data nodes in all modules as children. >>> Additionally, for an RPC, the root node also has the node >>> representing the RPC operation being defined as a child. The node >>> representing the operation being defined has the operation's >>> output parameters as children. >>> >>> o If the "when" statement is a child of a "uses", "choice", or >>> "case" statement, then the context node is the closest ancestor >>> node to the "uses", "choice", or "case" node that is also a data >>> node. If no such node exists, the context node is the root node. >>> The accessible tree is tentatively altered during the processing >>> of the XPath expression by removing all instances (if any) of the >>> nodes added by the "uses", "choice", or "case" statement. >>> >>> >>> It clearly says that the context node is the root node ("/"), not the >>> node representing the RPC ("/my-rpc"), which is a child to root node. The >>> "root node" aka "document root" can only mean a single thing XPath >>> terminology. >>> >> RFC 6020 clearly says that the tree is the rpc reply instance document, >> so it is a different document whose root node coincides with <rpc-reply>. >> The problem of 6020bis is that we need a definition that's independent of >> XML, and that's not so easy, but I agree with Martin that nothing should >> change for relative paths. >> > > I'm not against the new accessible tree. That nothing should change for > relative paths is a given, IMO. So what about absolute location paths? > > The previous accessible tree for a "when" expression under "output" was: > > <root> > +- x:bar > > and now it is: > > <root> > +- x:foo > +- x:bar > > The absolute path to "x:bar" was: > > /x:bar > > and is now: > > /x:foo/x:bar > > and this needs to be taken into account for at least relative paths to > stay the same. Again, the root node is "/" in any case. So the context node > needs to be set explicitly "/x:foo" for this corner case. I dare say it is > not even a corner case. There is a similar YANG pattern to my "my-rpc" > example in ietf-netconf-notifications for a "notification". > > I am strongly opposed to changing the way when-stmt works, and against expanding the XPath context for RPC and notifications. You are demonstrating the types of complicated hacks required to implement YANG 1.1. Jernej > > >> Lada >> >> Jernej >>> >>> If an absolute path is used, it would be: >>>> >>>> when "/nc:rpc-reply/x:specific-param = 'foo'"; // 1.0 >>>> when "/x:my-rpc/x:specific-param = 'foo'"; // 1.1 >>>> >>>> >>>> I wonder if any implementation of 1.0 supports this absolute form. >>>> >>>> >>>> /martin >>>> >>>> >>>> } >>>>> leaf specific-param { >>>>> type string; >>>>> } >>>>> } >>>>> } >>>>> >>>>> Jernej >>>>> >>>>> /martin >>>>>> >>>>>> >>>>>> >>>>>> Thanks, Lada >>>>>>> >>>>>>> Martin Bjorklund <[email protected]> writes: >>>>>>> >>>>>>> Ladislav Lhotka <[email protected]> wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Y02-01 allows "must" as a substatement of "input", "output" and >>>>>>>>> "notification" but for these cases the specification of the context >>>>>>>>> node in sec. 7.5.3 doesn't work. >>>>>>>>> >>>>>>>>> o The context node is the node in the accessible tree for >>>>>>>>> which the >>>>>>>>> "must" statement is defined. >>>>>>>>> >>>>>>>> You are right. But note how the accessible tree is defined. There >>>>>>>> is >>>>>>>> a node for the operation / notification. This node should be the >>>>>>>> context node: >>>>>>>> >>>>>>>> o If the "must" statement is a substatement of a >>>>>>>> "notification" >>>>>>>> statement, the context node is the node representing the >>>>>>>> notification in the accessible tree. >>>>>>>> >>>>>>>> o If the "must" statement is a substatement of a "input" >>>>>>>> statement, the context node is the node representing the >>>>>>>> operation in the accessible tree. >>>>>>>> >>>>>>>> o If the "must" statement is a substatement of a "output" >>>>>>>> statement, the context node is the node representing the >>>>>>>> operation in the accessible tree. >>>>>>>> >>>>>>>> >>>>>>>> /martin >>>>>>>> >>>>>>> -- >>>>>>> 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 >>>> >>>> _______________________________________________ >>> 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 >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
