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
No it was:
<root>
+-- nc:rpc-reply
+- x:bar
> and now it is:
>
> <root>
> +- x:foo
> +- x:bar
>
> The absolute path to "x:bar" was:
>
> /x:bar
/nc:rpc-reply/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 think what needs to be done is to clarify that the context node for
when/must in input/output or uses in input/output is the node
representing the rpc. Note that this is unspecified in 6020.
/martin
>
> 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
