libyang 1.0.184
YANG data modeling language library
Validating Data

By default, the represented data are supposed to represent a full YANG datastore content. So if a schema declares some mandatory nodes, despite configuration or status, the data are supposed to be present in the data tree being loaded or validated. However, it is possible to specify other kinds of data (see Data parser options) allowing some exceptions to the validation process.

Data validation is performed implicitly to the input data processed by the parser (lyd_parse_*() functions) and on demand via the lyd_validate() function. The lyd_validate() is supposed to be used when a (complex or simple) change is done on the data tree (via a combination of lyd_change_*(), lyd_insert*(), lyd_new*(), lyd_unlink() and lyd_free() functions).

Part of data validation is resolving leafrefs and instance-identifiers. Leafrefs are resolved only when a change occurred in the data tree that could have broken the link. However, as instance-identifiers can point to any node whatsoever without an import, it would not be effective to store metadata as in the case of leafrefs. That is why they are resolved during every validation. Also, for the same reason, it can easily happen that when parsing/validating data with an instance-identifier, it will target a remote node, whose schema is not currently present in the context. To handle this case, a callback should be set using ly_ctx_set_module_data_clb(), which can load the schema when required.

Must And When Conditions Accessible Tree

In YANG 1.1, there can be must and/or when expressions in RPC/action input or output, or in notifications that require access to the configuration datastore and/or state data. Normally, when working with any of the aforementioned data trees, they must contain only the RPC/action/notification itself, without any additional configuration or state data. So how can then these conditions be verified during validation?

There is an option to pass this additional data tree to all the functions that perform must and when condition checking (lyd_parse_*() and lyd_validate()). Also, there are 3 flags of struct lys_node that mark schema nodes that include paths that require foreign nodes (outside their subtree) for their evaluation. LYS_XPCONF_DEP marks nodes with such must and/or when expressions that require some configuration data, LYS_XPSTATE_DEP that require some state data, and LYS_LEAFREF_DEP with such a leafref. The subtree root is always the particular operation data node (for RPC it is the RPC data node and all the input or output nodes as its children and similarly for action and notification). Note that for action and not-top-level notification this means that all their parents are not considered as belonging to their subtree even though they are included in their data tree and must be present for the operation validation to pass. The reason for this is that if there are any lists in those parents, we cannot know if there are not some other instances of them in the standard data tree in addition to the one used in the action/notification invocation.

There were 2 ways of using this mechanism envisioned (explained below), but you can combine or modify them.

Fine-grained Data Retrieval

This approach is recommended when you do not maintain a full configuration data tree with state data at all times.

Firstly, you should somehow learn that the operation data tree you are currently working with includes some schema node instances that have conditions that require foreign data. You can either know this about every operation beforehand or you go through all the schema nodes looking for the flags LYS_XPCONF_DEP, LYS_XPSTATE_DEP, and LYS_LEAFREF_DEP. Then you should use lys_node_xpath_atomize() to retrieve all XPath condition dependencies (in the form of schema nodes) outside the operation subtree. You will likely want to use the flag LYXP_NO_LOCAL to get rid of all the nodes from inside the subtree (you should already have those). The last thing to do is to build a data tree that includes at least all the instances of the nodes obtained from lys_node_xpath_atomize() (it will be expected). Then you pass this tree to the validation and it should now have access to all the nodes that can potentially affect the XPath evaluation and no other.

Maintaining Configuration And State Data Tree

If you have a full data tree with state data available for the validation process then it is quite simple (compared to the first approach). You can simply always pass it to validation of these operations and in cases it is not required (no nodes with conditions traversing foreign nodes) only a negligible amount of redundant work is performed and you can skip the process of learning whether it is required or not.

Functions List