Customizing DITA 1.3 EDDs

The modular design of the DITA 1.3 EDDs allows easy customization. You can switch off entire domains or remove individual elements. This makes your topic templates fit the needs of your authors.

Remove domains from your EDD

Just like the DITA DTDs, the DITA 1.3 EDDs contains separate modules for each of the included DITA domains. All element definitions in such a domain module are marked as conditional text, using a condition tag that reflects the domain.

To create a valid and consistent customized EDD, use the conditional text expression builder. This utility is available from the Show/Hide Conditional Text panel.

Note: Using the Show and Hide lists will result in an invalid EDD. Also, using the Show All option may not yield a valid and consistent EDD, as there may be conflicting general rules and multiple root elements in each top-level EDD.

The expression for the DITA EDDs must always be of the following form:


("include_1" or "include_2" or ... or "include_n") 
  and not ("exclude_1" or "exclude_2" or ... or "exclude_n")

where include_x are conditions to show and exclude_x are conditions to hide. To remove a currently included domain, remove it from the list of included domains and add it to the list of excluded domains.

Note: All conditions must be mentioned in the expression, either in the include or in the exclude section.

It may be useful to name each build expression with a descriptive name, so that switching between various document shells becomes a matter of selecting the Build Expression from the drop-down list in the Show/Hide Conditional Text panel and clicking Apply.

Note: Applying a build expression may take quite a while. Have patience and do not interrupt the process, as this will result in an invalid EDD.

Remove individual domain elements from your EDD

If you want to keep a domain but exclude a particular element from that domain, you must change the value of the variable in which the element is defined. Each specialized element is only included in one single variable, which carries the name of the domain to which the element belongs plus the base element from which the specialization, was derived. Some examples:

Element	Domain	Variable	Definition
b	hi-d	hi-d-ph	`\|b\|i\|line-through\|overline\|sub\|sup\|tt\|u`
apiname	pr-d	pr-d-keyword	`\|apiname\|option\|parmname`
hazardstatement	hazard-d	hazard-d-note	`\|hazardstatement`

To remove an individual domain element, remove the element with its pipe prefix from the variable definition. If the element is the only one in the definition, change the variable definition to a single whitespace character.

Note: The variable change is immediate. There is no need to re-apply conditions or update the EDD.

As an example, removing the line-through element from your EDD, you must edit the hi-d-ph variable so that it reads |b|i|overline|sub|sup|tt|u. This makes the line-through element unavailable in the entire EDD.

Removing base elements from your EDD

If you want to remove an element that is not part of a domain specialization,, you need to remove it from all the variable definitions in which the element occurs. Use the variables list to determine the variables to be edited. Remove the element with its pipe prefix from the variable definitions. If the element is the only one in the definition, change the variable definition to a single whitespace character.

Note: In some general rules, base elements are included without using variables. To make changes to these rules, you need to convert the text inset(s) in which the element appears before being able to make changes. This is explained in a separate section below.

Removing base elements from the general rules and specifications of context rules does not remove the definition of the base elements from the EDD. When you import the changed EDD into a template, the log will show one or more defined but not referenced elements. This does not affect the validity of your EDD and the defined but not referenced elements will not appear in the element catalog, as they are not valid in any context.

Changing general rules

As all general rules are contained in modules, which are imported into the top-level EDD as text insets, you have a choice of two methods for adapting these general rules:

Change the general rule for the current EDD only
Change the general rule for all applicable EDDs

In the first case, you need to convert the text inset that contains the general rule to plain text. Double-click the text inset to open the Text Inset Properties panel, click the Convert button and choose the option Only this text inset. After this, you can edit the general rule. There is no need to update the EDD after this.

Note: If you choose this option, it is recommended to save the EDD under a different name in a folder that holds all your custom EDDs. This ensures that the original EDD remains available and keeps all your customized EDDs available in the same space.

In the second case, you need to open the module in which the general rule is located. Double-click the text inset to open the Text Inset Properties panel and click the Open button. In the module that opens, edit the general rule and save the module. Then return to the original EDD and update the text inset.

Note: The other EDDs that contain this module should also be opened and the text inset updated before changes take effect. After a text inset update, the current build expression must be re-applied.

Changing or adding context rules

Context rules may mention domain elements, which are not available when the domain is excluded. When creating additional context rules, you must take care that the specification for the new context rule is not empty and does not contain undefined elements.

If a new context rule only applies to elements from a specific domain, mark the entire context rule and apply the condition tag for that domain to it. This ensures that the entire context rule is suppressed when the domain is excluded from the EDD.