consider the following yang module
module mod {
yang-version 1;
namespace "http://example.com/mod";
prefix m;
revision "2016-09-09" {
description "Initial revision.";
}
container foo {
description 'container foo';
leaf l {
type string;
}
}
}
Which path expression is correct in reaching to leaf l ?
/mod:foo/l
/m:foo/l
/foo/l
If I have 2 revisions of the same module active in my application, how does a client express which revision node he is interested in?
and, is there a path expression available to refer the 'description' of leaf l ?
Which path expression is correct in reaching to leaf l ?
In the context of a RESTCONF GET, the scheme described in draft-ietf-netconf-restconf-16, Section 3.5.3, Encoding Data Resource Identifiers in the Request URI is used.
A RESTCONF data resource identifier is encoded from left to right, starting with the top-level data node, according to the "api-path" rule in Section 3.5.3.1. The node name of each ancestor of the target resource node is encoded in order, ending with the node name for the target resource. If a node in the path is defined in another module than its parent node, or its parent is the datastore, then the module name followed by a colon character (":") MUST be prepended to the node name in the resource identifier. See Section 3.5.3.1 for details.
Therefore the correct URI would be something like this:
/restconf/data/mod:foo/l
If I have 2 revisions of the same module active in my application, how does a client express which revision node he is interested in?
You cannot express such a request. This is one of the reasons why a server is only allowed to implement a single revision of a YANG module. In YANG 1.1 this is explicitly prohibited, while in YANG 1.0, this is only implied. Note that respective implemented YANG modules may refer to (import) several revisions of the same module, but only a single one of those may be advertised as implemented (probably the newest one). Since module updating rules are quite strict, definitions will not just go missing in a newer revision of a module, so clients are safe.
is there a path expression available to refer the 'description' of leaf l ? my usecase for the 'description' is, something like this. A client submits a yang module to a server. Client wants to make sure that server is seeing the structure correctly. Client says , "show me the description of that leaf", or, "what is the default of a leaf" etc.
You seem to be misunderstanding the role of a YANG model. A client does not govern a server's model, it may only govern the data that is described in that model! Such a thing is in the domain of the server and its maintainer.
The only standard way of querying the YANG model (that I am aware of) and not the data modeled by it, would be to obtain the YANG/YIN file from the server (get-schema) and then parse it yourself.
As a side note. A client that implements your module and receives a valid response from a server is inherently aware of which description maps to which XML element/JSON object, because it already did the "mapping" between an instance document and the model (schema) during the validation phase.