Understanding multi-level libraries

Multi-level libraries allow documentation organizations to organize their content libraries in layers so that they match the product architecture.

Multi-level libraries are useful in deployments whose libraries contain a very large number of topics. To help manage library items, a library is split into smaller libraries that are organized hierarchically.

For example, consider a library that includes error messages for your product. Some of these error messages are OS-specific. You could organize them in three libraries, as follows:

Libraries are organized hierarchically in layers, where each layer is associated with a level ID. The level ID indicates at which architecture layer the library is set.

The top-most layer is the level 1 layer. In the sample library structure above, there are two layers: The top layer, Error messages, is at level 1, while the Windows and Linux libraries are at level 2. Lower-level libraries are called child libraries, upper-level libraries are called parent libraries, while libraries that are at the same level are called sibling libraries.

A library inherits content from its child libraries. For example, products that reference the Error messages library will be able to access all the content in the Windows and Linux libraries. However, a library cannot access objects from its parent or sibling libraries; in the example above, products who reference the Windows library only cannot access content that is in the Error messages or Linux library.

Note: Multi-level libraries must be planned carefully as they increase complexity. Consider all aspects of implementing of multi-level libraries and test scenarios thoroughly.

More detailed example: IXIA CCMS Web

The following diagram shows a more detailed implementation of multi-level libraries, using CCMS Web as an example.

Web Library Structure

The DRM product that references a library is always considered to be layer 0. In this example, the Web product references the Web library, which is at the Product Library layer. The Web library uses the Glassfish and Tomcat libraries, which are at the Third-Party Library layer. Each of these libraries uses the Windows and Linux libraries, which are at the Operating System Library layer.

This architecture is summarized in the following table:

Note: In the example below, the first library starts at level 3 to reserve levels for libraries that might need to be at a higher level.

Table 1. Sample use case for multi-layer libraries
Layer level	Name	Examples
3	Product Library	TEXTML Server
6	Third Party Library	Tomcat, Glassfish, Java, oXygen
9	Operating System Library	Windows, Linux, Mac OS

A product can refer to a library at any level. When referring to a library, a product inherits that library as well as all its child libraries.

There is no maximum number of levels. However, try to keep the number of levels to a manageable number to reduce the complexity.

Note: In the initial configuration, a single layer is configured, which means that your deployment will work exactly as it did in previous versions. That is, you will not be able to specify a layer when creating a library, and all your existing libraries will be assigned the default level ("1").