> On 17 Dec 2015, at 14:28, Jernej Tuljak <[email protected]> wrote: > > Martin Bjorklund je 17.12.2015 ob 13:23 napisal: >> Jernej Tuljak <[email protected]> wrote: >>> Martin Bjorklund je 16.12.2015 ob 18:47 napisal: >>>> 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." >>> There is no room for misinterpreting what an XPath root node is (next >>> sentence). Even if the processing is actually done on an RPC reply >>> instance document, an RPC instance document or a notification instance >>> document, "nc:rpc-reply", "nc:rpc" and "ncEvent:notification" are >>> simply not part of the YANG XPath model as anything else than a root >>> node ("/") and they never were. The QNames previously listed do not >>> exist in this model. >>> >>>>>>> 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. >>> The specific definition I had in mind is netconf-confirmed-commit >>> "notification" (trimmed): >>> >>> notification netconf-confirmed-commit { >>> uses common-session-parms { >>> when "confirm-event != 'timeout'"; >>> } >>> } >>> >>> The context node for this "when" is as unspecified as in my original >>> example for "output" per 6020 (no data node ancestor to "uses"). And >>> in 6020bis-09 the context node now defaults to root node (not >>> root/document element)! >> As I wrote before, this needs to be fixed. We need to take the >> node representing the notification (or rpc) into account. Do you >> agree? > > I agree. The root node is acceptable only if none of these ancestors are > found: a data node, node representing a notification, node representing an > rpc, node representing rpc output.
The latter is somewhat more peculiar because it doesn't appear in XML instances - the others do. I think it would be useful to include a section describing the data tree, its properties, and how it maps to XPath. This is a bit difficult prospect though given that 6020bis is already in the (second) WGLC. Lada > > Jernej > >> >>> So if I take >>> ietf-netconf-notifications@2012-02-06 and add a "yang-version 1.1;" to >>> it, the module will break. >>> Furthermore the absolute XPath location path for confirm-event node is >>> "/ncn:netconf-confirmed-commit/ncn:confirm-event", not >>> "/ncEvent:notification/ncn:netconf-confirmed-commit/ncn:confirm-event", >>> which is what you seem to be saying. >> No, you are right. >> >> >> /martin >> >> >>> If this is what the intention >>> was, several errata need to be posted for 6020. We implement the 1.0 >>> accessible tree the way I have been describing, and yes, we do >>> implement absolute location paths. >>> >>> XPATH, 5.1 (http://www.w3.org/TR/1999/REC-xpath-19991116/#data-model): >>> The root node is the root of the tree. A root node does not occur >>> except as the root of the tree. The element node for the document >>> element is a child of the root node. >>> >>> 6020: >>> >>> The data model used in the XPath expressions is the same as that used >>> in XPath 1.0 >>> >>> [XPATH<https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-09#ref-XPATH>], >>> with the same extension for root node children >>> as used by XSLT 1.0 >>> >>> [XSLT<https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-09#ref-XSLT>] >>> (Section 3.1). Specifically, it means >>> that the root node may have any number of element nodes as its >>> children. >>> >>> o data node: A node in the schema tree that can be instantiated in a >>> data tree. One of container, leaf, leaf-list, list, and anyxml. >>> >>> 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. >>> >>> o If the context node represents notification content, the tree is >>> the notification XML instance document. The XPath root node has >>> the element representing the notification being defined as the >>> only child. >>> >>> 6020bis-09: >>> >>> The data model used in the XPath expressions is the same as that used >>> in XPath 1.0 [XPATH], with the same extension for root node children >>> as used by XSLT 1.0 [XSLT] (Section 3.1). Specifically, it means >>> that the root node may have any number of element nodes as its >>> children. >>> >>> 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 a >>> "notification" statement, the accessible tree is the notification >>> instance, all state data in the server, and the running >>> configuration datastore. If the notification is defined on the >>> top-level in a module, then the root node has the node >>> representing the notification being defined and all top-level data >>> nodes in all modules as children. Otherwise, the root node has >>> all top-level data nodes in all modules 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. >>> >>> >>> I hope this clarifies what my previous email was saying about >>> ietf-netconf-notifications. The accessible tree for "output" is a >>> different issue. >>> >>> (PS: I've been having trouble replying to the mailing list ever since >>> we migrated our mail server which is why my previous message was not >>> sent to the mailing list and Martin seemed to be replying to thin >>> air.) >>> >>> Jernej >>> >>>> >>>> /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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
