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.
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
