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