To support extensibility and pluggability, DITA requires that a DTD implementation of structural and domain specialization modules conform to well-defined design patterns.
This section describes those design patterns. These design patterns realize the specialization architecture with the capabilities and within the limitations of the DTD grammar.
Each structural type must be defined in a separate DTD module with a name consisting of the topic element name and the mod extension. To see an example, look at the concepts.mod module for the concept topic type.
The structural type module must conform to the following design pattern.
<!ENTITY % conbody "conbody">
The document type shell can predefine an element entity to add domain specialized elements into every context in which the base element occurs.
<!ENTITY included-domains "">
The document type shell can predefine the included-domains entity to list domains added to the document type.
<!ENTITY % concept-info-types "%info-types;">
The document type shell can then control how topics are allowed to nest by redefining the topictype-info-types entity for each topic type, or quickly create common nesting rules by redefining the main info-types entity.
<!ELEMENT concept ((%title;), (%titlealts;)?, (%shortdesc;)?, (%prolog;)?, (%conbody;), (%related-links;)?, (%concept-info-types;)* )>
<!ATTLIST concept id ID #REQUIRED ... DITAArchVersion CDATA "&DITAArchVersion;" domains CDATA "&included-domains;" >
These attributes give processes a reliable way to check the architecture version and look up the list of domains available in the document type.
In particular, the module defines a class attribute for every specialized element. The class attribute must include the value of the class attribute of the base element and append the element name qualified by the topic element name with at least one leading and trailing space. The class attribute for an element introduces by a structural specialization must start with a minus sign.
Each domain specialization must have two files:
To see an example, look at the highlightDomain.ent and highlightDomain.mod files.
The domain entity declaration file must conform to the following design pattern:
<!ENTITY % hi-d-ph "b | u | i | tt | sup | sub">
<!ENTITY hi-d-att "(topic hi-d)">
The domain definition module conforms to the following design pattern:
<!ENTITY % b "b">
The attribute domain pattern is a special case of the domain specialization pattern, which allows the creation of new attributes specialized from the props or base attribute.
<!ENTITY % newAtt-d-attribute "new CDATA #IMPLIED">
<!ENTITY newAtt-d-att "a(props new)" >
The document type shell must conform to the following design pattern. To see an example, look at the concepts.dtd module for the concept document type.
<!ENTITY % hi-d-dec PUBLIC "-//OASIS//ENTITIES DITA Highlight Domain//EN" "highlightDomain.ent"> %hi-d-dec; <!ENTITY % newAtt-d-dec PUBLIC "-//My Company//ENTITIES new Attribute Domain//EN" "newAttDomain.ent"> %newAtt-d-dec;
<!ENTITY % pre "pre | %pr-d-pre; | %sw-d-pre; | %ui-d-pre;">
<!ENTITY % concept-info-types "concept">
<!ENTITY included-domains "&ui-d-att; &hi-d-att; &pr-d-att; &sw-d-att; &ut-d-att; &newAtt-d-att">
<!ENTITY % topic-type PUBLIC "-//OASIS//ELEMENTS DITA Topic//EN" "topic.mod"> %topic-type;
<!ENTITY % hi-d-def PUBLIC "-//OASIS//ELEMENTS DITA Highlight Domain//EN" "highlightDomain.mod"> %hi-d-def;There are no domain definition files for attribute domains.
Return to main page.
OASIS DITA Version 1.1 Architectural Specification -- Committee Specification, 31 May 2007
Copyright © OASIS Open 2005, 2007. All Rights Reserved.