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