> On 16 Dec 2015, at 16:17, 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
Yes, that's how I think it should be. It's tricky because x:foo doesn't appear
in the XML encoding of <rpc-reply> - that's what I asked about previously in
this thread.
Lada
> YANG pattern to my "my-rpc" example in ietf-netconf-notifications for a
> "notification".
>
> 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
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
