Jernej Tuljak <[email protected]> wrote:
>
> Dne 16.12.2015 ob 17:18 je Martin Bjorklund zapisal(a):
> > 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
>
> No. How do you explain the different wording for "input" when compared
> to "output" (6020, 7.19.5):
>
> o If the context node represents RPC input parameters, the tree is
> the RPC XML instance document. The XPath root node has the
> element representing the RPC operation being defined as the only
> child.
>
> o If the context node represents RPC output parameters, the tree is
> the RPC reply instance document. The XPath root node has the
> elements representing the RPC output parameters as children.
>
> "XPath root node has the _element_ representing the RPC operation as
> the _only child_" vs. "XPath root node has the _elements_ representing
> the RPC output as _children_".
>
> This is different from what 6020bis-09 is saying. The latter
> "equalized" accessible trees for "input" and "output". What I am
> asking is whether this confilcts with 1.1 charter.
You're right, but the entire thing is underspecifed in 6020. In the
example you had:
rpc foo {
output {
uses my-stuff {
when "...";
}
}
}
and if you go by 6020, there is no context node for the when
expression, and the accessible tree is defined in terms of the context
node.
Yes this is different in 1.1, but I think we're specifying rules for
something that wasn't specified, and fix inconsistencies.
> You could never refer to "nc:rpc-reply" as anything other that the
> document root in 1.0 ("/") . You could never refer to "nc:rpc" either,
> only to "x:foo".
It depends on how you interpret the words: "the tree is the RPC reply
instance document."
> >> 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.
>
> True. It is unspecified. For notifications also, yet
> ietf-netconf-notifications practices it.
It just uses relative paths, in places where the context node is
well-defined.
/martin
>
> Jernej
>
> >
> > /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
>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
