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?/operThis 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.1This 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:barNo it was: <root> +-- nc:rpc-reply +- x:barand now it is: <root> +- x:foo +- x:bar The absolute path to "x:bar" was: /x:bar/nc:rpc-reply/x:barNo. 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.
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. /martinIf 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/martinJernej/martinJernejLadaJernejIf 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/martinThanks, 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
