types CHANGE redesign storing canonical values
Canonical values are not available for all the types and the type's
printer should be used to get string representation instead of trying to
get string value directly from the lyd_value. So, the canonical value is
now much more hidden in lyd_value structure. On the other hand, there is
newly available original string representation of the value (some of the
types already needed it), which is always present no matter of the
value's type.
diff --git a/src/libyang.h b/src/libyang.h
index 26fa65d..eba8008 100644
--- a/src/libyang.h
+++ b/src/libyang.h
@@ -118,6 +118,17 @@
* The lists are structures connected via a `next` pointer. Iterating over the siblings can be simply done by ::LY_LIST_FOR macro.
*/
+/**
+ * @page howtoplugins Plugins
+ *
+ * libyang supports several types of plugins to better support generic features of YANG that need some specific code for
+ * their specific instances in YANG schemas. This is the case of YANG types, which are derived from YANG built-in types
+ * (which are implemented by libyang), but the description of the derived type can specify some additional requirements or
+ * restriction that cannot be implemented generically and some special code is needed. The second case for libyang plugins
+ * are YANG extensions. For YANG extensions, most of the specification stays in their description (e.g. allowed substatements
+ * or place of the extension instanciation) and libyang is not able to process such a text in a generic way. In both cases,
+ * libyang provides API to provide functionality implementing the specifics of each type or extension.
+ */
#ifdef __cplusplus
}
#endif