Understanding containers
The DRM implementation is supported by a DITA map specialization called container.
With the DRM module, maps do not contain links to the actual topics. Instead, they contain key references that are resolved by a container file. There is a one-to-one relationship between versions and containers: Each version is associated with a single container and a container is associated with a single version.
In this diagram, MapA contains 4 topics: a concept and three tasks. The map does not reference the topics directly; instead, each topic is defined with a key. MapA also includes a reference to a container, Container_v1, which includes the key definitions. All the maps in a version point to the same container, which has all the key definitions for all the objects in a version.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE bookmap PUBLIC "-//IXIA//DTD IXIA DITA Map//EN" "IxiaMap.dtd">
<bookmap id="lar1403120614675" xml:lang="en-us">
<title>CMS Quick Start</title>
<chapter href="lar1403120714373.xml"/>
<chapter href="lar1403120831656.xml"/>
</bookmap>
In the code above, the map references the actual topic files directly using the href
attribute. With the DRM module, the map does not reference the topics directly. Instead, it specifies the topics to include using key references. To resolve the keys, the map references a container, which contains the key definitions.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE bookmap PUBLIC "-//IXIA//DTD IXIA DITA Map//EN" "IxiaMap.dtd">
<bookmap id="lar1403120614675" xml:lang="en-us">
<title>CMS User Guide</title>
<containerref href="lar1403119327816.ditamap"/>
<chapter keyref="lar1403120714373"/>
<chapter keyref="lar1403120831656"/>
</bookmap>
keyref
instead of being directly referenced with an href
. The key name is always the ID of the object. The map also includes a reference to a container map. The following code shows the container that resolves the key definitions:<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE containerpart PUBLIC "-//IXIA//DTD DITA Container Part//EN" "containerpart.dtd">
<containerpart id="lar1403120655373" xml:lang="en-us">
<title>3.4.0.1 {0001}</title>
<keydefs>
<topicgroup id="Map">
<keydef href="lar1403120614675.ditamap" keys="lar1403120614675" scope="local"/>
</topicgroup>
<topicgroup id="Topic">
<keydef href="lar1403120714373.xml" keys="lar1403120714373" scope="local"/>
<keydef href="lar1403120831656.xml" keys="lar1403120831656" scope="local"/>
</topicgroup>
<topicgroup id="Image"/>
</keydefs>
</containerpart>
Containers and container parts
To simplify the explanation, the section above skipped a step in the chain of files required to resolve the keys. In reality, the maps point to a container, which in turn points to a container part. The container part is the file that contains the actual key definitions, and all the key definitions for a version are contained across several container parts.
The following diagram shows how containers and container parts are defined in the DRM module:
There is a one-to-one relationship between versions and containers: Each version is associated with a single container and a container is associated with a single version. A container can have one or more container parts. Container parts allow projects with many objects to be organized into smaller parts for improved performance and to allow different users to add or remove content in a version simultaneously. By default, a container part holds 1000 objects (configurable).
As shown above, the CMS Quick Start map points to container 3.4.0.1 and includes two keys, one for each topic that it contains. Container 3.4.0.1 references container part 3.4.0.1 0001, which contains the definition for the keys used in the CMS Quick Start map.