Custom DTD shell methods

You might have your own DTD shells that define custom topic or map types, as well as additional domains or constraints. To integrate these into the CCMS, there are two possible methods. The first method involves creation of a custom DTD shell. The second method goes a bit further and involves integration of that custom DTD shell into custom topic and map shells.

Creation of a custom DTD shell

In this first method, you create your own DTD plugin that includes each of these custom files and a catalog file that references each of them. Then, you add that DTD plugin to the CCMS system configuration and reference it in the master-catalog.

If you follow this first method, your integration should include the following:

You may need to integrate the IXIA CCMS localization domain into each custom topic and map DTD.
(DRM only) You need to integrate the IXIA CCMS containerref domain into each of your custom map DTDs. If you have a lot of custom DTDs, this could take a while.
Note: Once you integrate the identified domains, you can use the updated files as the basis for ongoing edits so that you don't lose that work. However, if consultants maintains those DTDs, they might work from a different set of base DTDs and provide you with an updated set of files that do not include the IXIA CCMS domains. If so, you must do the integration with each iteration. You have an ongoing responsibility to synchronize your local changes with the consultant's files.

When you import content, the IXIA CCMS can do one of two things: Keep the content's doctypes as-is OR refactor all imported topics to a single doctype and all imported maps to a single doctype.

If you plan to import content on an ongoing basis and that content does not already have the correct doctype, such as the generic OASIS doctypes, then you must import your content in batches:

Set systemid.xml to use doctypeA as the topic default
Import all the content using doctypeA first, then edit systemid.xml to use doctypeB as the topic default
Import all the content using doctypeB, and so on

Note: If there are dependencies between topics using different doctypes, you must import them together, so this batch import approach will not work for you. Use the alternate integration method.

This limitation is only an issue if the content does not already have the appropriate doctype. If your content for import always has the appropriate doctype, you don't have to refactor it after import.

Integration of your DTDs into custom topic and map shells

This second method has several significant advantages, and is likely to benefit most deployments.

Once you integrate your custom DTDs into your CompanyDitabase.dtd and CompanyMap.dtd, those are the only two files you have to maintain, regardless of if who maintains your DTDs: you or a consultant. In addition, the doctypes for CompanyDitabase.dtd and CompanyMap.dtd are the only two that you ever have to list in systemid.xml.

Upon import, all topics get refactored to the CompanyDitabase.dtd doctype. All maps get refactored to the CompanyMap.dtd doctype. Thus, you can import a large set of content all at once.

Note: Each topic and map still has a unique type so even though they all reference CompanyDitabase.dtd and CompanyMap.dtd, the topic and map type determine what elements, attributes, and structures are available for that type so you still maintain your content specifications.

Overview of DTD shell integration

Before you start integrating custom DTD shells into your topic and map shells, here is a simplified explanation to help you choose which method is best for you. If you want to understand DITA DTDs in more detail, read a few reputable online resources.

You DTD plugin generally contains this set of files, often with the same name, but different extension.

.dtd DTD files that define a topic or map type
.mod model files
.ent entity files

Suppose you specialize a "report" topic type in addition to topic, concept, task, reference, and troubleshooting. Generally, the related files are the report.dtd, report.mod, and report.ent files. There are some exceptions:

Element contraints: Sometimes, there is only a .mod file, which usually indicates an element constraint. Element constraints redefine an element's model to disallow child elements that the generic DITA standard allows, such as CCMS section and paragraph constraints.
Domain constraints: Sometimes, there is only a .ent file, which usually indicates a domain constraint. Domain constraints redefine the highlight domain to allow only <sub> and <sup> and disallow all the other elements in that domain (<b>, <i>, etc.).
Specialized elements: Sometimes, there is only a .mod and .ent file, which typically indicates a set of specialized elements are used in several of your specialized topic or map types. Specialized elements are not actual topic or map types, so they don't have a .dtd file, but the various .dtd files in the set do reference these .mod and .ent files.

When you integrate a set of DTDs into your topic and map shells, your primary concern is the .dtd files. Each .dtd file integrates the necessary default .mod and .ent files, such as the default concept.mod or reference.ent files, as well as the related custom.mod and .ent files.

As you might imagine, there is no one-size-fits-all procedure for this process, since it depends on the nature of the DTDs for integration.