To be able to work with YANG data instances, libyang has to represent YANG data models. All the processed modules are stored in libyang context and loaded using parser functions. It means, that there is no way to create/change YANG module programmatically. However, all the YANG model definitions are available and can be examined through the C structures. All the context's modules together form YANG Schema for the data being instantiated.

Any YANG module is represented as lys_module. In fact, the module is represented in two different formats. As lys_module.parsed, there is a parsed schema reflecting the source YANG module. It is exactly what is read from the input. This format is good for converting from one format to another (YANG to YIN and vice versa), but it is not very useful for validating/manipulating YANG data. Therefore, there is lys_module.compiled storing the compiled YANG module. It is based on the parsed module, but all the references are resolved. It means that, for example, there are no groupings or typedefs since they are supposed to be placed instead of uses or type references. This split also means, that the YANG module is fully validated after compilation of the parsed representation of the module. YANG submodules are available only in the parsed representation. When a submodule is compiled, it is fully integrated into its main module.

The context can contain even modules without the compiled representation. Such modules are still useful as imports of other modules. The grouping or typedef definition can be even compiled into the importing modules. This is actually the main difference between the imported and implemented modules in the libyang context. The implemented modules are compiled while the imported modules are only parsed.

By default, the module is implemented (and compiled) in case it is explicitly loaded or referenced in another module as target of leafref, augment or deviation. This behavior can be changed via context options LY_CTX_ALL_IMPLEMENTED, when all the modules in the context are marked as implemented (note the problem with multiple revisions of a single module), or by LY_CTX_REF_IMPLEMENTED option, extending the set of references making the module implemented by when, must and default statements.

All modules with deviation definition are always marked as implemented. The imported (not implemented) module can be set implemented by lys_set_implemented(). But the implemented module cannot be changed back to just imported module. Note also that only one revision of a specific module can be implemented in a single context. The imported modules are used only as a source of definitions for types and groupings for uses statements. The data in such modules are ignored - caller is not allowed to create the data (including instantiating identities) defined in the model via data parsers, the default nodes are not added into any data tree and mandatory nodes are not checked in the data trees.

The compiled schema tree nodes are able to hold private objects (lysc_node.priv as a pointer to a structure, function, variable, ...) used by a caller application unless LY_CTX_SET_PRIV_PARSED is set, in that case the lysc_node.priv pointers are used by libyang. Note that the object is not freed by libyang when the context is being destroyed. So the caller is responsible for freeing the provided structure after the context is destroyed or the private pointer is set to NULL in appropriate schema nodes where the object was previously set. Also lysc_tree_dfs_full() can be useful to manage the private data.

Despite all the schema structures and their members are available as part of the libyang API and callers can use it to navigate through the schema tree structure or to obtain various information, we recommend to use the following macros for the specific actions.

LYSC_TREE_DFS_BEGIN and LYSC_TREE_DFS_END to traverse the schema tree (depth-first).
LY_LIST_FOR and LY_ARRAY_FOR as described on Data Structures page.

Further information about modules handling can be found on the following pages:

Note: There are many functions to access information from the schema trees. Details are available in the Schema Tree module.

For information about difference between implemented and imported modules, see the context description.

Functions List (not assigned to above subsections)