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