Darwin Information Typing Architecture (DITA) Version 1.2

Chapter 2: Architectural specification

The architectural specification provides information about how DITA is designed. It is divided into three sections: Base, technical content, and learning and training.

2.2.1: Architectural Specification: Base

Base DITA includes the topic, map elements, metadata, classification, and specialization elements. It also includes domains for hazard statement, typographic, and utility elements

The base section of the architectural specification contains the following parts:

An introduction, which provides background concepts and an overview of the architecture
The DITA markup section, which provides an overview of DITA topics, DITA maps, and DITA metadata
The DITA processing section, which provides descriptions of common DITA-processing expectations
The configuration, specialization, and constraints section, which provides details of the mechanisms that DITA provides for defining, extending, and constraining DITA document types

2.2.1.1: Introduction to DITA

The Darwin Information Typing Architecture (DITA) is an XML-based architecture for authoring, producing, and delivering topic-oriented, information-typed content that can be reused and single-sourced in a variety of ways. While DITA historically has been driven by the requirements of large-scale technical documentation authoring, management, and delivery, it is a standard that is applicable to any kind of publication or information that might be presented to readers, including interactive training and educational materials, standards, reports, business documents, trade books, travel and nature guides, and more.

DITA is designed for creating new document types and describing new information domains based on existing types and domains. The process for creating new types and domains is called specialization. Specialization enables the creation of very specific, targeted document-type definitions that still can share the common output transformations and design rules developed for more general types and domains; this is similar to how classes in an object-oriented system can inherit the methods of ancestor classes.

Because DITA topics are XML conforming, they can be readily viewed, edited, and validated using standard XML tools, although realizing the full potential of DITA requires using DITA-aware tools.

2.2.1.1.1: About the specification source

The DITA specification is authored as a DITA content set and published using the DITA Open Toolkit. It is an example of a complex document that is developed by a team of people and uses many DITA features, including key references (keyrefs) and content references (conrefs).

As a convenience for readers, the DITA specification is published in several packages which contain different combinations of required and optional modules. The ability to easily define, manage, and publish these packages is a result of using DITA for the specification source. The source files for the DITA specification are managed in a version control repository that is maintained by OASIS; they also can be downloaded from OASIS.

The PDF versions of the DITA specification were built using Antenna House XSL Formatter and RenderX XEP.

Add link to URL where the DITA source can be downloaded.

Update this topic to reflect the following:

Content of official specification overview page
Decisions about packaging that the TC made in February 2010

2.2.1.1.2: DITA terminology and notation

The DITA specification uses specific notation and terms to define the components of the DITA standard.

Notation

The following conventions are used throughout the specification:

attribute types: Attribute names may be preceded by @ to distinguish them from elements or surrounding text, for example, the @props or the @class attribute.
element types: Element names may be delimited with angle brackets (< and >) to distinguish them from surrounding text, for example, the <keyword> and the <prolog> element.

In general, the unqualified use of the term map or topic can be interpreted to mean "a <map> element and any specialization of a <map> element " or "a <topic> element or any specialization of a <topic> element."

Normative and non-normative information

The DITA specification contains normative and non-normative information:

Normative information: Normative information is the formal portion of the specification that describes the rules and requirements that make up the DITA standard and which must be followed.
Non-normative information: Non-normative information includes descriptions that provide background, examples, and other useful information that are not formal requirements or rules that must be followed. The terms non-normative and informative are used interchangeably.

All information in the specification should be considered normative unless it is an example, an appendix, or is explicitly labeled as informative or non-normative. Appendices are always non-normative, unless explicitly stated otherwise. The DITA specification contains examples to help clarify or illustrate specific aspects of the specification. Because examples are specific rather than general, they may not illustrate all aspects or be the only way to accomplish or implement an aspect of the specification. Therefore all examples are non-normative, unless explicitly stated otherwise.

Basic DITA terminology

The following terminology is used to discuss basic DITA concepts:

DITA attribute type

An attribute type that is one of the following:

One of the base attribute types that are defined by the DITA specification
A specialization of the either the @base or @props attribute

DITA document

An XML document that conforms to the requirements of this specification. A DITA document must have as its root element one of the following elements:

<map> or a specialization of the <map> element
<topic> or a specialization of the <topic> element
<dita>, which cannot be specialized, but which allows documents with multiple sibling topics

DITA document type

A unique set of structural modules, domain modules, and constraint modules that taken together provide the XML element and attribute declarations that define the structure of DITA documents. DITA document types normally are implemented using DITA document-type shells.

DITA document-type shell

A set of DTD or XSD declarations that implement a DITA document type by using the rules and design patterns that are included in the DITA specification. A DITA document-type shell includes and configures one or more structural modules, zero or more domain modules, and zero or more constraint modules. With the exception of the optional declarations for the <dita> element and its attributes, DITA document-type shells do not declare any element or attribute types directly.

DITA element

An XML element instance whose type is a DITA element type. DITA elements must exhibit a @class attribute that has a value that conforms to the rules for specialization hierarchy specifications.

DITA element type

An element type that is one of the following:

One of the base element types that are defined by the DITA specification
A specialization of one of the base element types

A DITA element type is declared in exactly one vocabulary module. DITA element types may only exhibit attributes that are DITA attribute types.

map instance

An occurrence of a map type in a document.

map type

An element type that defines a set of relationships among topic instances. The map type provides the root element and, through the contained element types, the substructure for the map instances. The map substructure provides hierarchy, group, and matrix organization of references to topic instances.

structural type instance

An occurrence of a topic type or a map type in a document.

topic instance

An occurrence of a topic type in a document.

topic type

An element type that defines a complete unit of content. The topic type provides the root element for the topic and, through the contained element types, the substructure for the topic instances. The root element of the topic type is not necessarily the same as the root element of a document type; document types may nest multiple topic types and may also declare non-DITA wrapper elements as the root element for compatibility with other processes.

Specialization terminology

The following terminology is used to discuss DITA specialization:

base content model

The content model of a DITA element before specialization or the application of constraints or extensions.

base type

An element or attribute type that is not a specialization. All base types are defined by the DITA specification.

extension element

Within a vocabulary module, an element type that can be extended, replaced, or constrained for use in a DITA document type.

generalization

The process by which a specialized element is transformed into a less-specialized ancestor element or a specialized attribute is transformed into a less-specialized ancestor attribute. The original specialization-hierarchy information may be preserved in the generalized instance, thus allowing the original specialized type to be recreated from the generalized instance.

restricted content model

For a DITA element type, a content model that has been restricted from the base content model for the element type by one or more of the following mechanisms:

Removing optional elements
Requiring optional elements
Ordering of unordered elements
Restricting repeatable (but optional) elements from repeating

Content models may be restricted through the use of constraint modules or through specialization.

selective domain extension

An extension that replaces an extension element with element types that are defined in an domain module, thus making the base type unavailable in the DITA document-type shell that configures the extension.

specialization

(1) The act of defining new element or attribute types as a semantic refinement of existing element or attribute types

(2) An element or attribute type that is a specialization of a base type

(3) A process by which a generalized element is transformed into one of its more specialized element types or a generalized attribute is transformed into a more specialized attribute.

specialization hierarchy

The sequence of element or attribute types, from the most general to most specialized, from which a given element or attribute type is specialized. The specialization hierarchy for a DITA element is formally declared through its @class attribute.

specialization parent

For a given DITA element type, the most specialized of its ancestors in its specialization hierarchy.

specialized attribute type

An attribute type that is defined as a semantic refinement of another attribute type. The attribute type must be specialized from either the @base or @props attribute, and its range of permissible values must be a subset of or identical to the values allowed by the original attribute type.

specialized element type

An element type that is defined as a semantic refinement of an existing element type. The content allowed by the specialized element type must be a subset of or identical to the content allowed by the original element type. Within a DITA document, all specialized element types must be refinements of one of the base element types, with the exception of elements that are used in the context of <foreign> or <unknown> elements.

structural type

A topic type or map type.

DITA modules

The following terminology is used to discuss DITA modules:

attribute domain module: A domain module that defines exactly one specialization of either the @base or @props attribute.
constraint module: A set of declarations that imposes additional constraints onto the element or attribute types that are defined in a specific vocabulary module.
domain module: A set of element types or an attribute type that supports a specific subject or functional area. Element types or attribute types in a domain can be integrated with topic types or map types to enhance semantic support for particular kinds of content. For example, the structural type <topic> declares the <keyword> element; when integrated with a domain for describing user interfaces, new keyword specializations (such as <wintitle>) become available wherever <keyword> was allowed in the original structural type.
element domain module: A domain module that defines one or more element types for use within maps or topics.
map module: A structural module that defines a single map type.
structural module: A vocabulary module that defines exactly one top-level map type or topic type. Structural modules may also define specializations of elements from domain modules.
topic module: A structural module that defines a single top-level topic type.
vocabulary module: A uniquely-named unit of element type or attribute type declaration. There are two types of vocabulary modules: structural modules and domain modules. For a given map type, topic type, or domain, there is exactly one vocabulary module that defines it.

The following figure illustrates the relationship between a DITA document, its DITA document-type shell, and the various vocabulary modules that it uses.

Instances, modules, and declarations

Shows the relationship between a DITA document, its DITA document-type shell, and the various document-type modules that it uses.

Linking and addressing terms

The following terminology is used to discuss linking and addressing terms:

key name

An identifier defined by a value of the @keys attribute. A key is bound to one or more of the following items:

A resource addressed by the <topicref> element or a specialization of the <topicref> element
An element contained with the <topicmeta> element of the <topicref> element or a specialization of the<topicref> element

key definition

A <topicref> element or specialization of a <topicref> element that specifies the @keys attribute and defines one or more key names.

key resolution context

The root map that establishes the context for resolving key references. For a given key-resolution instance, there is at most one root map that defines the effective value of the key space, as determined by the key definition precedence rules..

key space

The effective set of unique key names that are defined by a given key resolution context. Within a given key resolution context, a key name has at most one binding.

referenced element

An element that is referenced by another DITA element. See also referencing element.

Example

The following code sample is from the installation-reuse.dita topic. The <step> element that it contains is a referenced element; other DITA topics reference the <step> element by using the @conref attribute.

<step id="run-startcmd-script">
	<cmd>Run the startcmd script that is applicable to your operating-system environment.</cmd>
</step>

referencing element

An element that references another DITA element by specifying an addressing attribute. See also referenced element and addressing attribute

Example

The following <step> element is a referencing element. It uses the @conref attribute to reference a <step> element in the installation-reuse.dita topic.

<step conref="installation-reuse.dita#reuse/run-startcmd-script>
	<cmd/>
</step>

addressing attribute

An attribute, such as @conref, @conkeyref, @keyref, and @href, that specifies an address (a URI reference or a key reference).

2.2.1.1.3: Basic concepts

DITA has been designed to satisfy requirements for information typing, semantic markup, modularity, reuse, interchange, and production of different deliverable forms from a single source. These topics provide an overview of the key DITA features and facilities that serve to satisfy these requirements.

DITA topics: In DITA, a topic is the basic unit of authoring and reuse. All DITA topics have the same basic structure: a title and, optionally, a body of content. Topics can be generic or more specialized; specialized topics represent more specific information types or semantic roles, for example, <concept>, <task>, <reference>, or <learningContent>. See DITA topics for more information.
DITA maps: DITA maps are documents that organize topics and other resources into structured collections of information. DITA maps specify hierarchy and the relationships among the topics; they also provide the context in which keys are defined and resolved. DITA maps should have .ditamap file extensions. See DITA maps for more information.
Information typing: Information typing is the practice of identifying types of topics, such as concept, reference, and task, to clearly distinguish between different types of information. Topics that answer different reader questions (How ...? What is ...?) can be categorized with different information types. The base information types provided by DITA specializations (i.e., technical content, machine industry, and learning and training) provide starter sets of information types that can be adopted immediately by many technical and business-related organizations. See Information typing for more information.
DITA linking: DITA depends heavily on links. The purposes for which it provides links include defining the content and organization of publication structures (DITA maps), topic-to-topic navigation links and cross references, and reuse of content by reference. All DITA links use the same addressing facilities, either URI-based addresses or DITA-specific indirect addresses using keys and key references. See DITA linking for more information.
DITA addressing: DITA provides a number of facilities for establishing relationships among DITA elements and between DITA elements and non-DITA resources. All DITA relationships use the same addressing facilities irrespective of the semantics of the relationship established. DITA addresses are either direct, URI-based addresses, or indirect key-based addresses. Within DITA documents, individual elements are addressed by unique IDs specified on the common @id attribute. DITA defines two fragment identifier syntaxes for addressing DITA elements, one for topics and elements within maps and one for non-topic elements within topics. See DITA addressing for more information.
Content reuse: The DITA @conref, @conkeyref, @conrefend, and related attributes provide a mechanism for reuse of content fragments within DITA topics or maps. See Content reuse for more information
Conditional processing: Attribute-based profiling, also known as conditional processing or applicability, is the use of classifying metadata that enables the filtering, flagging, searching, indexing, and other processing based on the association of an element with one or more values in a specific classification domain. See Conditional processing for more information.
Configuration: A given DITA map or topic document is governed by a DITA document type that defines the set of structural modules (topic or map types), domain modules, and constraints modules that the map or topic can use. See Configuration for more information.
Specialization: The specialization feature of DITA allows for the creation of new element types and attributes that are explicitly and formally derived from existing types. The resulting specialization allows for the blind interchange of all conforming DITA content and a minimum level of common processing for all DITA content. It also allows specialization-aware processors to add specialization-specific processing to existing base processing. See Specialization for more information.
Constraints: Constraint modules define additional constraints for corresponding vocabulary modules in order to restrict content models or attribute lists for specific element types, remove extension elements from an integrated domain module, or replace base element types with domain-provided extension element types. Constraint modules do not and cannot change element semantics, only the details of how element types can be used in the context of a specific concrete document type. Because constraints can make optional elements required, documents that use the same vocabulary modules may still have incompatible constraints. Thus the use of constraints can affect the ability for content from one topic or map to be used directly in another topic or map. See Constraints for more information.

2.2.1.1.4: File naming conventions

DITA uses certain naming conventions and file extension for topics, maps, modules, and document-type implementation files.

Files that contain DITA content should use the following naming conventions:

DITA topics

*.dita (recommended)
*.xml

DITA maps

*.ditamap

Conditional processing profiles

profilename.ditaval

Files that define DITA document-type components must use the following naming conventions:

Document-type shell files

typename.dtd
typename.xsd

Where typename is the name of the intended root topic or map type defined by the document type shell or, as needed, a name that clearly identifies both the intended root map or topic type and distinguishes the document type shell from other shells for the same root type.

Note

For example, the OASIS-provided document-type shells for technical content include two different document-type shells for the task topic type: task.dtd and generalTask.dtd, where task.dtd includes the strict task body constraint module and generalTask.dtd does not.

DTD structural module files

typename.mod
typename.ent

DTD domain module files

typenameDomain.mod
typenameDomain.ent

DTD constraint module files

constraintnameConstraint.mod

Schema structural module files

typenameMod.xsd
typenameGrp.xsd

Schema domain module files

typenameDomain.xsd

Schema constraint module files

constraintnameConstraintMod.xsd
constraintnameConstraintIntMod.xsd

2.2.1.1.5: Producing different deliverables from a single source

DITA is designed to produce multiple deliverable formats from a single set of DITA content. This means that many rendition details are specified neither in the DITA specification nor in the DITA content; the rendition details are defined and controlled by the processors.

This topic was removed from the "Introduction to DITA" section. We need to ensure that all relevant content in this topic is covered in the applicable section.

Like many XML-based applications for human-readable documentation, DITA supports the separation of content from presentation. This is necessary when content is used in different contexts, since authors cannot predict how or where the material that they author will be used. The following features and mechanisms enable users to produce different deliverable formats from a single source:

DITA maps: Different DITA maps can be optimized for different delivery formats. For example, you might have a book map for printed output and another DITA map to generate online help; each map uses the same content set.
Specialization: The DITA specialization facility enables users to create the XML elements needed by a particular information set in order to provide appropriate rendition distinctions. In XML-based systems where presentation details are defined as styles bound to elements, the more precise and detailed the markup, the easier it is to define presentation rendering. Because the use of arbitrary specializations does not impede interchange or interoperability, DITA users can safely create the specializations demanded by their local delivery and rendition requirements, with a minimum of additional impact on the systems and business processes that depend on or use the content. While general XML practices suggest that element types should be semantic, specialization can be used to define element types that are purely presentational in nature. The highlighting domain is an example of such a specialization.
Conditional processing: Conditional processing makes it possible to have a topic or DITA map that contains delivery-specific content.
Content referencing: The conref mechanism makes it possible to construct delivery-specific maps or topics from a combination of generic components and delivery-context-specific components.
Key referencing: The keyref mechanism makes it possible to change variables for volatile content, redirect links, and reap the benefits of indirect addressing.
@outputclass attribute: The @outputclass attribute provides a mechanism whereby authors can indicate specific rendition intent where necessary. Note that the DITA specification does not define any values for the @outputclass attribute; the use of the @outputclass attribute is, by nature, processor specific.

While DITA is independent of any particular delivery format, it is a standard that supports the creation of human-readable content. As such, it defines some fundamental document components including paragraphs, lists, and table. When there is a reasonable expectation that such basic document components be rendered consistently, the DITA specification defines default or suggested renderings.

2.2.1.2: DITA markup

Topics and maps are the basic building blocks of the Darwin Information Typing Architecture (DITA). Metadata attributes and values can be added to DITA topics and maps, as well as to elements within topics, to allow for conditional publishing and content reuse.

DITA topics and maps are XML documents that conform to the XML specification. As such, they can be viewed, edited, validated, and processed with standard XML tools, although some DITA-specific features, such as content reference, key reference, and specialization require DITA-specific processing for full implementation and validation.

2.2.1.2.1: DITA topics

DITA topics are the basic units of DITA content and the basic units of reuse. Each topic contains a single subject. Topics may be of specific specialized information types, such as task, concept, or reference, or may be generic, that is, without a specified information type.

2.2.1.2.1.1: The topic as the basic unit of information

In DITA, a topic is the basic unit of authoring and reuse. All DITA topics have the same basic structure: a title and, optionally, a body of content. Topics can be generic or more specialized; specialized topics represent more specific information types or semantic roles, for example, <concept>, <task>, <reference>, or <learningContent>.

DITA topics consist of content units that can be as generic as sets of paragraphs and unordered lists or as specific as sets of instructional steps in a procedure or cautions to be considered before a procedure is performed. Content units in DITA are expressed using XML elements and can be conditionally processed using metadata attributes and values.

Classically, a DITA topic is a titled unit of information that can be understood in isolation and used in multiple contexts. It should be short enough to address a single subject or answer a single question but long enough to make sense on its own and be authored as a self-contained unit. However, DITA topics also can be less self-contained units of information, such as topics that contain only titles and short descriptions and serve primarily to organize subtopics or links or topics that are designed to be nested for the purposes of information management, authoring convenience, or interchange.

DITA topics are used as components of DITA maps. DITA maps enable topics to be organized in a hierarchy for publication. Large units of content, such as complex reference documents or book chapters, are created by nesting topic references in a DITA map. The same set of DITA topics can be used in any number of maps.

DITA topics also can be used and published individually; for example, one can represent an entire deliverable as a single DITA document that consists of a root topic and nested topics. This strategy can accommodate the migration of legacy content that is not topic-oriented; it also can accommodate information that is not meaningful outside the context of a parent topic. However, the power of DITA is most fully realized by storing each DITA topic in a separate XML document and using DITA maps to organize how topics are combined for delivery. This enables a clear separation between how topics are authored and stored and how topics are organized for delivery.

2.2.1.2.1.2: The benefits of a topic-based architecture

Topics enable the development of usable and reusable content.

While DITA does not require the use of any particular writing practice, the DITA architecture is designed to support authoring, managing, and processing of content that is designed to be reused. Although DITA provides significant value even when reuse is not a primary requirement, the full value of DITA is realized when content is authored with reuse in mind. To develop topic-based information means creating units of standalone information that are meaningful with little or no surrounding context.

By organizing content into topics that are written to be reusable, authors can achieve several goals:

Content is readable when accessed from an index or search, not just when read in sequence as part of an extended narrative. Since most readers do not read technical and business-related information from beginning to end, topic-oriented information design ensures that each unit of information can be read independently.
Content can be organized differently for online and print delivery. Authors can create task flows and concept hierarchies for online delivery and create a print-oriented hierarchy to support a narrative content flow.
Content can be reused in different collections. Since a topic is written to support random access (as by search), it should also be understandable when included as part of various product deliverables. Topics permit authors to refactor information as needed, including only the topics that apply to each unique scenario.
Content is more manageable in topic form whether managed as individual files in a traditional file system or as objects in a content management system.
Content authored in topics can be translated and updated more efficiently and less expensively than information authored in larger or more sequential units.
Content authored in topics can be filtered more efficiently, encouraging the assembly and deployment of information subsets from shared information repositories.

Topics written for reuse should be small enough to provide opportunities for reuse but large enough to be coherently authored and read. Since each topic is written to address a single subject, authors can organize a set of topics logically and achieve an acceptable narrative content flow.

2.2.1.2.1.2.1: Disciplined, topic-oriented writing

Topic-oriented writing is a disciplined approach to writing that emphasizes modularity and reuse of concise units of information: topics. Well-designed DITA topics can be reused in many contexts, as long as writers are careful to avoid unnecessary transitional text.

Conciseness and appropriateness

Readers who are trying to learn or do something quickly appreciate information that is written in a structure that is easy to follow and contains only the information needed to complete that task or grasp a fact. Recipes, encyclopedia entries, car repair procedures--all serve up a uniquely focused unit of information. The topic contains everything required by the reader.

Locational independence

A well-designed topic is reusable in other contexts to the extent that it is context free, meaning that it can be inserted into a new document without revision of its content. A context-free topic avoids transitional text. Phrases like "As we considered earlier ..." or "Now that you have completed the initial step ..." make little sense if a topic is reused in a new context in which the relationships are different or no longer exist. A well-designed topic reads appropriately in any new context because the text does not refer the reader outside the topic.

Navigational independence

Most print publications or web pages are a mixture of content and navigation. Internal links lead a reader through a sequence of choices as he or she navigates through a website. DITA supports the separation of navigation from content by assembling independent topics into DITA maps. Nonetheless, writers may want to provide links within a topic to additional topics or external resources. DITA does not prohibit such linking within individual topics. The DITA relationship table enables links between topics and to external content. Since it is defined in the DITA map, it is managed independently of the topic content.

Links in the content are best used for cross-references within a topic. Links from within a topic to additional topics or external resources should be avoided because they limit the reusability of the topic. To link from a term or keyword to its definition, use the DITA keyref facility to avoid creating topic-to-topic dependencies that are difficult to maintain. See Key-based addressing.

2.2.1.2.1.2.2: Transitional text solutions

Topic orientation does not mean that transitions cannot be authored in DITA. The key to providing both locational independence and intentional sequences is the adroit use of DITA markup features.

The print attribute on the topicref element includes the value, "printonly", which may be used to indicate that the topic be omitted when the DITA map is transformed to a format for which transitions are unnecessary. Consequently, a topic designated as "printonly" may be written in any style that serves as a transitional topic in the flow of printed information.

You can also use conditional text to insert transitional sequences into a map so that you can include or exclude the content of short descriptions or paragraphs at the end of a topic. However, if you share conditionally marked topics with other business partners or teams, you must instruct them on the proper runtime settings to enable the conditions to be used the way you intended.

DITA does not preclude authoring transitional text; it does provide an environment that allows you to tag and manage transitional elements apart from surrounding, topic-encapsulated information.

2.2.1.2.1.3: Information typing

Information typing is the practice of identifying types of topics, such as concept, reference, and task, to clearly distinguish between different types of information. Topics that answer different reader questions (How ...? What is ...?) can be categorized with different information types. The base information types provided by DITA specializations (i.e., technical content, machine industry, and learning and training) provide starter sets of information types that can be adopted immediately by many technical and business-related organizations.

Information typing has a long history of use in the technical documentation field to improve information quality. It is based on extensive research and experience, including Robert Horn's Information Mapping and Hughes Aircraft's STOP (Sequential Thematic Organization of Proposals) technique. Note that many DITA topic types are not necessarily closely connected with traditional Information Mapping.

Information typing is a practice designed to keep documentation focused and modular, thus making it clearer to readers, easier to search and navigate, and more suitable for reuse. Classifying information by type helps authors perform the following tasks:

Develop new information more consistently
Ensure that the correct structure is used for closely related kinds of information (retrieval-oriented structures like tables for reference information and simple sequences of steps for task information)
Avoid mixing content types, thereby losing reader focus
Separate supporting concept and reference information from tasks, so that users can read the supporting information if needed and ignore if it is not needed
Eliminate unimportant or redundant detail
Identify common and reusable subject matter

DITA currently defines a small set of well-established information types that reflects common practices in certain business domains, for example, technical communication and instruction and assessment. However, the set of possible information types is unbounded. Through the mechanism of specialization, new information types can be defined as specializations of the base topic type (<topic>) or as refinements of existing topics types, for example, <concept>, <task>, <reference>, or <learningContent>.

You need not use any of the currently-defined information types. However, where a currently defined information type matches the information type of your content, the currently defined information type should be used, either directly, or as a base for specialization. For example, information that is procedural in nature should use the task information type or a specialization of task. Consistent use of established information types helps ensure smooth interchange and interoperability of DITA content.

2.2.1.2.1.4: Generic topics

The element type <topic> is the base topic type from which all other topic types are specialized. All topics have the same basic structure.

For authors, typed content is preferred to support consistency in writing and presentation to readers. The generic topic type should only be used if authors are not trained in information typing or when a specialized topic type is inappropriate. The OASIS DITA standard provides several specialized topic types, including concept, task, and reference that are critical for technical content development.

For those pursuing specialization, new specialized topic types should be specialized from appropriate ancestors to meet authoring and output requirements.

2.2.1.2.1.5: Topic structure

All topics have the same basic structure, regardless of topic type: title, description or abstract, prolog, body, related links, and nested topics.

All DITA topics must have an XML identifier (the @id attribute) and a title. The basic topic structure consists of the following parts, some of which are optional:

Topic element: The topic element holds the required @id attribute and contains all other elements.
Title: The title contains the subject of the topic.
Alternate titles: Titles specifically for use in navigation or search. When not provided, the base title is used for all contexts.
Short description or abstract: A short description of the topic or a longer abstract with an embedded short description. The short description may be used both in topic content (as the first paragraph), in generated summaries that include the topic, and in links to the topic. Alternatively, the abstract lets you create more complex introductory content and uses an embedded short description element to define the part of the abstract that is suitable for summaries and link previews.; While short descriptions aren't required, they can make a dramatic difference to the usability of an information set and should generally be provided for all topics.
Prolog: The prolog is the container for topic metadata, such as change history, audience, product, and so on.
Body: The topic body contains the topic content: paragraphs, lists, sections, and other content that the information type permits.
Related links: Related links connect to other topics. When an author creates a link as part of a topic, the topic becomes dependent on the other topic being available. To reduce dependencies between topics and thereby increase the reusability of each topic, authors may use DITA maps to define and manage links between topics, instead of embedding links directly in each related topic.
Nested topics: Topics can be defined inside other topics. However, nesting requires special care because it can result in complex documents that are less usable and less reusable. Nesting may be appropriate for information that is first converted from desktop publishing or word processing files or for topics that are unusable independent from their parent or sibling topics.; The rules for topic nesting can be configured in a document-type shells. For example, the standard DITA configuration for concept topics only allows nested concept topics. However, local configuration of the concept topic type could allow other topic types to nest or disallow topic nesting entirely. In addition, the @chunk attribute enables topics to be equally re-usable regardless of whether they are separate or nested. The standard DITA configuration for ditabase document-type documents allows unrestricted topic nesting and may be used for holding sets of otherwise unrelated topics that hold re-usable content. It may also be used to convert DITA topics from non-DITA legacy source without first determining how individual topics should be organized into separate XML documents.

2.2.1.2.1.6: Topic content

The content of all topics, regardless of topic type, is built on the same common structures.

Topic body: The topic body contains all content except for that contained in the title or the short description/abstract. The topic body may be specialized to impose constraints appropriate for the specific topic type even when titles and prolog are generic, or the topic body may be generic where the topic title and prolog are specialized.
Sections and examples: The body of a topic may contain divisions, such as sections and examples. They may contain block-level elements like titles and paragraphs and phrase-level elements like API names or text. It is recommend that sections have titles, whether they are entered directly into the title element or rendered using a fixed or default title.; Either body divisions or untitled sections or examples may be used to delimit arbitrary structures within a topic body. However, body divisions may nest, but sections and examples cannot contain sections.
Sectiondiv: Sectiondiv allows for the arbitrary grouping of content within a section for the purpose of content reuse. The sectiondiv does not include a title. Content that requires a title should use section or example.
Bodydiv: Bodydiv allows for the arbitrary grouping of content within the body of a topic for the purpose of content reuse. The bodydiv does not include a title. Content that requires a title should use section or example.
Block-level elements: Paragraphs, lists, and tables are types of "block" elements. As a class of content, they can contain other blocks, phrases, or text, though the rules vary for each structure.
Phrases and keywords: Block-level elements can contain markup to label parts of a paragraph or parts of a sentence as having special semantic meaning or presentation characteristics, such as <uicontrol> or <b>. Phrases can usually contain other phrases and keywords as well as text. Keywords can only contain text.
Images: Images can be inserted to display photos, illustrations, screen captures, diagrams, and the like. At the phrase level, they can display trademark characters, icons, toolbar buttons, and the like.
Multimedia: With the object element, multimedia information may be added to display, for example, diagrams that can be rotated and expanded. With the <foreign> element, media may be included within topic content, e.g., SVG graphics, MathML equations, and so on.

2.2.1.2.1.7: Topic domains: Basic DITA

A DITA vocabulary domain defines a set of elements associated with a particular subject area or authoring requirement regardless of topic type. DITA incorporates three domains into the basic DITA content: typographic, utilities, and indexing. Other domains are incorporated into the DITA Technical Content and Learning and Training specializations.

The elements in a domain are defined in a domain module. A domain module can be integrated with a topic type to make the domain elements available within the topic type structure. The following domains are provided as part of basic DITA:

DITA topic domains: Basic DITA

Domain	Description	Short name	Module name
Typographic	For highlighting when the appropriate semantic element doesn't exist yet	hi-d	highlightDomain.mod (DTD) highlightDomain.xsd (Schema)
Utilities	For providing imagemaps and other useful structures	ut-d	utilitiesDomain.mod (DTD) utilitiesDomain.xsd (Schema)
Indexing	For extended indexing functions such as see and see-also	indexing-d	indexingDomain.mod (DTD) indexingDomain.xsd (Schema)

2.2.1.2.2: DITA maps

This topic collection contains information about DITA maps and the purposes that they serve. It also includes high-level information about DITA map elements, attributes, and metadata.

2.2.1.2.2.1: Definition of DITA maps

DITA maps are documents that organize topics and other resources into structured collections of information. DITA maps specify hierarchy and the relationships among the topics; they also provide the context in which keys are defined and resolved. DITA maps should have .ditamap file extensions.

Maps draw on a rich set of existing best practices and standards for defining information models, such as hierarchical task analysis. They also support the definition of non-hierarchical relationships, such as matrices and groups, which provide a set of capabilities that has similarities to Resource Description Framework (RDF) and ISO topic maps.

DITA maps use <topicref> elements (or specializations of the <topicref> element) to reference DITA topics, DITA maps, and non-DITA resources, for example, HTML and TXT files. The <topicref> elements can be nested or grouped to create relationships between the referenced topics, maps, and non-DITA files; the <topicref> elements can be organized into hierarchies in order to represent a specific order of navigation or presentation.

DITA maps impose an architecture on a set of topics. Information architects can use DITA maps to specify what DITA topics are needed to support a given set of user goals and requirements; the sequential order of the topics; and the relationships that exist among those topics. Because DITA maps provide this context for topics, the topics themselves can be relatively context-free; they can be used and reused in multiple different contexts.

DITA maps often represent a single deliverable, for example, a specific Web site, a printed publication, or the online help for a product. DITA maps also can be subcomponents for a single deliverable, for example, a DITA map might contain the content for a chapter in a printed publication or the troubleshooting information for an online help system. The DITA specification provides specialized map types; book maps represent printed publications, subject scheme maps represent taxonomic or ontological classifications, and learning maps represent formal units of instruction and assessment. However, these map types are only a starter set of map types reflecting well-defined requirements.

DITA maps establish relationships through the nesting of <topicref> elements and the application of the @collection-type attribute. Relationship tables may also be used to associate topics with each other based on membership in the same row; for example, task topics can be associated with supporting concept and reference topics by placing each group in cells of the same row. During processing, these relationships can be rendered in different ways, although they typically result in lists of "Related topics" or "For more information" links. Like many aspects of DITA, the details about how such linking relationships are presented is determined by the DITA processor.

DITA maps also define keys and provide the context in which key references are resolved. A <topicref> element (or specialized <topicref> such as <keydef>) may be used to define a key which binds that key name to a specified resource.

2.2.1.2.2.2: Purpose of DITA maps

DITA maps enable the scalable reuse of content across multiple contexts. They can be used by information architects, writers, and publishers to plan, develop, and deliver content.

DITA maps support the following uses:

Defining an information architecture

Maps can be used to define the topics that are required for a particular audience, even before the topics themselves exist. DITA maps can aggregate multiple topics for a single deliverable.

Defining what topics to build for a particular output

Maps reference topics that are included in output processing. Information architects, authors, and publishers can use maps to specify a set of topics that are processed at the same time, instead of processing each topic individually. In this way, a DITA map can serve as a manifest or bill of materials.

Defining navigation

Maps can define the online navigation or table of contents for a deliverable.

Defining related links

Maps define relationships among the topics they reference. These relationships are defined by the nesting of elements in the DITA map, relationship tables, and the use of elements on which the @collection-type attribute is set. On output, these relationships might be expressed as related links or the hierarchy of a table of contents (TOC).

Defining an authoring context

The DITA map can define the authoring framework, providing a starting point for authoring new topics and integrating existing ones.

Defining keys

Maps can define keys, which provide an indirect addressing mechanism that enhances portability of content. The keys are defined by <topicref> elements or specialization of <topicref> elements, such as <keydef>. The <keydef> element is a convenience element; it is a specialized type of a <topicref> element with the following attributes:

A required @keys attribute
A @processing-role attribute with a default value of "resource-only".

Maps also are the context for resolving key-based references, such as elements that specify the @keyref or @conkeyref attribute.

Specialized maps can provide additional semantics beyond those of organization, linking, and indirection. For example, the subjectScheme map specialization adds the semantics of taxonomy and ontology definition.

2.2.1.2.2.3: DITA map elements

A DITA map describes the relationships among a set of DITA topics. The DITA map and map group elements organize topics into hierarchies, groups, and relationships; they also define keys.

Map and map group elements

A DITA map is composed of the following elements:

map

The <map> element is the root element of the DITA map.

topicref

The <topicref> elements are the basic elements of a map. A <topicref> element can reference a DITA topic, a DITA map, or any non-DITA resource. A <topicref> element also can have a title, short description, and the same kind of prolog-level metadata that is available in topics.

The <topicref> elements can be nested to create a hierarchy, which can be used to define a table of contents (TOC) for print output, online navigation, and parent/child links. Hierarchies can be annotated using the @collection-type attribute to define a particular type of relationship, such as a set of choices, a sequence, or a family. These collection types can affect link generation, and they may be interpreted differently for different outputs.

reltable

Relationship tables are defined with the <reltable> element. Relationship tables can be used to define relationships between DITA topics or between DITA topics and non-DITA resources. In a relationship table, the columns define common attributes, metadata, or information type (for example, task or troubleshooting) for the resources referenced in that column. The rows define relationships between the resources referenced in different cells of the same row.

The <relrow>, <relcell>, <relheader>, and <relcolspec> elements are used to define the components of the relationship table. Relationships defined in the relationship table also can be further refined by using the @collection-type attribute.

topicgroup

The <topicgroup> element defines a group or collection outside of a hierarchy or relationship table. It is a convenience element that is equivalent to a <topicref> element with no @href attribute or navigation title. Groups can be combined with hierarchies and relationship tables, for example, by including a <topicgroup> element within a set of siblings in a hierarchy or within a table cell. The <topicref> elements so grouped can then share inherited attributes and linking relationships with no effect on the navigation or table of contents.

topicmeta

Most map-level elements, including the map itself, can contain metadata inside the <topicmeta> element. Metadata typically is applied to the element and its descendants.

topichead

The <topichead> element provides a navigation title; it is an convenience element that is equivalent to a <topicref> element with a navigation title but no @href attribute.

anchor

The <anchor> element provides an integration point that another map can reference in order to insert its navigation into the current navigation tree. For those familiar with Eclipse help systems, this serves the same purpose as the <anchor> element in that system. It may not be supported for all output formats.

navref

The <navref> element represents a pointer to another map which should be preserved as a transcluding link rather than resolved. Output formats that support such linking will integrate the referenced resource when displaying the referencing map to an end user.

keydef

Enables authors to define keys. This element is a convenience element; it is a specialization of <topicref> that sets the default value of the @processing-role attribute to resource-only. Setting the @processing-role attribute to resource-only ensures that the resource referenced by the key definition is not directly included in the navigation that is defined by the map that includes the key definition.

mapref

Enables authors to reference an entire DITA map, including hierarchy and relationship tables. This element is a convenience element; it is a specialization of <topicref> that sets the default value of the @format attribute to ditamap. The <mapref> element represents a reference from a parent map to a subordinate map.

topicset

Enables authors to define a branch of navigation in a DITA map so that it can be referenced from another DITA map.

topicsetref

Enables authors to reference a navigation branch that is defined in another DITA map.

anchorref

Enables authors to define a map fragment that is pushed to the location defined by an anchor.

Example of a simple map with a relationship table

The following example contains the markup for a simple relationship table:

<map>
...
<reltable>
  <relheader>
    <relcolspec type="concept"/>
    <relcolspec type="task"/>
    <relcolspec type="reference"/>
  </relheader>
  <relrow>
    <relcell>
      <topicref href="A.dita"/>
    </relcell>
    <relcell>
      <topicref href="B.dita"/>
    </relcell>
    <relcell>
      <topicref href="C1.dita"/>
      <topicref href="C2.dita"/>
    </relcell>
  </relrow>
</reltable>
</map>

A DITA-aware tool might represent the <reltable> graphically:

type="concept"	type="task"	type="reference"
A	B	C1 C2

When the output is generated, the topics contain the following linkage:

A: Links to B, C1, and C2
B: Links to A, C1, and C2
C1, C2: Links to A and B

Example of a simple map that defines keys

The following example illustrates how keys can be defined:

<map>
	<keydef keys="dita-tc" href="dita_technical_committee.dita"/>
	<keydef keys="dita-adoption" href="dita_adoption_technical_committee.dita"/>
	...
</map>

The map also could be tagged in either of the following ways:

<topicref> element with @processing-role attribute set to "resource-only"

<map>
	<topicref keys="dita-tc" href="dita_technical_committee.dita" processing-role="resource-only"/>
	<topicref keys="dita-adoption" href="dita_adoption_technical_committee.dita" processing-role="resource-only"/>
	...
</map>

<topicref> element with @toc, @linking, and @search attributes set to "no"

<map>
	<topicref keys="dita-tc" href="dita_technical_committee.dita" toc="no" linking="no" search="no"/>
	<topicref keys="dita-adoption" href="dita_adoption_technical_committee.dita" toc="no" linking="no" search="no"/>
	...
</map>

Example added based on review #1 comment from Elliot Kimber. Exactly what do we want to communicate in this example?

Best practices for key definitions: Using a separate map, defining keys at beginning of map, etc.?
First key encountered is used?
That <keydef> is equivalent to <topicref processing-role="resource-only"> or setting @toc, @linking, and @search attributes to "no"?

Should the example include more information about why the keys are defined and how they would be resolved?

Example of a simple map that references another map

The following code sample illustrates how a DITA map can reference another DITA map:

<map>
	<title>DITA work at OASIS</title>
	<topicref href="oasis-dita-technical-committees.dita>
		<topicref href="dita_technical_committee.dita"/>
		<topicref href="dita_adoption_technical_committee.dita/>
	</topicref>
<mapref href"oasis-processes.ditamap"/>
...
</map>

The map also could be tagged in the following way:

<map>
	<title>DITA work at OASIS</title>
	<topicref href="oasis-dita-technical-committees.dita>
		<topicref href="dita_technical_committee.dita"/>
		<topicref href="dita_adoption_technical_committee.dita/>
	</topicref>
<topicref href"oasis-processes.ditamap" format="ditamap/>
...
</map>

With either of the above examples, during processing, the map is resolved in the following way:

<map>
	<title>DITA work at OASIS</title>
	<topicref href="oasis-dita-technical-committees.dita>
		<topicref href="dita_technical_committee.dita"/>
		<topicref href="dita_adoption_technical_committee.dita/>
	</topicref>
<-- Contents of the oasis-processes.ditamap file -->
<topicref href"oasis-processes.dita>
	...
</topicref>
...
</map>

Example of maps that use the <anchor> element and the @anchorref attribute

In this example, an anchor is defined with an ID of "a1".

<map>
  <title>MyComponent tasks</title>
  <topicref navtitle="Start here" href="start.dita" toc="yes">
    <navref mapref="othermap2.ditamap"/>
    <navref mapref="othermap3.ditamap"/>
    <anchor id="a1"/>
  </topicref>
</map>

The id on <anchor> can be referenced by the anchorref attribute on another map's <map> element. For example, the map to be integrated at that spot would be defined as follows.

<map anchorref="a1">
  <title>This map is pulled into the MyComponent task map</title>
  ...
</map>

2.2.1.2.2.4: DITA map attributes

DITA maps have unique attributes that are designed to control the way that relationships are interpreted for different output purposes. In addition, DITA maps share many metadata and linking attributes with DITA topics.

Attributes unique to DITA maps

DITA maps often encode structures that are specific to a particular medium or output, for example, Web pages or a PDF document. Attributes, such as @print and @toc, are designed to help processors interpret the DITA map for each kind of output. These attributes are not available in DITA topics; individual topics, once separated from the high-level structures and dependencies associated with a particular kind of output, should be entirely reusable regardless of the intended output format. The @collection-type and @linking attributes affect how related links are generated for topics that are referenced in the DITA map.

collection-type

The @collection-type attribute specifies how the children of a <topicref> element relate to their parent and to each other. This attribute, which is set on the parent element, typically is used by processors to determine how to generate navigation links in the rendered topics. For example, a @collection-type value of "sequence" indicates that children of the specifying <topicref> element represent an ordered sequence of topics; processors might add numbers to the list of child topics or generate next/previous links for online presentation. Where the @collection-type attribute is available on elements that cannot directly contain elements (such as <reltable> or <relcolspec>), the behavior of the attribute is reserved for future use.

linking

By default, the relationships between the topics that are referenced in a map are reciprocal:

Child topics link to parent topics and vice versa.

Next and previous topics in a sequence link to each other.

Topics in a family link to their sibling topics.

Topics referenced in the table cells of the same row in a relationship table link to each other. A topic referenced within a table cell does not (by default) link to other topics referenced in the same table cell.

This behavior can be modified by using the @linking attribute, which enables an author or information architect to specify how a topic should participate in a relationship. The following values are valid:

linking="none": Specifies that the topic does not exist in the map for the purposes of calculating links.
linking="sourceonly": Specifies that the topic will link to its related topics but not vice versa.
linking="targetonly": Specifies that the related topics will link to it but not vice versa.
linking="normal": Default value. It specifies that linking will be reciprocal (the topic will link to related topics, and they will link back to it).

Authors also can create links directly in a topic by using the <xref> or <link> elements, but in most cases map-based linking is preferable, because links in topics create dependencies between topics that can hinder reuse.

Note that while the relationships between the topics that are referenced in a map are reciprocal, the relationships merely imply reciprocal links in generated output that includes links. The rendered navigation links are a function of the presentation style that is determined by the processor.

toc

Specifies whether topics are excluded from navigation output, such as a Web site map or an online table of contents. By default, <topicref> hierarchies are included in navigation output; relationship tables are excluded.

navtitle

Specifies a navigation title. This is a shorter version of the title that is used in the navigation only. By default, the @navtitle attribute is ignored; it serves only to help the DITA map author keep track of the title of the topic.

Note

The @navtitle attribute is deprecated in favor of the <navtitle> element. When both a <navtitle> element and a navtitle attribute are specified, the <navtitle> element should be used.

locktitle

If locktitle is set to "yes", the <navtitle> element or @navtitle attribute is used if it is present. Otherwise, the navtitle is ignored and the navigation title is retrieved from the referenced file.

Note

The @navtitle attribute is deprecated in favor of the <navtitle> element. When both a <navtitle> element and a navtitle attribute are specified, the <navtitle> element should be used.

print

Specifies whether the topic should be included in printed output

search

Specifies whether the topic should be included in search indexes.

chunk

Specifies that the processor generates an interim set of DITA topics that are used as the input for the final processing. This can produce the following output results:

Multi-topic files are transformed into smaller files, for example, individual HTML files for each DITA topic.

Individual DITA topics are combined into a single file.

Specifying a value for the @chunk attribute on a <map> element establishes chunking behavior that applies to the entire map, unless overridden by @chunk attributes that are set on more specific elements in the DITA map. For a detailed description of the @chunk attribute and its usage, see Chunking.

copy-to

In most situations, specifies whether a duplicate version of the topic is created when it is transformed. This duplicate version can be either literal or virtual. The value of the @copy-to attribute specifies the uniform resource identifier (URI) by which the topic can be referenced by a @conref attribute, <topicref> element, or <xref> element. The duplication is a convenience for output processors that use the URI of the topic to generate the base address of the output. The @keys and @keyref attributes provide an alternative mechanism; they enable references to topics in specific-use contexts without making copies.

The @copy-to attribute also can be used to specify the name of a new chunk when topics are being chunked; it also can be used to determine the name of the stub topic that is generated from a <topicref> element that contains a title but does not specify a target. In both of those cases, no duplicate version of the topic is generated.

For information on how the @copy-to attribute can be used with the @chunk attribute, see Chunking.

processing-role

Specifies whether the topic or map referenced should be processed normally or treated as a resource that is only included in order to resolve key or content references.

processing-role="normal": The topic is a readable part of the information set. It is included in navigation and search results. This is the default value for the <topicref> element.
processing-role="resource-only": The topic should be used only as a resource for processing. It is not included in navigation or search results, nor is it rendered as a topic. This is the default value for the <keydef> element.

If the @processing-role attribute is not specified locally, the value cascades from the closest element in the containment hierarchy.

Attributes shared by DITA maps and DITA topics

The following metadata and reuse attributes are used by both DITA maps and DITA topics:

product, platform, audience, otherprops, rev, status, importance

dir, xml:lang, translate

id, conref, conrefend, conkeyref,, conaction

props, base

, search

DITA maps also use many of the following attributes that are used with <link> or <xref> elements in DITA topics:

format

href

keyref

scope

type

query

When new attributes are specialized from @props or @base as a domain, they may be incorporated into both map and topic structural types.

How the collection-type and linking attributes work in a relationship table

The following example illustrates how linkage is defined in a DITA map:

Simple linking example

<topicref href="A.dita" collection-type="sequence">
  <topicref href="A1.dita"/>
  <topicref href="A2.dita"/>
</topicref>
<reltable>
  <relrow>
    <relcell><topicref href="A.dita"/></relcell>
    <relcell><topicref href="B.dita"/></relcell>
  </relrow>
</reltable>

When the output is generated, the topics contain the following linkage:

A: Links to A1, A2 as children; Links to B as related
A1: Links to A as a parent; Links to A2 as next in the sequence
A2: Links to A as a parent; Links to A1 as previous in the sequence
B: Links to A as related

The following example illustrates how setting the @linking attribute can change the default behavior:

Linking example with the linking attribute

<topicref href="A.dita" collection-type="sequence">
  <topicref href="B.dita" linking="none"/>
  <topicref href="A1.dita"/>
  <topicref href="A2.dita"/>
</topicref>
<reltable>
  <relrow>
    <relcell><topicref href="A.dita"/></relcell>
    <relcell linking="sourceonly"><topicref href="B.dita"/></relcell>
  </relrow>
</reltable>

When the output is generated, the topics contain the following linkage:

A: Links to A1, A2 as children; Does not link to B as a child or related topic
A1: Links to A as a parent; Links to A2 as next in the sequence; Does not link to B as previous in the sequence
A2: Links to A as a parent; Links to A1 as previous in the sequence
B: Links to A as a related topic

2.2.1.2.2.5: Subject scheme maps

A subject scheme map enables adopters to create custom controlled values and to manage metadata attribute values for an organization or a project without having to write a DITA specialization.

Subject scheme maps use key definition to define a collection of controlled values rather than a collection of topics. The highest level of map that uses the set of controlled values must reference the subject scheme map in which those controlled values are defined.

A controlled value is a short, readable, and meaningful keyword that can abe used as a value in a metadata attribute. For example, the @audience metadata attribute may take a value that identifies the user group associated with a particular content unit. Typical user values for a medical-equipment product line might include therapist, oncologist, physicist, radiologist, and so on. In a subject scheme map, an information architect can define a list of these audience values. Authoring tools may use these lists of controlled values to provide value lists from which authors may select values when they are entering metadata.

If controlled values for a metadata attribute are defined using the subject scheme map, tools may give an organization a list of readable labels, a hierarchy of values to simplify selection, and a shared definition of the value.

Controlled values may be used to classify content for filtering and flagging at build time. They may also be used for retrieval and traversal of the content at run time if information viewers that provide such functionality are available.

Tools may validate controlled values for attributes by reference to the subject scheme map. As with all key definitions and references, the reference must appear in the highest map that makes use of the controlled values.

Defining a list of controlled values

A specialized DITA map, <subjectScheme> is used to define a collection of controlled values. Each controlled value is defined using a specialized topic reference, called <subjectdef>. The <subjectdef> is used to define both a category and a list of controlled values. The top-level <subjectdef> defines the category and the children define the controlled values. The following example illustrates the use of <subjectdef> to define controlled values for a group of users:

<subjectScheme>
<!-- Pull in a scheme that defines audience user values -->
    <subjectdef keys="users">
        <subjectdef keys="therapist">
        <subjectdef keys="oncologist">
        <subjectdef keys="radiationphysicist">
        <subjectdef keys="radiologist">
    </subjectdef>

 <!-- Define an enumeration of the audience attribute, equal to
       each value in the users subject. This makes the following values
       valid for the audience attribute: therapist, oncologist, physicist, radiologist -->
     <enumerationdef>
         <attributedef name="audience"/>
         <subjectdef keyref="users"/>
     </enumerationdef>...
</subjectScheme>

Within the <subjectdef> element

<navtitle> can provide a more readable value name
<shortdesc> within <topicmeta> can provide a definition

An enumeration may be defined with hierarchical levels by nesting subject definitions. If filtering or flagging excludes "therapist" and does not explicity identify "novice", processing should apply filtering to all subsets of therapist. If filtering includes "novice" but does not explicity exclude "therapist", processing should include the general therapist content because it applies to "novice". If flagging explicity includes "therapist" but is not set explicity for "novice", processing should apply the "therapist" flag to the "novice" content as a special type of therapist.

<subjectScheme>
    <subjectdef keys="users">
        <subjectdef keys="therapist">
            <subjectdef keys="novice"/>
            <subjectdef keys="expert"/>
        </subjectdef>
        <subjectdef keys="oncologist">
        <subjectdef keys="physicist">
        <subjectdef keys="radiologist">
    </subjectdef>

The <subjectdef> element can use an @href attribute to refer to a more detailed definition of the subject. For example, the value of "oncologist" could refer to an encyclopedia entry that describes the oncologist role in medicine.

<subjectdef keys="oncologist" href="encyclopedia/oncologist.dita"/>

These definitions may help to clarify the meaning of a value, especially when different parts of an organization may use the same term differently. An editor may support drilling down to the subject definition topic for a detailed explanation of the subject. DITA output formatting may produce a help file, PDF, or other readable catalog for understanding the controlled values.

Validating metadata attributes against a subject scheme

After locating the scheme, editors may validate an attribute against the bound enumeration, preventing users from entering misspelled or undefined values. A map editor may validate the audience attribute in a map against the scheme. A processor may check that all values listed for an attribute in a DITAVAL file are bound to the attribute by the scheme before filtering or flagging.

Scaling a subject scheme to define a taxonomy

A taxonomy differs from a controlled values list primarily in the degree of precision with which the metadata values are defined. A set of controlled values lists is sometimes regarded as the simplest form of taxonomy. Regardless of whether the goal is a simple list of controlled values or a taxonomy:

The same core elements are used (subjectScheme, subjectdef, and schemeref).
A category and its subjects can have a binding that enumerates the values of a metadata attribute.

Beyond the core elements and the attribute binding elements, sophisticated taxonomies can take advantage of some optional elements in the scheme. Most of these optional elements make it possible to specify more precise relationships among subjects.

The <hasNarrower>, <hasPart>, <hasKind>, <hasInstance>, and <hasRelated> elements specify the kind of relationship in a hierarchy between a container subject and its contained subjects. The following example defines San Francisco as an instance of a city but a geographic part of California.

<subjectScheme>
  <hasInstance>
    <subjectdef keys="city" navtitle="City">
       <subjectdef keys="la" navtitle="Los Angeles"/>
       <subjectdef keys="nyc" navtitle=New York City"/>
       <subjectdef keys="sf" navtitle="San Francisco">
    </subjectdef>
    <subjectdef keys="state" navtitle="State">
       <subjectdef keys="ca" navtitle="California"/>
       <subjectdef keys="ny" navtitle=New York"/>
    </subjectdef>
   </hasInstance>
   <hasPart>
      <subjectdef keys="place" navtitle="Place">
        <subjectdef keys="ca">
          <subjectdef keys="la">
          <subjectdef keys="sf">
      </subjectdef>
      <subjectdef keys="ny">
         <subjectdef keys="nyc">
      </subjectdef>
    </hasPart>
 </subjectScheme>

Sophisticated tools can use this scheme to associate content about San Francisco with related content about other California places or with related content about other cities (depending on the interests of the current user).

The scheme can also define relationships between subjects that are not hierarchical. For instance, cities sometimes have "sister city" relationships. The example scheme could add a subjectRelTable element to define these associative relationships, with a row for each sister-city pair and the two cities in different columns in the row.

While users who have access to sophisticated processing tools benefit from defining taxonomies with this level of precision, other users can safely ignore this advanced markup and define taxonomies with hierarchies of subjectdef elements that aren't precise about the kind of relationship between the subjects.

2.2.1.2.3: DITA metadata

Metadata can be applied in both DITA topics and DITA maps. Metadata that is assigned in DITA topics can be supplemented or overridden by metadata that is assigned in a DITA map; this design facilitates the reuse of DITA topics in different DITA maps and use-specific contexts.

2.2.1.2.3.1: Metadata elements

The metadata elements, many of which map to Dublin core metadata, are available in topics and DITA maps. This design enables authors and information architects to use identical metadata markup in both topics and maps.

The <metadata> element is a wrapper element that contains many of the metadata elements. In topics, the <metadata> element is available in the <prolog> element. In maps, the <metadata> element is available in the <topicmeta> element.

In DITA maps, the metadata elements also are available directly in the <topicmeta> element. However, it is recommended to use the metadata elements available in the <metadata> element, as it better supports reuse between topics and maps. Collections of metadata can be shared between DITA maps and topics by using the conref or keyref mechanism.

In general, specifying metadata in a <topicmeta> element is equivalent to specifying it in the <prolog> element of a referenced topic. The value of specifying the metadata at the map level is that the topic then can be reused in other maps where different metadata might apply. Many items in the <topicmeta> element also cascade to nested <topicref> elements within the map.

Note

Not all metadata elements are currently available in the <metadata> element. However, they are available in either the topic <prolog> element or the map <topicmeta> element.

2.2.1.2.3.2: Metadata attributes

Certain attributes are common across most DITA elements. These attributes support content referencing, conditional processing, application of metadata, and globalization and localization.

2.2.1.2.3.2.1: Conditional processing attributes

The metadata attributes specify properties of the content that can be used to determine how the content should be processed. Specialized metadata attributes can be defined to enable specific business processing needs, such as semantic processing and data mining.

Metadata attributes typically are used for the following purposes:

Filtering content based on the attribute values, for example, to suppress or publish profiled content
Flagging content based on the attribute values, for example, to highlight specific content on output
Performing custom processing, for example, to extract business-critical data and store in it a database

Typically @audience, @platform, @product, @otherprops, @props, and specializations of the @props attributes are used for filtering; the same attributes plus the @rev attribute are used for flagging. The @status and @importance attributes, as well as custom attributes specialized from @base, are used for application-specific behavior, such as identifying metadata to aid in search and retrieval.

Filtering and flagging attributes

The following conditional-processing attributes are available on most elements:

product: The product that is the subject of the discussion.
platform: The platform on which the product is deployed.
audience: The intended audience of the content.
rev: The revision or draft number of the current document. (This is typically used only for flagging.)
otherprops: Other properties that do not require semantic identification.
props: A generic conditional processing attribute that can be specialized to create new semantic conditional processing attributes.

In general, a conditional processing attribute provides a list of one or more values separated with whitespace. For instance, audience="administrator programmer" qualifies the content as applying to administrators and programmers.

Other metadata attributes

Other attributes are still considered metadata on an element, but they are not designed for filtering or flagging.

importance

The degree of priority of the content. This attribute takes a single value from an enumeration.

status

The current state of the content. This attribute takes a single value from an enumeration.

base

A generic attribute that has no specific purpose, but is intended to act as the basis for specialized attributes that have a simple value syntax like the conditional processing attributes (one or more alphanumeric values separated by whitespace).

outputclass

Provides a label on one or more element instances, typically to specify a role or other semantic distinction. As the @outputclass attribute does not provide a formal type declaration or the structural consistency of specialization, it should be used sparingly, usually only as a temporary measure while a specialization is developed. For example, <uicontrol> elements that define button labels could be distinguished by adding an @outputclass attribute:

<uicontrol outputclass="button">Cancel</uicontrol>

The value of the @outputclass attribute may be used to trigger XSLT or CSS rules, while providing a mapping to be used for future migration to a more specialized set of user interface elements.

2.2.1.2.3.2.2: Translation and localization attributes

DITA elements have several attributes that support localization and translation.

xml:lang: Identifies the language of the content, using the standard language and country codes. For instance, French Canadian is identified by the value fr-ca. The @xml:lang attribute asserts that all content and attribute values within the element bearing the attribute are in the specified language, except for contained elements that declare a different language.
translate: Determines whether the element requires translation. A default value may be inferred from the element type. For example, <apiname> may be untranslated by default, whereas <p> may be translated by default.
dir: Determines the direction in which the content should be rendered.

2.2.1.2.3.2.3: Architectural attributes

The architectural attributes specify the version of DITA that the content supports, identify the DITA domains that are in use by the content, and provide essential information about specializations that are in use by the content.

The architectural attributes should not be marked up in the source DITA map and topic instances. Instead, the values of the architectural attributes are handled by the processor when the content is processed, preferably through defaults set in the DTD or Schema declaration. This practice ensures that the DITA content instances do not specify invalid values for the architectural attributes.

The architectural attributes are as follows:

class: This attribute identifies the specialization modules for the element type as well as its ancestors. Every DITA element (except the <dita> element that is used as the root of a ditabase document) has a @class attribute.
domains: This attribute identifies the domain specialization modules used in a map or topic and, for each domain module, its module dependencies. The root element of every topic and map has a @domains attribute.
DITAArchVersion: This attribute identifies the version of the DITA architecture used by the DTD or schema. The root element of every topic and map has a @DITAArchVersion attribute. The attribute is declared in a DITA namespace to allow namespace-sensitive tools to detect DITA markup.

To make the document instance usable in the absence of a DTD or Schema declaration, a normalization process may set the architectural attributes in the document instance.

2.2.1.2.3.3: Metadata in maps and topics

Topic metadata can be specified in a DITA map as well as in the topics that the map references. By default, metadata in the map supplements or overrides metadata that is specified at the topic level, unless the @lockmeta attribute of the <topicref> element is set to "no".

Where metadata about topics can be specified

Information about topics can be specified as metadata on the map, as attributes on the <topicref> element, or as metadata attributes or elements in the topic itself:

DITA map: Metadata elements

At the map level, properties can be set by using metadata elements. They can be set for an individual topic, for a set of topics, or globally for the entire document. The metadata elements are authored within a <topicmeta> element, which associates metadata with the parent element, plus the other children of that element. Because the topics in a branch of the hierarchy typically have some common subjects or properties, this is a convenient mechanism to set properties for a set of topics. For example, the <topicmeta> element in a <relcolspec> can associate metadata with all the topics that are referenced in the <reltable> column.

A map can override or supplement everything about a topic except its primary title and body content. All the metadata elements that are available in a topic also are available in a map. In addition, a map may provide alternate titles and a short description. The alternate titles can override their equivalents in the topic. The short description in the map may override the short description in the topic if both following conditions are true:

The <topicref> element specifies a @copy-to attribute.
The processor implements this behavior. Processors may or may not implement this behavior.

DITA map: Attributes of the <topicref> element

At the map level, properties can be set as attributes of the <topicref> element.

DITA topic

Within a topic, authors can either set metadata attributes on the root element or add metadata elements in the <prolog> element.

How metadata set at both the map and topic level is handled

In a topic, the metadata elements apply to the entire topic. In a map, they supplement or override any metadata that is provided in the referenced topics. When the same metadata element or attribute is specified in both a map and a topic, by default the value in the map takes precedence, on the assumption that the author of the map has more knowledge of the reusing context than the author of the topic had. The @lockmeta attribute on the <topicmeta> element controls whether map-specified values override values in the referenced topic.

The <navtitle> element is an exception to the rule of how metadata specified by the <topicmeta> element is propagated. The content of the <navtitle> element is used as a navigation title only if the @locktitle attribute of the parent <topicref> element is set to "yes".

Associating attribute-based metadata with element-based metadata

Do we need examples that illustrate what is discussed earlier in this topic? The extant example really illustrates an edge case, rather than the basic principles.

Discussion from review #3:

Bruce Nevin: I agree with Kris that other examples are needed.
Kris Eberlein: If we want examples, people are going to need to pony up and develop them. This might need to be an item that is deferred to DITA 1.3.

At the topic level, the content of the prolog metadata elements can provide more information about the values that are used for attributes on the elements in the body of the DITA topic. However, prolog metadata and attribute metadata also can be used and expressed independently. The coordination shown here is possible but is not required.

<prolog>
  <metadata>
    <audience name="AdminNovice"
              type="administrator"
              job="customizing"
              experiencelevel="novice">

  </metadata>
</prolog>
....
<p audience="AdminNovice ProgrammerExp">This paragraph applies to both 
novice administrators and expert programmers</p>

In the preceding example, the attribute value AdminNovice is associated with the audience element with the same name, which gives authors and processes more information about the audience in question: in this case, that the "AdminNovice" audience consists of administrators who are customizing and who are new at it.

2.2.1.2.3.4: Cascading of attributes and metadata in a DITA map

Certain map-level attributes and metadata elements cascade throughout a map, which facilitates attribute and metadata management. When attributes or metadata elements cascade, they apply to the elements that are children of the element where the attributes or metadata were specified. Cascading applies to a containment hierarchy, as opposed to a element-type hierarchy.

The following attributes and metadata elements cascade throughout the entire map:

Attributes set on the <map> element
Metadata elements that are contained in the <topicmeta> element that is a child of the <map> element

Attribute values and metadata elements in relationship tables can be applied to entire columns or rows as well as individual cells, a practice that is particularly useful for attribute and metadata management.

Attributes and metadata that cascade

The following attributes and metadata elements cascade:

Attributes

@audience, @platform, @product, @otherprops, @rev
@props and any attribute specialized from @props
@linking, @toc, @print, @search
@format, @scope, @type
@xml:lang, @dir, @translate
@processing-role

Metadata elements

author, source, publisher, copyright, critdates, permissions
audience, category, prodinfo, othermeta

Cascading is additive for attributes and metadata elements that accept multiple values. For attributes that take a single value, the closest value defined on a containing element takes effect. In a relationship table, row-level metadata is considered more specific than column-level metadata, as shown in the following containment hierarchy:

<map> (most general)
- <topicref> container (more specific)
  - <topicref> (most specific)
- <reltable> (more specific)
  - <relcolspec> (more specific)
    - <relrow> (more specific)
      - <topicref> (most specific)

Rules for cascading in the map

When determining the value of an attribute, processors must evaluate each attribute on each individual element in a specific order; this order is specified in the following list. Applications should continue through the list until a value is established or until the end of the list is reached (at which point no value is established for the attribute). In essence, the list provides instructions on how processors can construct a map where all attribute values are set and all cascading is complete.

For example, in the case of <topicref toc="yes>, applications must stop at 2 in the list; a value is specified for @toc in the document instance, so @toc values from containing elements will not cascade to that specific <topicref> element. The @toc="yes" setting on that <topicref> element may cascade to contained elements, provided those elements reach 5 below when evaluating the @toc attribute.

For attributes within a map, the following processing order must occur:

The @conref and @keyref attributes are evaluated.

The explicit values specified in the document instance are evaluated. For example, a <topicref> element with the @toc attribute set to "no" will use that value.
The default or fixed attribute values that are expressed within DTDs or XSDs are evaluated. For example, in the DTDs and XSDs, the @toc attribute on the <reltable> element has a default value of "no".

The default values that are supplied by a controlled values file are evaluated.

The attributes cascade.
The processing-supplied default values are applied.
After the attributes are resolved within the map, they cascade to referenced maps.

Note

The processing-supplied default values do not cascade to other maps. For example, most processors will supply a default value of @toc="yes" when no @toc attribute is specified. However, a processor-supplied default of toc="yes" must not override a value of toc="no" that is set on a referenced map. If the toc="yes" value is explicitly specified, is given as a default through a DTD, XSD, or controlled values file, or cascades from a containing element in the map, it will override a toc="no" setting on the referenced map. See Map-to-map cascading behaviors for more details.
Repeat steps 1 to 4 for each referenced map.
The attributes cascade within each referenced map.
The processing-supplied default values are applied within each referenced map.
Repeat the process for maps referenced within the referenced maps.

Example of metadata elements cascading in a DITA map

The following code sample illustrates how an information architect can apply certain metadata to all the DITA topics in a map:

<map title="DITA maps" xml:lang="en-us">
	<topicmeta>
		<author>Kristen James Eberlein</author>
		<copyright>
			<copyryear year="2009"/>
			<copyrholder>OASIS</copyrholder>
		</copyright>
	</topicmeta>
	<topicref href="dita_maps.dita" navtitle="DITA maps">
		<topicref href="definition_ditamaps.dita" navtitle="Definition of DITA maps"></topicref>
		<topicref href="purpose_ditamaps.dita" navtitle="Purpose of DITA maps"></topicref>
		...
</map>

The author and copyright information cascades to each of the DITA topics referenced in the DITA map. When the DITA map is processed to XHTML, for example, each XHTML files contains the metadata information.

2.2.1.2.3.5: Map-to-map cascading behaviors

When a DITA map (or branch of a DITA map) is referenced by another DITA map, by default, certain rules apply. These rules pertain to the cascading behaviors of attributes, metadata elements, and roles assigned to content (such as the role of "Chapter" assigned by a <chapter> element). Attributes and elements that cascade within a map generally follow the same rules when cascading from one map to another map; this topic covers the exceptions and additional rules that apply.

Cascading of attributes from map to map

The following attributes cascade within a single map:

@audience, @platform, @product, @otherprops, @rev
@props and any attribute specialized from @props
@linking, @toc, @print, @search
@format, @scope, @type
@xml:lang, @dir, @translate
@processing-role

Of these, the following attributes do not cascade from map to map:

@format: this attribute must be set to "ditamap" in order to reference a map or a branch of a map, so it cannot cascade through to the referenced map.
@xml:lang and @dir: cascading behavior for xml:lang is defined in The @xml:lang attribute. The @dir and translate attributes work the same way.
@scope: the @scope value describes the map itself, rather than the content. A @scope value of "external" indicates that the referenced map itself is external and unavailable, so the value cannot cascade into that referenced map.

The @class attribute does not cascade within a map, but is used to determine processing roles that cascade from map to map. See Cascading of roles in specialized maps for more details.

As with values that cascade within a map, the cascading is additive if the attribute permits multiple values (such as @audience). When the attribute only permits one value, the cascading value overrides the top-level element.

Example of attributes cascading between maps

For example, assume the following references in test.ditamap:

<map>
  <topicref href="a.ditamap" format="ditamap" toc="no"/>
  <mapref   href="b.ditamap" audience="developer"/>
  <topicref href="c.ditamap#branch1" format="ditamap" print="no"/>
  <mapref   href="c.ditamap#branch2" platform="myPlatform"/>
</map>

The map a.ditamap is treated as if toc="no" is specified on the root <map> element. This means that the topics that are referenced by a.ditamap do not appear in the navigation generated by test.ditamap (except for branches within the map that explicitly set toc="yes").
The map b.ditamap is treated as if audience="developer" is set on the root <map> element. If the audience attribute is already set on the root <map> element within b.ditamap, the value "developer" is added to any existing values.
The element with id="branch1" within the map c.ditamap is treated as if print="no" is specified on that element. This means that the topics within the branch with id="branch1" do not appear in the printed output generated by test.ditamap (except for nested branches within that branch that explicitly set print="yes").
The element with id="branch2" within the map c.ditamap is treated as if platform="myPlatform" is specified on that element. If the @platform attribute is already specified on the element with id="branch", the value "myPlatform" is added to existing values.

Cascading of metadata elements

Elements that are contained within <topicmeta> or <metadata> follow the same rules for cascading as apply within a single DITA map. For a complete list of which elements cascade within a map, see the column "Does it cascade to child <topicref> elements? " in the topic Reconciling topic and map metadata .

For example, consider the following code snippets:

`test-2.ditamap`

<map>
    <topicref href="a.ditamap" format="ditamap">
        <topicmeta>
            <shortdesc>This map contains information about Acme defects.</shortdesc>
        </topicmeta>
    </topicref>
    <topicref href="b.ditamap" format="ditamap">
        <topicmeta>
            <audience type="programmer"/>
        </topicmeta>
    </topicref>    
    <mapref href="c.ditamap" format="ditamap"/>
    <mapref href="d.ditamap" format="ditamap"/>
    </map>

b.ditamap

<map>
    <topicmeta>
        <audience type="writer"/>
    </topicmeta>
    <topicref href="b-1.dita"/>
    <topicref href="b-2.dita"/>
</map>

When test-2.ditamap is processed, the following behaviour occurs:

Because the <shortdesc> element does not cascade, it does not apply to the DITA topics that are referenced in a.ditamap.
Because the <audience> element cascades, the <audience> element in the reference to b.ditamap combines with the <audience> attribute that is already specified at the top level of that map. The result is that the b-1.dita topic and b-2.dita topic are processed as if they each contained the following child <topicmeta> element:
```
<topicmeta>
    <audience type="programmer"/>
    <audience type="writer"/>
</topicmeta>
```

Note

It is possible that a specialization might define metadata that should replace rather than add to metadata in the referenced map, but DITA (by default) does not currently support this behavior.

Cascading of roles in specialized maps

When a <topicref> element or a specialization of a <topicref> element references a DITA resource, it defines a role for that resource. In some cases this role is straightforward, such as when a <topicref> element references a DITA topic (giving it the already known role of "topic"), or when a <mapref> element references a DITA map (giving it the role of "DITA map").

Unless otherwise instructed, a specialized topicref element that references a map supplies a role for the referenced content. This means that, in effect, the @class attribute of the referencing element cascades to top-level topicref elements in the referenced map. In situations where this should not happen - such as all elements from the OASIS-supplied "mapgroup" domain - the non-default behavior should be clearly specified.

For example, when a <chapter> element from the bookmap specialization references a map, it supplies a role of "chapter" for each top-level element in the referenced map. When the <chapter> element references a branch in another map, it supplies a role of "chapter" for that branch. In effect, the @class attribute for <chapter> ("- map/topicref bookmap/chapter ") cascades to the top-level topicref in the nested map, although it does not cascade any further.

Alternatively, the <mapref> element in the "mapgroup" domain is a convenience element; the top-level <topicref> elements in the map referenced by a <mapref> element must not be processed as if they are <mapref> elements. The @class attribute from the <mapref> element ("+ map/topicref mapgroup-d/mapref ") does not cascade to the referenced map.

In some cases, preserving the role of the referencing element might result in out-of-context content. For example, a <chapter> element that references a bookmap might pull in <part> elements that contain nested <chapter> elements. Treating the <part> element as a <chapter> will result in a chapter that nests other chapters, which is not valid in bookmap and may not be understandable by processors. The result is implementation specific; processors may or may not choose to treat this as an error, issue a warning, or simply assign new roles to the problematic elements.

Example of cascading roles between maps

Consider the scenario of a <chapter> element that references a DITA map. This scenario could take several forms:

Referenced map contains a single top-level <topicref> element: The entire branch functions as if it were included in the bookmap; the top-level <topicref> element is processed as if it were the <chapter> element.
Referenced map contains multiple top-level <topicref> elements: Each top-level <topicref> element is processed as if it were a <chapter> element (the referencing element).
Referenced map contains a single <appendix> element: The <appendix> element is processed as it were a <chapter> element.
Referenced map contains a single <part> element, with nested <chapter> elements.: The <part> element is processed as it were a chapter element. Nested <chapter> elements may not be understandable by processors; applications may recover as described above.
<chapter> element references a single <topicref> element rather than a map: The referenced <topicref> element is processed as if it were a <chapter> element.

2.2.1.2.3.6: Reconciling topic and map metadata

The <topicmeta> element in maps contains numerous elements that can be used to declare metadata. These metadata elements have an effect on the parent <topicref> element, any child <topicref> elements, and – if a direct child of the <map> element – on the map as a whole.

For each element that can be contained in the <topicmeta> element, the following table addresses the following questions:

How does it apply to the topic?: This column describes how the metadata specified within the <topicmeta> element interacts with the metadata specified in the topic. In most cases, the properties are additive. For example, when the <audience> element is set to "user" at the map level, the value "user" is added during processing to any audience metadata that is specified within the topic.
Does it cascade to other topics in the map?: This column indicates whether the specified metadata value cascades to nested <topicref> elements. For example, when an <audience> element is set to "user" at the map level, all child <topicref> elements implicitly have an <audience> element set to "user" also. Elements which can apply only to the specific <topicref> element, such as <linktext>, do not cascade.
What is the purpose when specified on the <map> element?: The map element allows metadata to be specified for the entire map. This column describes what effect, if any, an element has when specified at this level.

Topicmeta elements and their properties

Element	How does it apply to the topic?	Does it cascade to child <topicref> elements?	What is the purpose when set on the <map> element?
<audience>	Add to the topic	Yes	Specify an audience for the entire map
<author>	Add to the topic	Yes	Specify an author for the entire map
<category>	Add to the topic	Yes	Specify a category for the entire map
<copyright>	Add to the topic	Yes	Specify a copyright for the entire map
<critdates>	Add to the topic	Yes	Specify critical dates for the entire map
<data>	Add to the topic	No, unless specialized for a purpose that cascades	No stated purpose, until the element is specified
<data-about>	Add the property to the specified target	No, unless specialized for a purpose that cascades	No stated purpose, until the element is specified
<foreign>	Add to the topic	No, unless specialized for a purpose that cascades	No stated purpose, until the element is specified
<keywords>	Add to the topic	No	No stated purpose
<linktext>	Not added to the topic; applies only to links created based on this occurrence in the map	No	No stated purpose
<metadata>	Add to the topic	Yes	Specify metadata for the entire map
<navtitle>	Not added to the topic; applies only to navigation that is created based on this occurrence in the map. The @locktitle attribute of the parent <topicref> element must be set to "yes" in order for the navigation title to be used.	No	No stated purpose
<othermeta>	Add to the topic	No	Define metadata for the entire map
<permissions>	Add to the topic	Yes	Specify permissions for the entire map
<prodinfo>	Add to the topic	Yes	Specify product info for the entire map
<publisher>	Add to the topic	Yes	Specify a publisher for the map
<resourceid>	Add to the topic	No	Specify a resource ID for the map
<searchtitle>	Replace the one in the topic. If multiple <searchtitle> elements are specified for a singletarget, processors may choose to issue a warning.	No	No stated purpose
<shortdesc>	Only added to the topic when the <topicref> element specifies a @copy-to attribute. Otherwise, it applies only to links created based on this occurrence in the map. Note Processors may or may not implement this behavior.	No	Provide a description of the map
<source>	Add to the topic	No	Specify a source for the map
<unknown>	Add to the topic	No, unless specialized for a purpose that cascades	No stated purpose, until the element is specified

2.2.1.3: DITA processing

Several common DITA processing behaviors are driven by attributes, including setting the set of vocabulary and constraint modules on which a DITA document depends, navigation, linking, content reuse (via direct or indirect addressing), conditional processing, chunking, and printing. In addition, translation of DITA content is expedited through the use of the @dir, @translate, and @xml:lang attributes, and the <index-sort-as> element.

2.2.1.3.1: Module compatibility and the @domains attribute

A given DITA document declares, through the @domains attribute on <map> and <topic> elements, the set of vocabulary and constraint modules on which it depends.

The @domains attribute serves two primary purposes:

To indicate to DITA processors the specific features that they should or must provide in order to completely process the document.
To determine the validity of elements that are copied from one DITA document to another. This copying may occur as the result of a content reference (conref) or key reference (keyref), or may occur in the context of an author editing a DITA document.

A processor can examine the value of the @domains attribute and compare the set of modules listed to the set of modules for which it provides direct support. It then can take appropriate action if it does not provide support for a given module, for example, issuing a warning before applying fallback processing.

When copying, it is necessary to determine if the data being copied (the copy source) requires modules that are not required by the document into which the data is to be copied (the copy target). Such a copy operation is always safe if the copy source requires a subset of the modules that are required by the copy target. Such a copy is unsafe if the copy source requires modules that are not required by the copy target.

When a copy operation is unsafe, processors may compare the copy source to the copy target to determine if the copy source satisfies the constraints of the copy target. If the copy source meets the copy target constraints, the copy may be allowed. Processors should issue a warning that the copy was allowed but the constraints are not compatible. If the copy source does not meet the constraints of the copy target, processors may apply generalization until the generalized result either satisfies the copy target constraints or no further generalization can be performed. If the copy operation can be performed following generalization, the processor should issue a warning that the constraints are not compatible and generalization had to be performed in order to complete the copy operation.

2.2.1.3.2: Navigation behaviors

DITA includes markup that processors may use to generate reader navigation to or across DITA topics.

While DITA content can be processed to create output with media-specific navigational aids, this topic discusses only the behaviors that are derived from markup.

Tables of contents (TOCs)

Processors may generate a TOC based on the hierarchy of the <topicref> elements in the DITA map. Each <topicref> element in the map represents a node in the TOC (unless it is set as a "resource only" topic reference). These topic references define a navigation tree. When a map contains a topic reference to a map (often called a map reference), processors should integrate the referenced map's navigation tree with the referencing map's navigation tree at the point of reference. In this way, a deliverable may be compiled from multiple DITA maps.

Note

If a <topicref> element that references a map contains child <topicref> elements, the processing behavior of the child <topicref> elements is undefined.

By default, the text for each node in the TOC is obtained from the referenced topic's title. If the @locktitle attribute on the <topicref> element is set to "yes", the node text must be taken from the @navtitle attribute or <navtitle> child element of the <topicref> element and must not be read from the referenced topic's title. If a <topicref> element contains both a <navtitle> child element and a @navtitle attribute, the @locktitle attribute applies to both <navtitle> and @navtitle and, when set to "yes", the value of the <navtitle> element must be used.

A TOC node is generated for every <topicref> element (or specialization thereof) that references a topic or specifies a navigation title, except in the following cases:

The @processing-role attribute is specified on the <topicref> element or an ancestor element.
The @print attribute is specified on the <topicref> element or an ancestor element and the current processing is not for print output.
Conditional processing is used to filter out this node or an ancestor node.
No @href or @navtitle attribute is set and no child <navtitle> element exists, or the node is a <topicgroup> element.

To suppress a <topicref> element from appearing in the TOC, set its @toc attribute to "no". The value of the @toc attribute cascades to child <topicref> elements, so if @toc is set to "no" on a particular <topicref>, all of that <topicref>'s children are also excluded from the TOC. If a child <topicref> overrides the cascading TOC node suppression by specifying @toc="yes", then the node that specifies @toc="yes" must appear in the TOC (minus the intermediate nodes that turned off @toc).

Indexing

An index may be generated from index entries occurring in topic bodies, topic prologs, or DITA maps. For more information, see the language reference for the <indexterm> element.

2.2.1.3.3: DITA linking

DITA depends heavily on links. The purposes for which it provides links include defining the content and organization of publication structures (DITA maps), topic-to-topic navigation links and cross references, and reuse of content by reference. All DITA links use the same addressing facilities, either URI-based addresses or DITA-specific indirect addresses using keys and key references.

At its most general, a link establishes a relationship among two or more objects. In DITA, relationships are among DITA elements and either other DITA elements or non-DITA resources, such as Web pages. Relationships may be explicitly typed in some cases (relationship tables and subject scheme maps for example) but are not always associated with a specific relationship type.

Anderson, March 10 2010: changed "are generally not associated" to "are not always associated" - I think the wording was unclear, and in particular, navigation links are quote often created and typed by the role attribute as parent/child/next/previous/etc. I'm not sure if that is considered "typed" by this definition, but to me "are generally not" means most are not, while a large percentage of relationships I encounter are typed in this way.

Note

For example, a <keyword> element that uses a key reference to link to the definition of the keyword can be considered to be establishing a "mention-of" relationship from the <keyword> element to the definition and a "definition-of" relationship from the definition to the <keyword> element. But those link types are not formally defined either in the DITA definition of <keyword> or in the markup for the <keyword> element itself. While DITA enables the formal definition of typed relationships for some types of link elements, it does not require that all links be formally typed and does not provide a general mechanism for associating explicit link types with links.

In the abstract, link relationships may be explicit, defined directly by some type of markup in the source data, or implicit, implied by properties of the content that a processor uses to infer relationships (for example, matching the content of a <keyword> element to the title of a topic of a specific topic type). DITA formally defines only explicit links, although processors may implement implicit links.

A link may establish either a navigation relationship or a use-by-reference relationship (e.g., content references). Navigation relationships are used primarily to enable navigation from one element to another, although they may also be used for other purposes, such as classification, or association of metadata. Use-by-reference relationships establish the effective structure and content of the information set.

An element that establishes one or more such relationships is a "link-defining element". Some element types, such as <link> and <xref>, are always link-defining elements. Other element types become link-defining elements when they use specific link-defining attributes.

Almost any element may become a use-by-reference link by using the @conref or @conkeyref attribute to establish a content reference (conref) relationship to another element or set of elements (see Use by reference). Elements such as <term> and <keyword> may become navigation links by using the @keyref attribute to establish a relationship to another DITA element or non-DITA resource.

In general, elements within topics that take both the @href and @keyref attributes always act as elements that define a navigation link, while elements that take @keyref but not @href act as elements that define a navigation link only when they specify @keyref.

A given link-defining element may establish more than one relationship. For example, an element may establish both a content reference link and a navigation link. A single row in a relationship table may establish a number of distinct relationships among the topics referenced in the different cells of the relationship table. A topic reference within a hierarchy of topic references establishes not only a use-by-reference relationship from the map to the topic, but also hierarchical relationships from the referenced topic to other topics in the navigation hierarchy (parents, siblings, and children).

DITA defines two forms of addresses for use in defining links, direct URI-based addresses and indirect key references. In all cases, the nature of the relationships established is independent of the form of address used. For example, a cross reference that uses a key reference to address the target of the cross reference is functionally equivalent to having addressed the same target by URI reference, in that the final processing result should be the same in both cases. However, the two forms of address have different practical and intermediate processing implications. See DITA addressing.

Links from maps to other maps, topics, or non-DITA resources establish explicit dependencies from the map containing the links to the associated resources. Links from maps to maps create a "map tree". The set of dependencies for a root map is the union of the dependencies of all the maps in the map tree.

Links from a topic to other topics, maps, or non-DITA resources establish explicit dependencies from the topic containing the links to the associated resources, and implicit dependencies from any maps that use that linking topic to its dependencies.

For the purposes of determining the set of dependencies for a given map tree, processors may ignore any implicit dependencies created by links within topics that are not also established by explicit dependencies in the map tree. In the case where a map includes a topic that includes a topic-to-topic link, where the linked topic is not explicitly included in the map, and the processor considers only dependencies that are explicitly defined in the map, the processor may fail to resolve the topic-to-topic link. This case can be avoided by using a resource-only topic reference in the map tree to establish the dependency explicitly. If the resource-only topicref also defines a key, the link within the topic can then be changed to use a key reference (@keyref or @conkeyref) instead of a URI reference (@href, @conref). See Key-based addressing.

Navigation links have an associated "scope" indicating the closeness of the relationship of the linking element to associated resources. See The scope attribute.

Most navigation links have an associated "link text", which is the text used to render the link so that it can be used. For all elements that allow or require link text, the link text may be specified as part of the linking element or, if unspecified, should be taken from the referenced resource. The details for how the link text for a given element should or may be generated are defined for that element type and may also be determined entirely by a rendition processor.

In the specific case of cross references created using <xref> and related links using <link>, the potential set of rules for constructing link text is essentially unbounded. Processors may, for example, define conventions for the value of @outputclass by which authors can indicate the details of how the link text should be constructed, or they may provide appropriate configuration options for controlling or customizing the construction of link text in cross references.

2.2.1.3.3.1: Links within maps

DITA maps serve primarily to define a navigation hierarchy of topics and non-DITA resources. Through relationship tables, maps may also define arbitrary topic-to-topic relationships such as "related links". Maps may also link to topics or non-DITA resources to establish dependency relationships without binding the linked resource into the navigation tree.

By default, the topic references within a map but not within a relationship table establish a navigation tree rooted at the root map within a map tree. A topic reference contributes to the navigation tree when it specifies a navigation title or references a topic or non-DITA resource. The @collection-type attribute of the <topicref> element determines the relationships established between the topicref and its parent, sibling, and child topicrefs, as well as among its child topicrefs.

A <topicref> or <navref> element that references a map does not bind the map to the navigation tree but acts as a form of use-by-reference link to the direct subelements of <map> and the relationship tables of the referenced map.

Maps may also contain relationship tables (<reltable>). Relationship tables establish navigation links among sets of topics and non-DITA resources. A given relationship table defines one or more links of a specific relationship type. See reltable. A map may include any number of relationship tables. Within a map tree, the effective set of relationship tables is the union of all the relationship tables in all the maps in the map tree.

Topic references that specify a @processing-role value of "resource-only" establish dependencies from the map to the associated resource but do not bind the resource to the navigation tree. Resource-only topic references are typically used for key definitions where the key is not intended to represent a specific navigation tree location and for topics that hold elements used only for content reference or that otherwise should not be reflected in the navigation tree.

Topic references in the navigation tree can further control whether or not they are included in tables of contents using the @toc attribute. A topic reference that specifies "no" for the @toc attribute and is not a resource-only topic reference still contributes to the navigation tree. In particular, any relationships determined by the value of the @collection-type attribute are created.

Topic references in the navigation tree can use the @linking attribute to control how links created by the effective @collection-type value apply to the topic reference's associated resource. See topicref-atts, topicref-atts-no-toc, and topicref-atts-without-format attribute groups.

Within maps, subordinate maps may be linked in either of two ways:

<topicref> with a @format value of "ditamap" (this type of map reference is sometimes referred to as a "mapref")
<navref>

The <navref> element links to an otherwise independent map and indicates that the integration of that map's navigation structure into the larger navigation tree is deferred so that it can be performed as a final step in any delivery of the rendered content. Maps referenced by <navref> do not contribute to the key space of the map tree from which they are referenced. The map referenced by <navref> need not be available for processing at the time the referencing map is processed.

2.2.1.3.3.2: Links within topics

A topic may contain several types of links.

Content reference links from any element in the topic that allows @conref or @conkeyref.
Related information links, within a <related-links> element following the topic body. The related links are usually rendered at the end of the topic.
Image links created using <image>. Image elements may use <longdescref> to link to the long description for the image as a supplement to the <alt> element.
Object links created using <object>. Object elements may use <longdescref> to link to the long description for the object as a supplement to the <alt> element.
Navigation links created using <xref>. For output media that support hyperlinking, the <xref> should result in a hyperlink.
Navigation links created using @keyref on elements that allow @keyref but not @href (e.g., <ph>, <cite>, <keyword>, and <term>).
Metadata associations using <data-about> in contexts where <data> is allowed.
Navigation links from long quotes to the source of the quote using <longquoteref>.

Links to resources outside a topic's containing XML document that use direct URI-based addresses establish unconditional topic-to-resource dependencies. Such dependencies can impede reuse in two ways:

The linking topic cannot be used in a given map unless the dependent resource is also used.
The linked resource cannot be dynamically changed based on the map context in which the linking topic is used.

These issues can be avoided by using key-based addressing. Because keys are defined in maps, each map that uses the linking topic can bind the key to the most appropriate resource.

2.2.1.3.4: DITA addressing

DITA provides a number of facilities for establishing relationships among DITA elements and between DITA elements and non-DITA resources. All DITA relationships use the same addressing facilities irrespective of the semantics of the relationship established. DITA addresses are either direct, URI-based addresses, or indirect key-based addresses. Within DITA documents, individual elements are addressed by unique IDs specified on the common @id attribute. DITA defines two fragment identifier syntaxes for addressing DITA elements, one for topics and elements within maps and one for non-topic elements within topics.

2.2.1.3.4.1: ID attribute

The DITA identity attribute provides a mechanism for identifying content for linking.

The id attribute assigns an identifier to DITA elements so the elements can be referenced. The id attribute is available for most elements. The id attribute is required on some elements. For a specific element to be referenced, it must have an id attribute with a valid value, although entire maps and the first topic, only topic, or all direct-child topics (depending on processing context) in a topic-containing document may be referenced without using an ID. The requirements for the id attribute differ depending on whether it is used on a topic element, a map element, or an element within a topic or map.

The id attributes for topic and map elements are true XML IDs and therefore must be unique with respect to other XML IDs within the scope of the XML document that contains the topic or map element. The id attribute for most other elements within topics and maps are not declared to be XML IDs. This means that XML parsers do not require that the values of those attributes be unique. All id attribute values must be XML name tokens.

Within documents containing multiple topics, the IDs for all non-topic elements that have the same nearest ancestor topic element should be unique with respect to each other. The IDs for non-topic elements may be the same as non-topic elements with different nearest ancestor topic elements.

Note

Thus, within a single XML document containing multiple peer or nested topics, the IDs of the non-topic elements only need to be unique within each topic without regard to the IDs of elements within any ancestor or descendant topics.

The IDs of all elements within a map should be unique within that map document. When two elements within a map have the same ID value, the first element with a given ID value, in document order, must be used as the target of any reference to that ID.

ID requirements summary table

Element	Attribute type	Unique within	Required	Value type
map	ID	document	No	XML non-colonized name token
topic	ID	document	Yes	XML non-colonized name token
sub-map	NMTOKEN	document	Usually no, with some exceptions	Any legal XML name token
sub-topic	NMTOKEN	individual topic	Usually no, with some exceptions	Any legal XML name token

2.2.1.3.4.2: URI-based (direct) addressing

Content reference and link relationships can be established from DITA elements using URI references to point directly to targets.

URI references address "resources" and, optionally, subcomponents of those resources. In the context of DITA, a resource is a DITA document (map, topic, or DITA base document) or a non-DITA resource (e.g., a Web page, a PDF document, etc.). For DITA resources, fragment identifiers can be used with the URI to address individual elements. The fragment identifier is the part of the URI that starts with a number sign ("#"), e.g., "#topicid/elementid". URI references may also include a query component, introduced with "?". DITA processors may ignore queries on URI references to DITA resources.

Note

URI references that are URLs must conform to the rules for URLs and URIs. In particular, Windows paths with backslashes are not valid URLs.

URIs and DITA fragment identifiers

DITA uses URI references in @href, @conref, or other attributes for all direct addressing of resources.

For addressing DITA elements within maps and topics or individual topics within documents containing multiple topics, URI references must include the appropriate DITA-defined fragment identifier. URI references may be relative or absolute. A relative URI reference may consist of just a fragment identifier. Such a reference is a reference to the document that contains the reference.

When addressing a DITA topic element, URI references may include a fragment identifier that includes the ID of the topic element (filename.dita#topicId or #topicId).

When addressing a non-topic element within a DITA topic, a URI reference must use a fragment identifier that contains the ID of the ancestor topic element of the non-topic element being referenced, a solidus ("/"), and the ID of the non-topic element (filename.dita#topicId/elementId or #topicId/elementId).

This addressing model makes it possible to reliably address elements whose id attribute values are unique within a single DITA topic but which may not be unique within a larger XML document that contains multiple DITA topics. (See ID attribute for more information on ID attributes.)

When addressing a DITA map element, URI references may include a fragment identifier that includes the ID of the map element (filename.ditamap#mapId or #mapId).

If a target DITA element is within the same XML document as the element making the reference, the URI reference may consist of only the fragment identifier (including the "#" (number sign) character).

Addressing non-DITA targets via URI

All resources, regardless of type, are directly addressed by URI references from DITA elements. When addressing targets within non-DITA resources, any fragment identifier used must conform to the fragment identifier requirements defined for the target media type, including references to non-DITA XML resources.

Addressing DITA topics via URI

Topics can always be addressed by a URI reference whose fragment identifier consists of the topic's ID. For the purposes of linking, a reference to a topic-containing document addresses the first topic within that document in document order. For the purposes of rendering, a reference to a topic-containing document addresses the root element of the document.

Note

For example, given a document whose root element is a topic, a URI reference (with no fragment identifier) addressing that document implicitly references the topic element. Given a <dita> document containing multiple topics, a URI reference addressing the <dita> document implicitly addresses the first child topic of the <dita> element for purposes of linking (for example, from a cross reference element) but addresses the <dita> element for the purposes of rendering (implying that all the topics contained by the <dita> element will be rendered in the result).

Addressing non-topic DITA elements via URI

To address non-topic elements within topics via URI, a topicID/elementID fragment identifier must be used.

To address elements within a DITA map via URI, an elementID fragment identifier must be used. The linking element must specify a value of "ditamap" for the format attribute.

URI reference syntax examples

The following table shows the URI syntax for common use cases.

Use case	Sample syntax
target a table in a topic at a network location	"http://example.com/file.dita#topicID/tableID"
target a section in a topic on a local file system	"directory/file.dita#topicID/sectionID"
target a figure contained in the same XML document	"#topicID/figureID"
target an element within an map	"http://example.com/map.ditamap#elementID" (and a value of "ditamap" for the format attribute)
target a map element within the same map document	"#elementID" (and a value of "ditamap" for the format attribute)
reference an external Web site	"http://www.somesite.com", "http://www.somesite.com#somefragment" or any other valid URI
reference an element within a local map	"filename.ditamap#elementid" (and a value of "ditamap" for the format attribute)
reference a local map	"filename.ditamap" (and a value of "ditamap" for the format attribute)
reference a local topic	reference a local topic "filename.dita" or "path/filename.dita"
reference a specific topic in a local document	"filename.dita#topicid" or "path/filename.dita#topicid"
reference a specific topic in the same file	"#topicid"

2.2.1.3.4.3: Key-based addressing

The DITA key-reference mechanism provides a layer of abstraction so that the resources addressed by references can be defined globally at the DITA map level instead of locally in each topic.

When using DITA topics in the context of different maps, it is often necessary to have a relationship resolve to different resources. For example, a content reference to a <ph> element that contains a product name might need to resolve to a different <ph> element when used in a different product-specific map. The DITA key-reference mechanism provides an indirect addressing mechanism that separates references (topicrefs, conrefs, cross references, etc.) from the direct address of the target. (A direct address is the address specified on the element that references the key, for example via @href or @conref.) Linking elements can refer to key names; the key names then are bound to specific resources by maps. Different maps can bind the same key names to different resources. This form of indirection is late bound, because the binding of key names to resources is determined at processing time based on the current set of key definitions for the map context rather than from a static binding that is created when a topic or map is authored.

To address a review #3 comment from David Helfinstine, I broke the original topic (11 pages!) down into four child topics. (Caveat: This was quick and dirty work on an area that wasn't my primary responsibility.) This area needs additional work, so I did not add <shortdesc> elements for all new topics. I have the following concerns:

I think this content is nested too deeply in the architecture.
Ideally, I think the examples should be integrated into the topics, rather than segregated into a separate topic.
Is the syntax for key-based addressing covered in the language reference topics? While I think we need a sound overview of key-based addressing the in the arch spec topics, I think users will look first to the language reference when wanting to retrieve information about syntax.

2.2.1.3.4.3.1: Overview of keys

To use key references, one must understand how keys are defined and bound to resources, how a map hierarchy establishes a key space, and the interaction of keys with conditional processing.

Key definition

Keys are defined within maps. Key names are defined using the @keys attribute on <topicref> elements (or specializations of topicref, such as <keydef>).

The @keys attribute uses the following syntax:

The value of the @keys attribute is one or more space separated key names.
Key names consist of characters that are legal in a URI. The case of key names is significant.
The following characters are prohibited in key names: "{", "}", "[", "]", "/", "#", "?", and whitespace characters.

The @keys attribute in any <topicref> element can be used to define keys, regardless of any other purpose that it may serve in the map. However, common practice is to define most or all keys separately from the topic references that are used to establish navigation hierarchies and relationships. If a separate DITA map is created that contains only key definitions, it should have the @processing-role attribute set to "resource-only". The map-group vocabulary module includes the <keydef> element, a specialization of <topicref> in which the value of the @processing-role attribute is set by default to "resource-only".

Key binding

A key can be bound simultaneously to several resources:

It is directly bound to the resource addressed by the @href attribute of the key-defining element, if a @keyref either is not specified or cannot be resolved following key space construction.
If the key-defining element specifies a @keyref attribute and the key reference can be resolved following key space construction, the key is bound to any directly addressed resource bound to the referenced key (directly or indirectly). (It is an error for a topicref to refer directly or indirectly to any key that it defines.)
It is bound to the subelements of the <topicmeta> element within the key-defining element, if any are present.

Key spaces

A root map and its directly addressed, local scope descendant maps establish a unique key space within which each unique key name has exactly one binding to a set of resources.

For the purposes of determining the effective key definitions for the key space represented by a given root map, a map tree is determined by considering only directly addressed, local scope maps descending from the root map. The order of subordinate maps is determined by the document order of the topicrefs that point to them. Indirect references to maps with key references are necessarily ignored until after the key space is determined.

Maps addressed by <navref> do not contribute to the key space of a map tree. Maps referenced by <navref> are equivalent to maps referenced with a scope of "peer" or "external" and therefore need not be present or available at the time the referencing map is processed for purposes of key space construction.

Keys and conditional processing

The effective keys for a map might be affected by conditional processing (filtering). Processors should perform conditional processing before determining effective key definitions. However, processors may determine effective key bindings before filtering. Consequently, different processors might produce different effective bindings for the same map when there are key definitions that might be filtered out based on their select attributes.

If filtering is not done first, the same root map may result in different effective key spaces for different sets of conditions. For processors that provide sets of available keys within an information set, such as authoring support systems, keys may need to be associated with the conditions specified on their key definitions. For example, given a map that defines the key "os-name" twice with different conditions, an author may need to know both that the key has two possible bindings within the key space and what the conditions are under which those bindings are effective. It also means that processors might need both a root map and a set of active conditions (for example, a DITAVAL document) in order to correctly determine the effective key space.

A relative URI reference in a key definition is resolved relative to the base URI established for the location of the key definition rather than relative to the various locations of references using the key.

Effective key definitions

For a given key there is at most one effective definition within a key space. A key definition is the effective definition for a given key if it is the first, in document order, within the map document that contains it, and is the first in the map tree in breadth-first order. It is not an error for the same key name to be defined more than once within a map or map tree, and duplicate key definitions should be ignored without warning.

Note

A given <topicref> element that defines more than one key may be the effective definition for some of its keys but not for others. It is the duplicate binding of a key name to its definition that is ignored, not the key-defining topic reference as a whole.

Key definitions are not scoped by the map document within which they occur or by the element hierarchy of their containing map document. Keys do not have to be declared before they are referenced. The key space is effective for the entire document, so the order of key definitions and key references relative to one another within the map hierarchy is not significant, and keys defined in any map in the map tree are available for use with key references from all maps and topics processed in the context of the root map.

Note

These rules mean that key definitions higher in the map tree hierarchy take precedence over key definitions lower in the map tree and that key definitions in referencing maps always take precedence over key definitions in referenced maps. These rules also mean that the entire key space must be determined before any keys can be resolved to their ultimately-addressed resources (if any).

Note

Because keys are defined in maps, all key-based processing must be done in the context of a root map that establishes the effective key space.

For key definitions in a submap to be included in the key space, there must be a direct URI reference to that submap from another directly addressed map in the map tree. However, if that same submap is referenced indirectly and has no direct URI reference as a backup (using @keyref without providing a fallback @href value, or using @conkeyref without providing a fallback @conref value), that reference is ignored for purposes of constructing the key space, and the definitions in that submap consequently do not enter into the construction of the key space at that point.

2.2.1.3.4.3.2: Using keys to address DITA elements

For topic references, image references, and navigation link relationships (<link>, <xref>, and elements that take the @keyref but not the @href attribute), resources can be addressed by key using the @keyref attribute. For content reference relationships, resources can be addressed by key using the @conkeyref attribute.

Syntax

For references to topics, maps, and non-DITA resources, the value of the @keyref attribute is simply a key name: keyref="topic-key".

For references to non-topic elements within topics and non-topicref elements within maps, the value of the @keyref attribute is a key name, a solidus ("/"), and the ID of the target element: keyref="topic-key/some-element-id".

If both @keyref and @href attributes are specified on an element, the @href value must be used as a fall-back address when the key name is undefined, and should be used as a fall-back address when the key name is defined but the key reference cannot be resolved to a resource. If both @conkeyref and @conref attributes are specified on an element, the @conref value must be used as a fall-back address when the key name is undefined, and should be used as a fall-back address when the key name is defined but the key reference cannot be resolved to a resource.

Example

For example, consider this topic in the document "file.dita":

<topic id="topicid">
 <title>Example referenced topic</title>
 <body>
  <p id="para-01">Some content.</p>
 </body>
</topic>

and this key definition:

<map>
  <topicref keys="myexample"
    href="file.dita"
  />
</map>

A keyref of the form "myexample/para-01 resolves to the <p> element in the topic. The key reference would be equivalent, in the context of this map, to the URI reference file.dita#topicid/para-01.

A key reference to a topicref element where the linking element specifies a format value of "ditamap" addresses the topicref element itself as though the topicref element had been addressed by ID. In particular, a topicref with a key reference to another topicref and a format value of "ditamap" is a use of the map branch rooted at the referenced topicref.

2.2.1.3.4.3.3: Processing key references

When a key definition is bound to a resource addressed by @href or @keyref and does not specify "none" for the @linking attribute, all references to that key definition become navigation links to the bound resource. When a key definition is not bound to a resource or specifies "none" for the @linking attribute, references to that key do not become navigation links.

When a key definition has a <topicmeta> subelement, elements that refer to that key and that are empty may get their effective content from the first matching subelement of the <topicmeta> subelement of the key-defining topicref. If no matching element is found, the contents of the <linktext> tag, if present, should be used. Elements within <linktext> that do not match the content model of the key reference directly or after generalization should be skipped. For <link> tags with a keyref attribute, the contents of the <shortdesc> tag in the key-defining element should provide the <desc> contents.

When a key definition has no @href value and no @keyref value, references to that key will not result in a link, even if they do contain an @href attribute of their own. If the key definition also does not contain a <topicmeta> subelement, empty elements that refer to the key (such as <link keyref="a"/> or <xref keyref="a" href="fallback.dita"/>) are removed.

Matching element content for key references contained in @keyref attributes falls into one of two categories:

For elements on which no @href attribute is available (such as cite, dt, keyword, term, ph, indexterm, index-base, and indextermref, and their specializations), matching content is taken from the <keyword> or <term> elements within <keywords> within <topicmeta>. If more than one <keyword> or <term> is present, the matching content is taken from the first of them.
For elements that in addition to @keyref or @conkeyref do specify an @href attribute (such as author, data, data-about, image, link, lq, navref, publisher, source, topicref, xref, and their specializations), matching content includes all elements from within the key definition element that are in valid context within the key reference. Elements that are invalid within the key reference element directly or after generalization are not included or are filtered out.

For key reference elements that become navigation links, if there is no matching element in the key definition, normal link text determination rules apply as for <xref>.

If a referencing element contains a key reference with an undefined key, it is processed as if there were no key reference, and the value of the @href attribute is used as the reference. If the @href attribute is not specified either, the element is not treated as a navigation link. If it is an error for the element to be empty, an implementation may give an error message, and may recover from this error condition by leaving the key reference element empty.

For topic references that use the @keyref attribute, the effective value of the <topicref> element is determined as follows:

The effective resource bound to the <topicref> element is determined by resolving all intermediate key references. Each key reference is resolved either to a resource addressed directly by URI reference in an @href attribute, or to no resource. Processors may impose reasonable limits on the number of intermediate key references they will resolve. Processors should support at least three levels of key references.

Note

This rule applies to all topic references, including those that define keys. Thus, the effective bound resource for a key definition that uses the @keyref attribute cannot be determined until the key space has been constructed.

The attributes that are common to a key definition element and a key reference element using that key, other than the @keys, @processing-role, and @id attributes, are combined as for content references, including the special processing for the @xml:lang, @dir, and @translate attributes. There is no special processing associated with either the @locktitle or the @lockmeta attributes when attributes are combined.

Removed paragraph and list per public review 1 comment C024.

Content from a key reference element and a key-defining element is combined following the rules for combining metadata between maps and other maps and between maps and topics. The @lockmeta attribute is honored when metadata content is combined.

The combined attributes and content cascade from one map to another or from a map to a topic, but this is controlled by existing rules for cascading, which are not affected by the use of key references.

2.2.1.3.4.3.4: Examples of keys

A generic topicref element used to define a key bound to a topic:

<map>
  ...
  <topicref keys="apple-definition"
    href="topics/glossary/apple-gloss-en-US.dita"
  />
  ...
</map>

In this example, the topicref is acting as both a key definition and contributing to the navigation structure of the map, meaning the topic apple-gloss-en-US.dita will be processed as it would be if the @keys attribute were not present.

The same key definition using the <keydef> specialization of <topicref>:

<map domains="(map mapgroup-d)">
  ...
  <keydef keys="apple-definition"
    href="topics/glossary/apple-gloss-en-US.dita"
  />
  ...
</map>

Because the <keydef> element sets the default value of the @processing-role attribute to "resource-only", the key definition does not contribute to the map's navigation structure, but only serves to establish the key-to-resource binding for the key "apple-definition".

Duplicate definition of the same key:

<map domains="(map mapgroup-d)">
  ...
  <keydef keys="load-toner"
    href="topics/tasks/model-1235-load-toner-proc.dita"
  />
  <keydef keys="load-toner"
    href="topics/tasks/model-4545-load-toner-proc.dita"
  />
  ...
</map>

In this example, only the first definition in document order of the "load-toner" key is effective, so all references to the key within the scope of the root map will resolve to the topic model-1235-load-toner-proc.dita, not topic model-4545-load-toner-proc.dita.

Duplicate definitions with different conditions:

<map domains="(map mapgroup-d)">
  ...
  <keydef keys="file-chooser-dialog"
    href="topics/ref/file-chooser-osx.dita"
    platform="osx"
  />
  <keydef keys="file-chooser-dialog"
    href="topics/tasks/file-chooser-win7.dita"
    platform="windows7"
  />
  ...
</map>

In this example, both key definitions use the @platform metadata attribute to indicate that they apply to different operating system platforms. In this case, the effective key definition is determined not just by the order in which the definitions occur but whether the active value of @platform is "osx" or "windows7" when the key space is determined or the key is resolved. In this case both key definitions are potentially effective because they have distinct values for conditional attributes. Note that if no active value is specified for the @platform condition when determining the effective keys, then both of the definitions are effective and thus the first one in document order is the effective definition.

If the DITA value configuration were defined such that the default behavior is "exclude" rather than the normal default of "include", then neither definition would be effective and the key would be undefined. That case can be avoided by specifying an unconditional key definition after any conditional key definitions, e.g.:

<map domains="(map mapgroup-d)">
  ...
  <keydef keys="file-chooser-dialog"
    href="topics/ref/file-chooser-osx.dita"
    platform="osx"
  />
  <keydef keys="file-chooser-dialog"
    href="topics/tasks/file-chooser-win7.dita"
    platform="windows7"
  />
  <keydef keys="file-chooser-dialog"
    href="topics/tasks/file-chooser-generic.dita"
  />
  ...
</map>

In this case, with an explicitly-configured default behavior of "exclude", if no active value for the platform condition is specified, the third definition will be the effective definition, binding the key "file-chooser-dialog" to the topic file-chooser-generic.dita.

Duplicate key definitions using subordinate maps

Root map:

<map domains="(map mapgroup-d)">
  <keydef keys="toner-specs"
   href="topics/reference/toner-type-a-specs.dita"
  />
  <mapref href="submap-01.ditamap"/>
  <mapref href="submap-02.ditamap"/>
</map>

submap-01.ditamap:

<map domains="(map mapgroup-d)">
  <keydef keys="toner-specs"
   href="topics/reference/toner-type-b-specs.dita"
  />
  <keydef keys="toner-handling"
   href="topics/concepts/toner-type-b-handling.dita"
  />
</map>

submap-02.ditamap:

<map domains="(map mapgroup-d)">
  <keydef keys="toner-specs"
   href="topics/reference/toner-type-c-specs.dita"
  />
  <keydef keys="toner-handling"
   href="topics/concepts/toner-type-c-handling.dita"
  />
  <keydef keys="toner-disposal"
   href="topics/tasks/toner-type-c-disposal.dita"
  />
</map>

In this example the effective key space is:

Key	Bound resource
toner-specs	toner-type-a-specs.dita
toner-handling	toner-type-b-handling.dita
toner-disposal	toner-type-c-disposal.dita

The binding for the key "toner-specs" in the root map is effective because it is the first encountered in a breadth-first traversal of the map tree. The binding for the key "toner-handling" to the definition in submap-01.ditamap is effective because submap-01 is included before submap-02 and therefore comes first in the map tree. The binding for the key "toner-disposal" is effective because it is the only definition of the key in the map tree.

A key definition that uses elements within the key definition rather than a separately-addressed resource

<map domains="(map mapgroup-d)">
  <keydef keys="product-name">
    <topicmeta>
     <keywords>
       <keyword>Thing-O-Matic</keyword>
     </keywords>
    </topicmeta>
  </keydef>
</map>

This form of key definition would normally be used from a <keyword> element in order to use the value defined in the key definition:

<topic id="topicid">
  <title>About the <keyword keyref="product-name"/> product</title>
</topic>

Normal processing results in the effective title text "About the Thing-O-Matic product".

A key definition that uses both elements within the key definition and points to a resource

<map domains="(map mapgroup-d)">
  <keydef keys="yaw-restrictor"
    href="parts/subassem/subassm-9414-C.dita"
  >
    <topicmeta>
     <keywords>
       <keyword>yaw restrictor assembly</keyword>
     </keywords>
    </topicmeta>
  </keydef>
</map>

When referenced from a <keyword> element with no directly-specified content, normal processing sets the effective content of the keyword to "yaw restrictor assembly" and makes the keyword a navigation link to the topic subassm-9414-C.dita.

Redirect a link or xref

Author 1 creates a map that associates keys with each topic, for example <topicref keys="a" href="a1.dita"/>

Author 1 creates topic c.dita that contains a related link to a0.dita - but uses the keyref attribute: <link keyref="a" href="a0.dita"/>

Author 2 reuses c.dita, but wants to redirect the link, so applies a different map with <topicref keys="a" href="a2.dita"/>. The link in c.dita now resolves to a2.dita when author 2 builds it (it continues to resolve to a1.dita when author 1 builds it)

Author 3 also reuses c.dita, but wants the link to point to an external resource, so creates an external-pointing topicref to resolve the key:
```
<topicref  keys="a" href="http://www.a..." scope="external">
  <topicmeta>
    <linktext>This links to A2</linktext>
    <shortdesc>Because it does.</shortdesc>
  </topicmeta>
</topicref>
```
The link in c.dita now resolves to an external URI reference when author 3 builds it (without affecting how it resolves for the other two reusers).

Author 4 wants to get rid of the link, so creates an explicitly empty topicref to get rid of it: <topicref keys="a"/>. This gets rid of the link for author 4 without affecting the other reusers.

Author 5 wants to turn the link into just plain text (not hypertext) - for example a citation of a print-only magazine article.
```
<topicref  keys="a">
  <topicmeta>
    <linktext>This is just text.</linktext>
  </topicmeta>
</topicref>
```

Author 6 reuses c.dita, but does not include a topicref that defines the key “a” in the map. Topic a0.dita is used as the “fallback” related link.

Redirect conref

Author 1 creates a map that associates a key with a topic that contains reusable elements, for example <topicref keys="reuse" href="prodA/reuse.dita"/>

Author 1 uses the key instead of the full href whenever creating conrefs - for example <p conkeyref="reuse/para1"/>

Author 2 wants to reuse author 1's content, but swap in a different set of reusable content. So Author 2 associates the key "reuse" with a different topic: <topicref keys="reuse" href="prodB/mytopic.dita"/>. So now <p conkeyref="reuse/para1"/> will resolve to a paragraph with the id “para1” in prodB/mytopic.dita when author 2 builds the content, while continuing to resolve to the para with the id “para1” in prodA/reuse.dita for author 1.

Create links from keywords, terms, or other elements

Author 1 creates a map that contains glossary entries, and associates keys for each entry: <topicref keys="myterm" href="myterm.dita"/>

Author 1 then uses the keys to create links to the appropriate glossary entry from occurrences of terms in content: <term keyref="myterm">my term</term>.

Note

The reusing author must create a parallel set of elements and IDs in the replacement topic; the element IDs within the topic are not remapped, only the pointer to the topic container.

Swap out variable content

Author 1 creates a map for key words and phrases that tend to change, such as UI labels and product names. The topicrefs do not in this case contain any actual hrefs, just the text that should be used:
```
<topicref keys="prodname">
  <topicmeta>
    <linktext>My Product</linktext>
  </topicmeta>
</topicref>
```

Author 1 then uses the keys to draw text into empty keywords: <keyword keyref="prodname"/>

Author 2 reuses the content but wants to use a different product name, so associates prodname with a different string:
```
<topicref keys="prodname">
  <topicmeta>
    <linktext>Another Product</linktext>
  </topicmeta>
</topicref>
```
The keyword now resolves to "Another Product" for author 2, while continuing to resolve to "My Product" for author 1.

Note

A processor should generate a warning message when a key reference on an empty element cannot be resolved, resulting in the element effectively being removed.

Splitting or combining targets

Author 1 creates a map in which most branches have the same structure: intro, example, reference. Two branches have only very little content in them, because the product support is only minimal. In anticipation of future elaboration, author 1 assigns 4 keys to the container under which more topics are expected in the future:
```
<topicref keys="blat-overview blat-intro blat-example blat-reference" 
          href="blat-overview.dita"/>
```
Author 2 references blat-example, and in the future when Author 1 moves blat-example into a separate topic, author 2's link remains appropriate and valid and does not need to be reworked.
Author 3 is reusing a bunch of author 1's content, but in a context where blats are not available, and are instead replaced by foobars. So author 3 simply adds the blat keys to their own foobar topicref:
```
<topicref keys="blat-overview blat-intro blat-example blat-reference foobar" 
          href="foobar.dita"/>
```

Removing a link

Author 1 creates a map which defines the key "overview":

<topicref keys="overview" 
          href="blat-overview.dita"/>

Author 1 adds a link to the topic productInfo.dita using they keyref attribute, and using the href as a fallback:
```
<link keyref="overview" href="blat-overview.dita"/>
```
Author 2 wishes to reuse productInfo.dita, but does not want a link to overview information. So, author 2 creates a new definition for the key overview that does not have a target:
```
<topicref keys="overview"/>
```
The link element which uses keyref="overview" is now removed, because there is no target and no link text.

2.2.1.3.4.4: Summary of addressing elements

This topic contains a table of DITA elements that may be used to link to or address other items. The table describes how and why each element uses the addressing mechanism, rather than defining the element itself.

DITA addressing elements

Base element type	Description and notes
topicref	Establishes a relationship between the containing map and another map, DITA topic, or non-DITA resource when @href or @keyref is specified. When @processing-role is "resource-only", establishes a dependency on the target resource but does not contribute to the navigation tree. May establish additional relationships between the referenced resource and other resources in the navigation hierarchy as determined by the values of the @collection-type attribute. By default, these additional relationships are bi-directional. The directionality of additional relationships can be controlled using the @linking attribute.
reltable	Establishes relations of a specific type (as defined by the relationship table) among topicref-linked resources where each row in the table establishes a single set of relationships among the topicref-linked resources in each cell of the row. Relationships defined in relationship tables are outside of any navigation structure defined by the map.
navref	Establishes a map-to-map relationship where the integration of the referenced map's navigation structure is deferred. The referenced map is processed independently from the referencing map and does not contribute to the referencing map's key space.
link	Establishes a link from its containing topic to another resource. Any <link> element within a topic can be functionally replaced by the equivalent link defined in a relationship table. Likewise, topic-to-topic links defined by relationship tables can be replaced by the equivalent set of <link> elements in the topics involved.
xref	Establishes a navigation link from a topic's abstract or body to another DITA element or non-DITA resource.
image	Links to an image for display at the point of reference.
object	Links to a media object for display at the point of reference.
longdescref	Links to a long description for an image or object. Can be used in place of the @longdescref attribute on the parent image or object element.
longquoteref	Links to the source of a long quotation. Used in place of the @href or @keyref attribute on <lq> and enables use of all the normal link-controlling attributes.
data-about	Establishes an explicit relationship between one or more <data> elements and the DITA element or non-DITA resource to which the data applies.
Elements that take @keyref but not @href	Elements that take @keyref but not @href establish navigation links to the referenced DITA element or non-DITA resource when @keyref is specified and the key is bound to a topic, map, or non-DITA resource. If the linking element has empty content and the key definition has a matching subelement in its <topicmeta>, establishes a use-by-reference relationship to the matchin element in the key definition. Includes <ph>, <cite>, <keyword>, and <term>.
imagemap (utilities domain)	Enables linking from defined areas overlaid on a graphic. Modeled on the HTML image map facility.
author	May link to a resource that represents the author in some way, such as a biographical topic or image.
data	May link to a resource that represents the metadata value in some way.
fragref (programming domain)	Links to a syntax definition fragment.
lq	May link to the source of the quotation.
publisher	May link to a resource that represents the publisher in some way, such as the Publisher's Web site or a publisher description topic.
source	May link to a description of the source for the topic to which the <source> element applies.
synnoteref (programming domain)	May link to a syntax note.
fn	Establishes a relationship between the content within which the footnote appears and the note itself, such that the footnote is an annotation of the content.

2.2.1.3.5: Content inclusion (conref)

The DITA @conref, @conkeyref, @conrefend, and related attributes provide a mechanism for reuse of content fragments within DITA topics or maps.

The @conref or @conkeyref attribute can be used to pull the referenced content into the location of the referencing element. The combination of either of these attributes with the @conrefend attribute can be used to pull the content of a range of elements.
The @conref attribute can be used in combination with the @conaction attribute to push content from the referencing element to the location of the referenced element.

Pulling content to the referencing element

When the @conref or @conkeyref attribute is used alone, the referencing element acts as a placeholder for the referenced element, and the content of the referenced element is rendered in place of the referencing element.

The combination of the @conrefend attribute with either @conref or @conkeyref specifies a range of sibling elements that is rendered in place of the referencing element. See The conrefend attribute for examples of how to combine @conrefend with either @conref or @conkeyref.

Pushing content from the referencing element

The @conaction attribute reverses the direction of reuse from pull to push. When the @conref or @conkeyref attribute is used in combination with the @conaction attribute, content can be rendered before, after, or in place of the referenced element, depending on the value of the @conaction attribute. See The conaction attribute for more details.

Note

The @conaction and @conrefend attributes cannot both be used within the same referencing element, so it is not possible to push a range of elements.

The identifier for the referenced element must be either absolute or resolvable in the context of the referencing element.

More formally, the DITA @conref attribute can be considered a transclusion mechanism similar to XInclude and to HyTime value references. DITA differs from these mechanisms, however, in that conref validity does not apply simply to the current content at the time of replacement, but to the ranges of possible content given the constraints of both the referencing document type and the referenced document type. DITA compares the constraints of each context to ensure the continued validity of the replacement content in its new context. A conref processor must not permit resolution of a reuse relationship that could be rendered invalid under the rules of either the reused or reusing content.

When pulling content with the conref mechanism – if the referenced element is the same type as the referencing element, and the list of domains declared on the domains attribute in the referenced topic or map instance is the same as or a subset of the list of domains declared in the referencing document, the element set allowed in the referenced element is guaranteed to be the same as, or a subset of, the element set allowed in the referencing element. A processor resolving a conref should tolerate specializations of valid elements and should generalize elements in the pulled content fragment as needed for the referencing context.

When pushing content with the conref mechanism, the domain checking algorithm is reversed. In this case, the domains attribute on the referenced document's topic or map must be the same as or a superset of the domains declared on the referencing document. Once again, a processor resolving a conref should tolerate specializations of valid elements and should generalize elements in the pushed content fragment as needed for the referenced context.

All replacement of content based on @conref occurs after parsing of the document but prior to any styling or other transformational or presentational operations on the full topic.

The referenced element may replace the referencing element based on build-time or runtime conditions. For example, content such as product names or install paths may differ from one product to another. It is advantageous to separate such content from topic content which is reused for more than one product. When the content is reused in a different context, different resources are substituted as reference elements.

A fragment of DITA content, such as an XML document containing only a single paragraph without a topic or map ancestor, does not contain enough information for the conref processor to be able to determine the validity of a reference to it. Consequently, the value of a conref must specify a referenced element within a DITA topic or DITA map (or it may point to the entire topic or map).

The attribute specifications on the resolved element can be drawn from both the referencing element and the referenced element, according to the following priority:

All attributes as specified on the referencing element, except for attributes which specify the value "-dita-use-conref-target". (The term "target" here refers to the referenced element.)
All attributes as specified on the referenced element except:
1. The id attribute
2. Any attribute that is also specified on the referencing element, except when the value specified on the referencing element is "-dita-use-conref-target"
The xml:lang attribute has special treatment as described in The @xml:lang attribute.

The only time the resolved element would include an attribute whose specified value is "-dita-use-conref-target" is when the referenced element had that attribute specified with the "-dita-use-conref-target" value and the referencing element either had no specification for that attribute or had it also specified with the "-dita-use-conref-target" value. If the final resolved element (after the complete resolution of any conref chain, as explained below) has an attribute with the "-dita-use-conref-target" value, that should be treated as equivalent to having that attribute unspecified.

A given attribute value on the resolved element comes in its entirety from either the referencing element or the referenced element; the attribute values of the referencing and referenced elements for a given attribute are never additive, even if the property (such as the audience type) takes a list of values.

If the referenced element has a @conref attribute specified, the above rules should be applied recursively with the resolved element from one referencing/referenced combination becoming one of the two elements participating in the next referencing/referenced combination. The result should preserve without generalization all elements that are valid in the originating context, even if they are not valid in an intermediate context. For example, if topicA and topicC allow highlighting, and topicB does not, then a content reference chain of topicA->topicB->topicC should preserve any highlighting elements in the referenced content. The result, however it is achieved, must be equivalent to the result of resolving the conref pairs recursively starting from the original referencing element in topicA.

The @conrefend attribute is used when referencing a range of elements with the conref mechanism. The @conref attribute references the first element in the range, while @conrefend points to the last element in the range. Although the start and end referenced elements must both be of the same type as the referencing element (or specialized from that element type), the intermediary, contiguous nodes in the middle of the range do not have to be the same.

2.2.1.3.6: Conditional processing (profiling)

Attribute-based profiling, also known as conditional processing or applicability, is the use of classifying metadata that enables the filtering, flagging, searching, indexing, and other processing based on the association of an element with one or more values in a specific classification domain.

DITA defines attributes that are specifically intended to enable filtering or flagging of individual elements. Those attributes are @audience, @platform, @product, @otherprops, @props, and @rev (flagging only). This enables the creation of topics and maps that can be dynamically configured at processing time to reflect a specific set of conditions, using the DITA-defined conditional processing profile (DITAVAL).

Processors should be able to perform filtering and flagging using the attributes listed above. Although metatdata elements exist with similar names, such as the <audience> element, processors are not required to perform conditional processing using metadata elements. The @props attribute can be specialized to create new attributes, and processors should be able to perform conditional processing on specializations of @props.

Conditional processing attributes

For a topic or topicref, the audience, platform, and product metadata can be expressed with attributes on the topic or topicref element or with elements within the topic prolog or topicmeta element. While the metadata elements are more expressive, the meaning of the values is the same, and can be used in coordination. For example, the prolog elements can fully define the audiences for a topic, and then metadata attributes can be used within the content to identify parts that apply to only some of those audiences.

audience

The values in the audience attribute may also be used to reference a more complete description of an audience in an audience element. Use the name of the audience in the audience element when referring to the same audience in an audience attribute.

The audience attribute takes a space-delimited list of values, which may or may not match the name value of any audience elements.

platform

The platform might be the operating system, hardware, or other environment. This attribute is equivalent to the platform element for the topic metadata.

The platform attribute takes a space-delimited list of values, which may or may not match the content of a platform element in the prolog.

product

The product or component name, version, brand, or internal code or number. This attribute is equivalent to the prodinfo element for the topic metadata.

The product attribute takes a space-delimited list of values, which may or may not match the value of the prodname element in the prolog.

rev

The identifier for the revision level. For example, if a paragraph was changed or added during revision 1.1, the rev attribute might contain the value "1.1".

otherprops

A catch-all for metadata qualification values about the content. This attribute is equivalent to the othermeta element for the topic metadata.

The attribute takes a space-delimited list of values, which may or may not match the values of othermeta elements in the prolog.

For example, a simple otherprops value list: <codeblock otherprops="java cpp">

MP: deprecated grouped value syntax per TC meeting 2007/01/02

The attribute may take labeled groups of values as for @props. Processors may treat such values as equivalent to @props or they may treat such values as simple strings. The use of labeled groups in @otherprops is deprecated in favor of using specializations of @props. Processors should clearly document how they treat grouped @otherprops values. See Attribute generalization for details on generalized @props attribute values.

props

A generic attribute for conditional processing values. Starting with DITA 1.1, the props attribute can be specialized to create new conditional processing attributes. See Attribute generalization.

Using conditional processing attributes

Each attribute takes zero or more space-delimited string values. For example, you can use the product attribute to identify that an element applies to two particular products.

Example source

<p audience="administrator">Set the configuration options:
    <ul>
        <li product="extendedprod">Set foo to bar</li>
        <li product="basicprod extendedprod">Set your blink rate</li>
        <li>Do some other stuff</li>
        <li platform="Linux">Do a special thing for Linux</li>
    </ul>
</p>

Evaluating conditional processing attributes

At processing time, a DITAVAL conditional processing profile may be used to specify values you want to include, exclude, or flag.

For example, a publisher producing information for a mixed audience using the basic product could choose to flag information that applies to administrators, and exclude information that applies to the extended product, by defining a conditional processing profile like this:

<val>
  <prop att="audience" val="administrator" action="flag">
    <startflag><alt-text>ADMIN</alt-text></startflag>
  </prop>
  <prop att="product" val="extendedprod" action="exclude"/>
</val>

At output time, the paragraph is flagged, and the first list item is excluded (since it applies to extendedprod), but the second list item is still included (even though it does apply to extendedprod, it also applies to basicprod, which was not excluded).

The result should look something like:

ADMIN Set the configuration options:

Set your blink rate
Do some other stuff
Do a special thing for Linux

Filtering logic

By default, values in conditional processing attributes that are not defined in a DITAVAL profile evaluate to "include". For example, if the value audience="novice" is used on a paragraph, but this value is not defined in a DITAVAL profile, the attribute evaluates to "include". However, the DITAVAL profile may change this default to "exclude", so that any value not explicitly defined in the DITAVAL profile will evaluate to "exclude". The profile may also be used to change the default for a single attribute; for example, it may declare that values in the platform attribute default to exclude while those in the product attribute default to include. See DITAVAL elements for information on how to set up a DITAVAL profile and how to change default behaviors.

When deciding whether to include or exclude a particular element, a processor should evaluate each attribute, and then evaluate the set of attributes.

If all the values in a single attribute evaluate to "exclude", the attribute evaluates to "exclude".
If any single attribute evaluates to exclude, the element is excluded.

For example, if a paragraph applies to three products and the publisher has chosen to exclude all of them, the processor should exclude the paragraph. This is true even if the paragraph applies to an audience or platform that is not excluded. But if the paragraph applies to an additional product that has not been excluded, then its content is still relevant for the intended output and should be preserved.

Flagging logic

When deciding whether to flag a particular element, a processor should evaluate each value. Wherever a value that has been set as flagged appears in its attribute (for example, audience="administrator") the process should add the flag. When multiple flags apply to a single element, multiple flags should be rendered, typically in the order they are encountered.

Flagging could be done using text (for example, bold text against a colored background) or using images. When the same element evaluates as both flagged and filtered (for example, flagged because of an audience attribute value and filtered because of its product attribute values), the element should be filtered.

2.2.1.3.7: Chunking

Content may be chunked (divided or merged into new output documents) in different ways for the purposes of authoring, for delivering content, and for navigation. For example, something best authored as a set of separate topics may need to be delivered as a single Web page. A map author can use the chunk attribute to split up multi-topic documents into component topics or combine multiple topics into a single document as part of output processing.

Examples of use

Here are some examples of potential uses of the chunk attribute:

Reuse of a nested topic: A content provider creates a set of topics as a single document. Another user wants to incorporate only one of the nested topics from the document. The new user can reference the nested topic from a DITA map, using the chunk attribute to specify that the topic should be produced in its own document.
Identification of a set of topics as a unit: A curriculum developer wants to compose a lesson for a SCORM LMS (Learning Management System) from a set of topics without constraining reuse of those topics. The LMS can save and restore the learner's progress through the lesson if the lesson is identified as a referenceable unit. The curriculum developer defines the collection of topics with a DITA map, using the chunk attribute to identify the learning module as a unit before generating the SCORM manifest.

Using the chunk attribute

When a set of topics is processed for output using a map, the map author may use the chunk attribute to override whatever default chunking behavior is set by the processor. The chunk attribute allows the map author to request that multi-topic documents be be broken into multiple documents, and that multiple individual topics be combined into a single document.

Chunking is necessarily output processor specific with chunked output required for some and not supported for other types of output. Chunking is also implementation specific with some implementations supporting some, but not all, chunking methods, or adding new implementation specific chunking methods to the standard methods described in this specification.

The value of the chunk attribute consists of one or more space delimited tokens. Tokens are defined in three categories: for selecting topics, for setting chunking policies, and for defining how the chunk values impact rendering. It is an error to use two tokens from the same category on a single topicref element.

Selecting topics

These values describe what portion of a target document is referenced. Such tokens are only useful when addressing a document that is made up of multiple topics. These values are ignored when the element on which they are specified does not reference a topic. Recognized values include:

select-topic : The "select-topic" token is used to select an individual topic without any ancestors, descendents, or peers from within the same document.
select-document : The "select-document" token is used to select the target topic together with all ancestors, descendents, and peers within the target document.
select-branch : The "select-branch" token is used to select the target topic together with its descendents.

Policies for splitting or combining documents

Two tokens are defined for setting chunking policies. Each token applies only to the current topicref or topicref specialization, except when used on the map element, in which case the value establishes a policy for the entire map.

by-topic : The "by-topic" token establishes a policy for the current topicref (or topicref specialization) where a separate output chunk is produced for each of the selected topics.
by-document : The "by-document" token establishes a policy for the current topicref (or topicref specialization) where a single output chunk is produced for the referenced topic or topics.

Rendering the selection

The following tokens affect how the chunk values impact rendering of the map or topics.

to-content : The "to-content" token indicates that the selection should be rendered as a new chunk of content.
- When specified on a topicref or topicref specialization, this means that the topics selected by this topicref and its children will be rendered as a single chunk of content.
- When specified on the map element, this indicates that the contents of all topics referenced by the map are to be rendered as a single document.
- When specified on a topicref or topicref specialization that contains a title but no target, this indicates that a title-only topic must be generated in the rendered result, along with any topics referenced by child topicrefs (and topicref specializations) of this topicref. The rendition address of the generated topic is determined as defined for the copy-to attribute. If the copy-to attribute is not specified and the topicref has no id attribute, the address of the generated topic is not required to be predictable or consistent across rendition instances.
For cross references to topicref elements, if the value of the chunk attribute is "to-content" or is unspecified, the cross reference is treated as a reference to the target topic. If the reference is to a topicref with no target, it is treated as a reference to the generated title-only topic.
to-navigation : The "to-navigation" token indicates that a new chunk of navigation should be used to render the current selection (such as an individual Table of Contents or related links). When specified on the map element, this token indicates that the map should be presented as a single navigation chunk. If a cross reference is made to a topicref that has a title but no target, and the chunk value of that topicref is set to "to-navigation", the resulting cross reference is treated as a reference to the rendered navigation document (such as an entry in the table of contents).

Some tokens or combinations of tokens may not be appropriate for all output types. When unsupported or conflicting tokens are encountered during output processing, warning or error messages should be produced. Recovery from such conflicts or other errors is implementation dependent.

There is no default value for the chunk attribute and the chunk attribute does not cascade from container elements, meaning that the chunk value on one topicref is not passed to its children. A default by-xxx policy for an entire map may be established by setting the chunk attribute on the map element, which will apply to any topicref that does not specify its own by-xxx policy.

When no chunk attribute values are given, chunking behavior is implementation dependent. When variations of this sort are not desired, a default for a specific map may be established by including a chunk attribute value on the map element.

When creating new documents via chunk processing, the storage object name or identifier (if relevant) is determined as follows:

If an entire map is used to generate a single chunk (by placing to-content on the map element), the name is taken from the name of the map.
If the @copy-to attribute is specified, the name is taken from the @copy-to attribute.
If @copy-to is not specified and the by-topic policy is in effect, the name is taken from the @id attribute of the topic.
If @copy-to is not specified and the by-document policy is in effect, the name is taken from the name of the referenced document.

Examples

In the examples below, an extension of ".xxxx" is used in place of the actual extensions that will vary by output format. For example, when the output format is HTML, the extension may actually be ".html", but this is not required.

The examples below assume the existence of the following files:

parent1.dita, parent2.dita, etc., each containing a single topic with id P1, P2, etc.
child1.dita, child2.dita, etc., each containing a single topic with id C1, C2, etc.
grandchild1.dita, grandchild2.dita, etc., each containing a single topic with id GC1, GC2, etc.
nested1.dita, nested2.dita, etc., each containing two topics: parent topics with id N1, N2, etc., and child topics with ids N1a, N2a, etc.

ditabase.dita, with the following contents:

<dita xml:lang="en-us">
  <topic id="X">
    <title>Topic X</title><body><p>content</p></body>
  </topic>
  <topic id="Y">
    <title>Topic Y</title><body><p>content</p></body>
    <topic id="Y1">
      <title>Topic Y1</title><body><p>content</p></body>
      <topic id="Y1a">
       <title>Topic Y1a</title><body><p>content</p></body>
      </topic>
    </topic>
    <topic id="Y2">
      <title>Topic Y2</title><body><p>content</p></body>
    </topic>
  </topic>
  <topic id="Z">
    <title>Topic Z</title><body><p>content</p></body>
    <topic id="Z1">
      <title>Topic Z1</title><body><p>content</p></body>
    </topic>
  </topic>
</dita>

The following map causes the entire map to generate a single output chunk.

<map chunk="to-content"> 
   <topicref href="parent1.dita"> 
      <topicref href="child1.dita"/> 
      <topicref href="child2.dita"/> 
   </topicref> 
</map>

The following map will generate a separate chunk for every topic in every document referenced by the map. In this case, it will result in the topics P1.xxxx, N1.xxxx, and N1a.xxxx.
```
<map chunk="by-topic"> 
   <topicref href="parent1.dita"> 
      <topicref href="nested1.dita"/> 
   </topicref> 
</map> 
```
The following map will generate two chunks: parent1.xxxx will contain only topic P1, while child1.xxxx will contain topic C1, with topics GC1 and GC2 nested within C1.
```
<map> 
   <topicref href="parent1.dita"> 
      <topicref href="child1.dita" chunk="to-content"> 
        <topicref href="grandchild1.dita"/>
        <topicref href="grandchild2.dita"/>
      </topicref>
   </topicref> 
</map> 
```
The following map breaks down portions of ditabase.dita into three chunks. The first chunk Y.xxxx will contain only the single topic Y. The second chunk Y1.xxxx will contain the topic Y1 along with its child Y1a. The final chunk Y2.xxxx will contain only the topic Y2. For navigation purposes, the chunks for Y1 and Y2 are still nested within the chunk for Y.
```
<map>
  <topicref href="ditabase.dita#Y" copy-to="Y.dita"
            chunk="to-content select-topic">
    <topicref href="ditabase.dita#Y1" copy-to="Y1.dita"
              chunk="to-content select-branch"/>
    <topicref href="ditabase.dita#Y2" copy-to="Y2.dita"
              chunk="to-content select-topic"/>
  </topicref>
</map>
```
The following map will produce a single output chunk named parent1.xxxx, containing topic P1, with topic Y1 nested within P1, but without topic Y1a.
```
<map chunk="by-document"> 
   <topicref href="parent1.dita" chunk="to-content"> 
      <topicref href="ditabase.dita#Y1" 
         chunk="select-topic"/> 
   </topicref> 
</map> 
```
The following map will produce a single output chunk, parent1.xxxx, containing topic P1, topic Y1 nested within P1, and topic Y1a nested within Y1.
```
<map chunk="by-document"> 
   <topicref href="parent1.dita" chunk="to-content"> 
      <topicref href="ditabase.dita#Y1" 
         chunk="select-branch"/> 
   </topicref> 
</map> 
```
The following map will produce a single output chunk, P1.xxxx. The topic P1 will be the root topic, and topics X, Y, and Z (together with their descendents) will be nested within topic P1.
```
<map chunk="by-topic"> 
   <topicref href="parent1.dita" chunk="to-content"> 
      <topicref href="ditabase.dita#Y1" 
         chunk="select-document"/> 
   </topicref> 
</map> 
```
The following map will produce a single output chunk named parentchunk.xxxx containing topic P1 at the root. Topic N1 will be nested within P1, and N1a will be nested within N1.
```
<map chunk="by-document"> 
   <topicref href="parent1.dita" chunk="to-content" copy-to="parentchunk.dita"> 
      <topicref href="nested1.dita" chunk="select-branch"/> 
   </topicref> 
</map> 
```

The following map will produce two output chunks. The first chunk named parentchunk.xxxx will contain the topics P1, C1, C3, and GC3. The "to-content" token on the reference to child2.dita causes that branch to begin a new chunk named child2chunk.xxxx, which will contain topics C2 and GC2.

<map chunk="by-document"> 
   <topicref href="parent1.dita" 
      chunk="to-content" copy-to="parentchunk.dita"> 
      <topicref href="child1.dita" chunk="select-branch"/> 
      <topicref href="child2.dita" 
         chunk="to-content select-branch" 
         copy-to="child2chunk.dita"> 
         <topicref href="grandchild2.dita"/> 
      </topicref> 
      <topicref href="child3.dita"> 
         <topicref href="grandchild3.dita" 
            chunk="select-branch"/> 
      </topicref> 
   </topicref> 
 </map>

The following map produces a single chunk named nestedchunk.xxxx, which contains topic N1 with no topics nested within.
```
<map> 
   <topicref href="nested1.dita#N1" 
             copy-to="nestedchunk.dita" 
             chunk="to-content select-topic"/> 
</map> 
```

The following map will produce two navigation chunks, one for P1, C1, and the other topic references nested under parent1.dita, and a second for P2, C2, and the other topic references nested under parent2.dita.

<map> 
    <topicref href="parent1.dita" 
          navtitle="How to set up a web server"
          chunk="to-navigation"> 
       <topicref href="child1.dita" 
          chunk="select-branch"/> 
       <!-- ... -->
    </topicref> 
    <topicref href="parent2.dita" 
          navtitle="How to ensure database security"
          chunk="to-navigation"> 
       <topicref href="child2.dita" 
          chunk="select-branch"/> 
       <!-- ... -->
    </topicref> 
    <!-- ... -->
</map>

Implementation-specific tokens and future considerations

Additional chunk tokens may be added to the DITA Standard in the future. In addition, implementers may define their own custom, implementation-specific tokens. To avoid name conflicts between implementations or with future additions to the standard, implementation-specific tokens should consist of a prefix that gives the name or an abbreviation for the implementation followed by a colon followed by the chunking method name. For example: “acme:level2” could be a token for the Acme DITA Toolkit that requests the “level2” chunking method.

2.2.1.3.8: Printing

By default, the content of most elements is included in all output media. The DITA map provides a means to suppress element content from appearing in print-oriented media, or from appearing in non-print-oriented media, such as HTML. The generation or non-generation of print and other forms of output can also be affected through the use of other navigation-related attributes.

The author can specify whether individual topics or groups of topics referenced in a DITA map should be included for processing to print-oriented outputs such as PDF. Each map (or map specialization) and topicref (or topicref specialization) in a DITA map supports the attributes @toc, @processing-role, and @print. The @print attribute supports the following enumerated values, each controlling the way that print-oriented processors handle the inclusion or exclusion of topics or groups of topics.

@print value	Print-oriented Processing	Non-print-oriented Processing
unspecified (default) Example: <topicref href="foo.dita">	Topics referenced by the map element are included in output.	Topics referenced by the map element are included in output.
yes Example: <topicref href="foo.dita" print="yes">	Topics referenced by the map element are included in output.	Topics referenced by the map element are included in output.
printonly Example: <topicref href="foo.dita" print="printonly">	Topics referenced by the map element are included in output.	Topics referenced by the map element are excluded in output.
no Example: <topicref href="foo.dita" print="no">	Topics referenced by the map element are excluded in output.	Topics referenced by the map element are included in output.
-dita-use-conref-target Example: <topicref conref="#foo-topic" print="-dita-use-conref-target">	Topics referenced by the map element derive a value for @print from the @print value of the referenced map element. See Using the -dita-use-conref-target value for more details on this value.	Topics referenced by the map element derive a value for @print from the @print value of the referenced map element. See Using the -dita-use-conref-target value for more details on this value.

Note

If a value for @print is not specified explicitly in a map element, but is specified in a map that references the map element, the @print value cascades to the referenced map. If the @print value is not specified on the referencing map, a default of "yes" is assumed.

Use @print="printonly" to identify transitional topics to be included exclusively in highly contextual or linear print-oriented output.

If the referenced topic should be excluded from all output formats, set the @processing-role attribute to "resource-only" instead of using the @print attribute. Content within that topic may still be referenced for display in other locations.

2.2.1.3.9: Translation and localization

DITA has features that facilitate preparing content for translation and working with multilingual content, including the @xml:lang attribute, the @dir attribute, and the @translate attribute. In addition, the <index-sort-as> element provides support for index sorting in languages in which the index sort order must be modified by the author or translator.

2.2.1.3.9.1: The @xml:lang attribute

The @xml:lang attribute specifies the language (and optionally the locale) of the element content. The @xml:lang attribute applies to all attributes and content of the element where it is specified, unless it is overridden with @xml:lang on another element within that content. If the @xml:lang attribute on the document (outermost) element of a map or of a top-level topic has no value, the processor should assume a default value. The default value of the processor may be either fixed, configurable, or derived from the content itself, such as the @xml:lang attribute on the primary map file. As the default value of a processor may be fixed, it is strongly recommended that the @xml:lang attribute be set on each map and top-level topic.

The @xml:lang attribute is described in the XML Recommendation at http://www.w3.org/TR/REC-xml/#sec-lang-tag. Note that the recommended style for the @xml:lang attribute is lower case language and uppercase locale (if used), separated by a hyphen, i.e., en-US or sp-SP.

Use in maps

The @xml:lang attribute can be specified on the <map> element. The @xml:lang attribute cascades within the map the same way that it cascades within a topic. The @xml:lang value does not cascade from one map to another or from a map to a topic, and an @xml:lang value specified in a map does not override @xml:lang values specified in other maps or in topics.

The primary language for the map should be set on the <map> element. The specified language should remain in effect for all child <topicref> elements, unless a child specifies a different value for the @xml:lang attribute.

When no @xml:lang value is supplied locally or on an ancestor, a processor determined default value is assumed.

Use with the @conref or @conkeyref attribute

When a @conref or @conkeyref attribute is used to include content from one element into another, the processor must use the effective value of the @xml:lang attribute from the referenced element, that is, the element that contains the content. If the reference element does not have an explicit value for the @xml:lang attribute, the effective value for its @xml:lang attribute is determined by using the standard @xml:lang inheritance from the referenced source.. If this action results in no effective value for @xml:lang, the processor should default to using the same value that is used for topics that do not set the @xml:lang attribute.

This behavior is shown in the following example, where the value of the @xml:lang attribute of the included note is obtained from its parent <section> element (id="qqwwee") that sets the @xml:lang attribute. In this example, the @xml:lang value "fr" is applied to the note with the id attribute "mynote".

<-- ****************installingAcme.dita********************* -->
                
<?xml version="1.0"?>
<!DOCTYPE topic PUBLIC "-//OASIS//DTD DITA Topic//EN" "topic.dtd">
<topic xml:lang="en" id="install_acme">
 <title>Installing Acme</title>
 <shortdesc>Step-by-step details about how to install Acme.</shortdesc>
 <body>
  <section>
   <title>Before you begin</title>
   <p>Special notes when installing Acme in France:</p>
   <note conref="warningsAcme.dita#topic_warnings/frenchwarnings"></note>
  </section>
 </body>
</topic>
</dita>
*******************************************

<-- **************** warningsAcme.dita ********************* -->
<?xml version="1.0"?>
<!DOCTYPE topic PUBLIC "-//OASIS//DTD DITA Topic//EN" "topic.dtd">
<topic id="topic_warnings">
 <title>Warnings</title>
 <body>
  <section id="qqwwee" xml:lang="fr">
   <title>French warnings</title>
   <p>These are our French warnings.</p>
   <note id="frenchwarnings">Note in French!</note>
  </section>
  <section xml:lang="en">
   <title>English warnings</title>
   <p>These are our English warnings.</p>
   <note id="englishwarnings">Note in English!</note>
  </section>
 </body>
</topic>
*************************************

2.2.1.3.9.2: The dir attribute

The dir attribute provides direction about how processors should render bidirectional text. Languages such as Arabic, Hebrew, Farsi, Urdu, and Yiddish have text written from right to left. Numerics and embedded sections of Western language text, however, are written from left to right. Some multilingual documents also contain a mixture of text segments in two directions. This attribute specifies how such text should be rendered to a reader.

Bidirectional text processing is controlled by several factors:

The xml:lang attribute may be used to identify text that requires bidirectional rendering. The Unicode Bidirectional algorithm provides the means to properly identify western content in mixed text.
The dir attribute may be set on the root element, in combination with the xml:lang attribute. For example, to correctly set in a web browser a text in Arabic with embedded English content, the root element should be set with xml:lang="ar" and dir="rtl". All text, including punctuation marks, will be set correctly.
The dir attribute may be set to either "ltr" or "rtl" on an element in the document.
JTH: 21 Sept 2009; changed dir values to all uppercase to conform with the reference below.

RDA 29 Jan 2010: changed back to lower case to conform with the DTD (upper case values are invalid in DITA content). Also added quotes to further clarify that these are attribute values.
The dir attribute may be set to either "lro" or "rlo" on an element in the document.

The Unicode bidirectional algorithm positions the punctuation correctly for a given language. The rendering is responsible for displaying the text properly.

The use of the dir attribute and the Unicode algorithm is explained in the article Specifying the direction of text and tables: the dir attribute (http://www.w3.org/TR/html4/struct/dirlang.html#adef-dir) . This article contains several examples of how to use the dir attribute set to either left-to-right or right-to-left. There is no example of setting the dir attribute to either "lro" or "rlo", although it can be inferred from the example that uses the <bdo> element, a now-deprecated W3C mechanism for overriding the entire Unicode bidirectional algorithm.

Note that properly written mixed text does not need any special markers. The Unicode bidirectional algorithm is sufficient. However, some rendering systems may need directions for displaying bidirectional text, such as Arabic, properly. For example, the Apache FOP tool may not render Arabic properly unless the left-to-right and right-to-left indicators are used.

Recommended usage

The dir attribute, together with the xml:lang attribute, is essential for rendering table columns and definition lists <dl> to ensure proper order.

In general text, the Unicode Bidirectional algorithm, as specified by the xml:lang attribute together with the dir attribute, provides for various levels of bidirectionality, as follows:

Directionality is either explicitly specified via the xml:lang attribute in combination with the dir attribute on the highest level element (topic or derived peer for topics, map for ditamaps) or assumed by the processing application. If used, it is recommended to specify the dir attribute on the highest level element in the topic or document element of the map.
When embedding a right-to-left text run inside a left-to-right text run (or vice-versa), the default direction may provide incorrect results based on the rendering mechanism, especially if the embedded text run includes punctuation that is located at one end of the embedded text run. Unicode defines spaces and punctuation as having neutral directionality and defines directionality for these neutral characters when they appear between characters having a strong directionality (most characters that are not spaces or punctuation). While the default direction is often sufficient to determine the correct directionality of the language, sometimes it renders the characters incorrectly (for example, a question mark at the end of a Hebrew question may appear at the beginning of the question instead of at the end or a parenthesis may render incorrectly). To control this behavior, the dir attribute is set to "ltr" or "rtl" as needed, to ensure that the desired direction is applied to the characters that have neutral bidirectionality. The "ltr" and "rtl" values override only the neutral characters (e.g. spaces and punctuation), not all Unicode characters.

Note

Problems with Unicode rendering may be caused by the rendering mechanism. The problems are not due to the XML markup itself.
Sometimes you may want to override the default directionality for strongly bidirectional characters. Overrides are done using the "lro" and "rlo" values, which overrides the Unicode Bidirectional algorithm. This override forces a direction on the contents of the element. These override attributes give the author a brute force way of setting the directionality independent of the Unicode Bidirectional algorithm. The gentler "ltr" and "rtl" values have a less radical effect, only affecting punctuation and other so-called neutral characters.

For most authoring needs, the "ltr" and "rtl" values are sufficient. Only when the desired effect cannot be achieved using these values, should the override values be used.

Implementation precautions

Applications that process DITA documents, whether at the authoring, translation, publishing, or any other stage, should fully support the Unicode bidirectional algorithm to correctly implement the script and directionality for each language used in the document.

Applications should ensure every highest level topic element and the root map element explicitly assign the dir attribute, as well as the xml:lang attribute.

2.2.1.4: Configuration, specialization, and constraints

The extension facilities of DITA allow existing vocabulary and constraint modules to be combined to create specific DITA document types. Additionally, vocabulary modules can be extended to create more-specialized markup to meet new requirements not satisfied by existing markup.

2.2.1.4.1: Overview of DITA extension facilities

DITA provides three extension facilities: configuration of the vocabulary modules used by DITA document types, constraint of base content models and attribute lists, and creation of new element and attribute types (specialization).

Configuration enables the definition of DITA document types that include only those vocabulary modules required for a given set of documents without the need to modify the vocabulary modules in any way. Configurations are implemented as document type shells.

Constraint enables the unilateral modification of content models and attribute lists for individual elements without modifying the base vocabulary modules involved, in the context of a specific configuration. Constraints are implemented as constraint modules, which are integrated into document type shells.

Specialization enables the creation of new element types in a way that preserves the ability to blindly interchange those new element types with any conforming DITA application. Specializations are implemented as vocabulary modules, which are then integrated into any number of document type shells.

Specialization hierarchies are implemented as sets of vocabulary modules, each of which declares the markup and entities that are unique to a specialization. The separation of the markup vocabulary and its implementing declarations into modules makes it easy to extend the hierarchy, because new modules can be added without affecting existing document types. It also makes it easy to assemble design elements from different sources into a single integrated document type shell and makes it easy to reuse specific parts of the specialization hierarchy in more than one document type shell.

DITA documents are governed by DITA document types that represent the combination of one or more structural types (maps or topics), domain vocabularies, and constraint modules that define the set of element types and attributes available to a specific document. In short, DITA provides a framework by which XML vocabulary and constraint modules can be combined in an infinite number of ways to create specific document types, as well as a set of base modules that serve as the base for further configuration, constraint, or specialization.

DITA documents are typically governed by a conforming DITA document type shell as defined in this section. However, the conformance of a DITA document is a function of the document instance, not its governing schema. Therefore conforming DITA documents are not required to use a conforming document type shell.

Conforming DITA documents are not required to have any governing document type declaration or schema. In addition, there may compelling or practical reasons to use non-conforming document type shells. For example, a document might use a document type shell that does not conform to the DITA requirements for shells in order to meet the needs of a specific tool, but the document can still be a conforming DITA document and, if the document type only allows content and attributes that are conforming, it can ensure that the documents it governs are conforming DITA documents even though the document type itself does not conform to the requirements for DITA document type shells. That is, there can be document type shells that do not conform to the coding requirements for document shells that can still ensure the creation of conforming DITA documents. There can also be document type shells that do not conform to the coding requirements for document type shells and that allow, but do not ensure, the creation of conforming DITA documents.

2.2.1.4.1.1: Recognized XML document constraint mechanisms

The DITA standard currently recognizes two XML document grammar mechanisms by which conforming DITA vocabulary modules and document types may be constructed: document type declarations (DTDs) and XML Schema declarations (XSDs).

This specification defines implementation requirements for both of these document constraint mechanisms. The OASIS DITA Technical Committee recognizes that other XML grammar languages might provide similar modularity and extensibility mechanisms. However, the Technical Committee has not yet defined implementation requirements for those languages so their conformance cannot be determined.

2.2.1.4.2: Configuration (Document type shells)

A given DITA map or topic document is governed by a DITA document type that defines the set of structural modules (topic or map types), domain modules, and constraints modules that the map or topic can use.

The DITA document type is defined entirely by the set of modules declared on the @domains attribute of the document's root element and by the values of the @class attributes of all the elements in the document. If the @domains attribute declares both structural and domain vocabulary modules, then the @domains attribute by itself serves to define the DITA document type. The information on the @domains and @class attributes is sufficient to implement all DITA-defined processing and constraint checking on documents (for example, determining if a referenced element in a content reference has a set of modules compatible with the modules used by the referencing element's document).

Thus, DITA does not require that conforming DITA documents have an associated DTD, XSD, or other formal document type definition as long as all required attributes are explicit in document instances. However, most DITA documents have an associated DTD or XML schema document by which the documents can be validated using normal XML processors and that can provide default values for the @domains and @class attributes, in particular. In addition, while the DITA specification only defines coding requirements for DTDs and XML schema documents, conforming DITA documents may use other document type constraint languages, such as RelaxNG or Schematron.

Per the coding requirements for DITA document types, document type shells are always implemented as a top-level file that only includes and configures vocabulary modules—they never directly define new element or attribute types.

Two document type shells define the same DITA document type if they integrate the same set of vocabulary and constraint modules. For example, a shell document type that is an unmodified copy of the OASIS-provided topic document type shell (topic.dtd or topic.xsd) defines the same DITA document type as the original but, because it is a distinct file, has a distinct system identifier (because it is not a replacement for the OASIS-provided shell but a copy of it, which must be stored in a different location) and must have a unique public identifier if a public identifier is associated with it. In particular, for document type shells not created by OASIS, the public identifier or URN for the document type shell must not indicate OASIS as the owner and should reflect the owner or creator of the document type shell. For example, if example.com creates a copy of the topic.dtd document type shell for its own use, an appropriate public identifier would be "-//example.com//DTD DITA Topic//EN", where "example.com" is the owner identifier component of the public identifier. An appropriate URN would be "urn:example.com:names:dita:xsd:topic.xsd".

Note

The public or system identifier associated with a given document type shell is not, by itself, necessarily distinguishing. This is because two different shell document types, owned by different owners, may define the same DITA document type as indicated by the effective value of the @domains attribute.

While the DITA specification includes a starter set of document type shells for common combinations of modules, those document type shells are not mandatory.

Note

Even if an initial implementation does not require configuration, constraint, or specialization, it can be useful to create new shell document types. That way, if modification is required in the future, documents will not need to be modified to point to a new shell document type.

DITA document type shells must follow the coding requirements defined in this specification. This ensures consistency of implementation and also serves to make the task of creating document type shells almost entirely mechanical.

2.2.1.4.2.1: DTD document-type shell: Coding requirements

A document type shell integrates one or more topic type or map type modules, zero or more domain modules, and zero or more constraint modules. A DTD document type shell is organized into sections, where each section contains a specific type of declaration.

DTD document type shells may not directly declare element types or attributes. A DTD document type shell must conform to the following coding requirements.

Each section of the shell is introduced by a comment. Shells should use these comments to identify each section of the shell. Each section should be present in the shell DTD, even if the section contains no declarations, and must occur in the order they are presented here. The ordering is required by the XML rules for entity declaration precedence and also serve to enable automatic shell creation and modification. Shells should have an initial set of comments that describe the shell and indicate the public identifiers, URNs, or absolute URLs by which the shell should be referenced in DOCTYPE declarations.

Topic or map entity inclusions

The topic or map entity declarations section includes the .ent file for the top-level topic or map type the shell is configuring.

Topic shells should use the comment:

<!-- ============================================================= -->
<!--                    TOPIC ENTITY DECLARATIONS                  -->
<!-- ============================================================= -->

Map shells should use the comment:

<!-- ============================================================= -->
<!--                    MAP ENTITY DECLARATIONS                    -->
<!-- ============================================================= -->

This section must declare and reference as an external parameter entity the .ent file for the topic or map module where the entity is named %typename-dec. For example:

<!ENTITY % concept-dec     
  PUBLIC "-//OASIS//ENTITIES DITA 1.2 Concept//EN" 
         "concept.ent"
>%concept-dec;

Domain entity inclusions

The domain entity inclusions section includes the entity declaration files for each element domain integrated by the document type. This section should use the comment:

<!-- ============================================================= -->
<!--                    DOMAIN ENTITY DECLARATIONS                 -->
<!-- ============================================================= -->

For each element domain included in the shell, this section must declare an external parameter entity for the domain's entity declaration file and immediately reference the entity. The entity name for the domain declaration consists of the domain name plus the dec suffix. In the following example, the entity file for the highlight domain is included in the document type shell:

<!ENTITY % hi-d-dec PUBLIC
    "-//OASIS//ENTITIES DITA Highlight Domain//EN" 
    "highlightDomain.ent"
>%hi-d-dec;

Domain attribute inclusions

The domain attribute inclusions section includes the entity declaration files for each attribute domain integrated by the document type. This section should use the comment:

<!-- ============================================================= -->
<!--                    DOMAIN ATTRIBUTE DECLARATIONS              -->
<!-- ============================================================= -->

For each attribute domain included in the shell, this section must declare an external parameter entity for the domain's entity declaration file and immediately reference the entity. The entity name for the domain declaration consists of the domain name plus the ent suffix. In the following example, the entity file for a new attribute domain is included in the document type shell:

<!ENTITY % newAtt-d-dec PUBLIC
    "-//My Company//ENTITIES New Attribute Domain//EN"
    "newAttDomain.ent"
>%newAtt-d-dec;

Element extension redefinitions

The element extension redefinition section contains redefinitions of element name parameter entities to reflect the integration of domain-provided element types into base content models. This section should use the comment:

<!-- ============================================================= -->
<!--                    DOMAIN EXTENSIONS                          -->
<!-- ============================================================= -->

For each element that is extended by one or more domains, the document type shell redefines the entity for the element. The new definition is a disjunctive list of alternatives comprising the literal name of the element followed by the element extension entity from each domain that is providing specializations. In the following example, the entity for the <pre> element is redefined to allow specializations from the programming, software, and user interface domains:

<!ENTITY % pre
    "pre        | 
     %pr-d-pre; | 
     %sw-d-pre; | 
     %ui-d-pre;">

The value of the entity may omit any base types from which other types listed are specialized. For example, the preceding example could omit the <pre> element, effectively allowing only specializations of <pre>, but not <pre> itself:

<!ENTITY % pre
    "%pr-d-pre; | 
     %sw-d-pre; | 
     %ui-d-pre;">

Note

Omitting base types from domain extensions constitutes a form of constraint. The constraint must be represented by a constraint module that declares the @domains attribute declaration for the constraint. For the omission of <pre> in the preceding example the constraint might be called "noBasePre-c" and would be declared in a file named "noBasePreConstraint.mod", containing the following declarations:

<!ENTITY noBasePre-c-pre  "%pr-d-pre; | %sw-d-pre; | %ui-d-pre;">
<!ENTITY noBasePre-c-att  "(topic noBasePre-c)" >
<!ENTITY % pre          “%noBasePre-c-pre ;“>

Attribute extension redefinitions

The attribute extension redefinition section integrates the declarations of specializations of the base and props attributes (defined in attribute domain modules included in the attribute domain inclusion section). This section must use the comment:

<!-- ============================================================= -->
<!--                    DOMAIN ATTRIBUTE EXTENSIONS                -->
<!-- ============================================================= -->

The entities for extending the props and base attributes have a null value by default:

<!ENTITY % props-attribute-extensions  "" >
<!ENTITY % base-attribute-extensions   "" >

For each attribute domain included by the shell, the shell must redefine the entity that is extended. The new definition is a list of the attribute extension entities for the domains that are providing specializations.

<!ENTITY % props-attribute-extensions
        "%newAtt-d-attribute; 
         %othernewAtt-d-attribute;">
<!ENTITY % base-attribute-extensions
        "%newfrombaseAtt-d-attribute; 
         %othernewfrombaseAtt-d-attribute;">

Topic nesting redefinitions

The topic nesting section contains redefinitions of the topic nesting control parameter entities defined by the topic modules integrated in the shell. This section should use the comment:

<!-- ============================================================= -->
<!--                    TOPIC NESTING OVERRIDES                    -->
<!-- ============================================================= -->

For each topic type integrated in the shell, the document type shell may control nesting of subtopics by redefining the topictype-info-types entity. The definition is usually an OR list of topic types that can be nested in the corresponding parent topic type. Use the literal root element name of each topic, not the corresponding element entity, as in the following example:

<!ENTITY % concept-info-types "concept | myTopicType">

The document type shell may also set the default for most topic types by defining the global info-types entity, for example:

<!ENTITY % info-types "concept | myTopicType">

Domain declaration redefinition

The domain declaration redefinition section sets the effective value of the @domains attribute for the topic or map type modules integrated into the shell. This section should use the comment:

<!-- ============================================================= -->
<!--                    DOMAINS ATTRIBUTE OVERRIDE                 -->
<!-- ============================================================= -->

The document type shell must redefine the included-domains entity to list the domains for specializations that are included in the document type, as well as any constraint modules, as in the following example:

<!ENTITY included-domains
    "&hi-d-att; 
     &ut-d-att; 
     &ui-d-att; 
     &pr-d-att; 
     &sw-d-att; 
     &newAtt-d-att;
     &noBasePre-c-ph;
   "
>

For a domain or structural module, the domains attribute value entity is declared in the domain's .ent file. For constraint modules, the domains attribute value entity is declared in the module's .mod file constraint modules do not use separate .ent files).

Content constraint module inclusions

The content constraint module inclusion section includes constraint modules that override the base content models for structural or domain types integrated in the shell. This section should use the comment:

<!-- ============================================================= -->
<!--                    CONTENT CONSTRAINT INTEGRATION             -->
<!-- ============================================================= -->

For each constraint module integrated in the shell, the shell must declare an external parameter entity for the constraint's .mod file and immediately reference the entity. The entity name for the constraint declaration consists of the constraint module name plus the -c-mod suffix. For example, this constraint inclusion for the task topic type constrains the DITA 1.2 relaxed task content model to match the more constrained DITA 1.1 task content model:

<!ENTITY % strictTaskbody-c-def  
  PUBLIC "-//OASIS//ELEMENTS DITA 1.2 Strict Taskbody Constraint//EN" 
  "strictTaskbodyConstraint.mod"
>%strictTaskbody-c-def;

Structural definition inclusions

The structural definition inclusion section includes the element type declaration (.mod) files for each topic or map type integrated into the shell. For topic shells, this section should use the comment:

<!-- ============================================================= -->
<!--                    TOPIC ELEMENT INTEGRATION                  -->
<!-- ============================================================= -->

For map shells, this section should use the comment:

<!-- ============================================================= -->
<!--                    MAP ELEMENT INTEGRATION                    -->
<!-- ============================================================= -->

For each structural type integrated in the document type, the document type shell must declare and reference an external parameter entity for the structural type module's .mod file. The entity name consists of the name of the structural type plus a -type suffix. For example:

<!ENTITY % topic-type PUBLIC
    "-//OASIS//ELEMENTS DITA Topic//EN" 
    "topic.mod"
>%topic-type;

Element domain definition inclusions

The element domain definition inclusion section includes the element definition files for each element domain integrated into the shell. This section should use the comment:

<!-- ============================================================= -->
<!--                    DOMAIN ELEMENT INTEGRATION                 -->
<!-- ============================================================= -->

For each element domain used in the document type, the document type shell must declare and reference an external parameter entity for the domain definition module file (.mod). The entity name consists of the domain name plus a -def suffix. For example:

<!ENTITY % hi-d-def PUBLIC
    "-//OASIS//ELEMENTS DITA Highlight Domain//EN" 
    "highlightDomain.mod"
>%hi-d-def;

2.2.1.4.2.2: XSD document-type shell: Coding requirements

A shell document type integrates one or more topic type or map type modules, zero or more domain modules, and zero or more constraint modules. A shell XSD is organized into sections, where each section contains a specific type of declaration.

An XSD document type shell must conform to the following coding requirements. XSD document type shells may not directly declare element types or attributes (except for the @domains attribute, which always reflects the details of the domains and structural types integrated by the shell).

DITA XSDs use the XML Schema redefine feature (xs:redefine) to override base group definitions for content models and attribute lists. This facility is analogous to the parameter entities used for DTDs. Unlike DTD parameter entities, an xs:redefine both includes the XSD file it redefines and holds the redefinition applied to the groups in the included XSD file. Thus, for XSD files that define groups, the file may be included via xs:include if it is used without modification or via xs:redefine if any of its groups are redefined.

Shell XSDs are organized into sections. Each section of the shell XSD is introduced by a comment. Shells should use these comments to identify each section of the shell. Each section should be present in the shell XSD, even if the section contains no declarations, and should occur in the order they are presented here. Shell XSDs should have an initial set of comments that describe the shell and indicate the URNs or absolute URLs by which the shell should be referenced from document instances or otherwise associated with documents. Shell XSDs may use the XSD appinfo and documentation elements to contain additional documentation about the shell.

Element domain inclusions

The element domain inclusion section contains includes of each element domain integrated by the shell. This section should use the comment:

<!--  ================ ELEMENT DOMAINS =====================  -->

For each element domain used by the map or topic type, the shell XSD must have an xs:include element that includes the XSD module for that domain. For example:

<xs:include schemaLocation="urn:oasis:names:tc:dita:xsd:programmingDomain.xsd:1.2"/>
<xs:include schemaLocation="urn:oasis:names:tc:dita:xsd:softwareDomain.xsd:1.2"/>
<xs:include schemaLocation="urn:oasis:names:tc:dita:xsd:highlightDomain.xsd:1.2"/>
<xs:include schemaLocation="urn:oasis:names:tc:dita:xsd:uiDomain.xsd:1.2"/>
<xs:include schemaLocation="urn:oasis:names:tc:dita:xsd:utilitiesDomain.xsd:1.2"/>
<xs:include schemaLocation="urn:oasis:names:tc:dita:xsd:indexingDomain.xsd:1.2"/>
<xs:include schemaLocation="urn:oasis:names:tc:dita:xsd:hazardstatementDomain.xsd:1.2"/>
<xs:include schemaLocation="urn:oasis:names:tc:dita:xsd:abbreviateDomain.xsd:1.2" />

Attribute domain inclusions

The attribute domain inclusion section contains includes of each attribute domain integrated by the shell. This section should use the comment:

<!--  ================ ATTRIBUTE DOMAINS =====================  -->

For each attribute domain used by the map or topic type, the shell XSD must have an xs:include element that includes the XSD module for that domain. For example:

<xs:include schemaLocation="urn:example.com:dita:domains:newAtt.xsd" />

Group inclusions

The group inclusion section contains includes or redefinitions of the group definitions for the structural types integrated in the shell. Group redefinitions are used to integrate domain-provided element and attribute types into base content models. This section should use the comment:

<!--  ================ GROUP DEFINITIONS =====================  -->

For both map and topic shells, this section must include or redefine the common element group, the metadata declaration group, and the table model group.

For topic shells, this section must include or redefine the group XSD for each topic type used by the shell. For example, from a shell for the task topic type:

<xs:include schemaLocation="urn:oasis:names:tc:dita:xsd:taskGrp.xsd:1.2" />
<xs:include schemaLocation="urn:oasis:names:tc:dita:xsd:metaDeclGrp.xsd:1.2"/>
<xs:include schemaLocation="urn:oasis:names:tc:dita:xsd:tblDeclGrp.xsd:1.2"/>
<xs:include schemaLocation="urn:oasis:names:tc:dita:xsd:topicGrp.xsd:1.2"/>

For map shells, this section must include or redefine the group XSD for each map type used by the shell (that is, the module for the specialization of <map> the shell uses, as well as any ancestor map types from which the shell's map element is specialized). For example, from the learningMap shell:

    <xs:include schemaLocation="urn:oasis:names:tc:dita:xsd:tblDeclGrp.xsd:1.2"/>
    <xs:redefine schemaLocation="urn:oasis:names:tc:dita:xsd:mapGrp.xsd:1.2">
      <xs:group name="topicref">
        <xs:choice>
          <xs:group ref="topicref"/>
          <xs:group ref="mapgroup-d-topicref"/>
          <xs:group ref="learningmap-d-topicref"/>
        </xs:choice>
      </xs:group>
    </xs:redefine>
  
    <xs:redefine schemaLocation="urn:oasis:names:tc:dita:xsd:commonElementGrp.xsd:1.2">
      <xs:group name="index-base">
        <xs:choice>
          <xs:group ref="index-base"/>
          <xs:group ref="indexing-d-index-base"/>
        </xs:choice>
      </xs:group>
      
    </xs:redefine>
    
    
    <xs:redefine schemaLocation="urn:oasis:names:tc:dita:xsd:metaDeclGrp.xsd:1.2">
      <xs:group name="metadata">
        <xs:choice>
          <xs:group ref="metadata"/>
          <xs:group ref="learningmeta-d-metadata"/>
        </xs:choice>
      </xs:group>
      <xs:group name="keywords">
        <xs:choice>
          <xs:group ref="keywords"/>
          <xs:group ref="delay-d-keywords"/>
        </xs:choice>
      </xs:group>
    </xs:redefine>

For each element extended by one or more domains, the document type shell must redefine the model group for the element to a list of alternatives including the literal name of the element and the element extension model group from each domain that is providing specializations. To integrate a new domain in the document type shell use the schema <redefine> mechanism to manage the number of domains used by the document type shell. The model group requires a reference to itself to extend the base model group. To see an example, look at the topic.xsd schema document.

<xs:group name="pre">   
  <xs:choice>       
    <xs:group ref="pre" />
    <xs:group ref="pr-d-pre" />
    <xs:group ref="ui-d-pre" />
    <xs:group ref="sw-d-pre" />
  </xs:choice>
</xs:group>

To add domains to a new structural type you can copy the contents of the parent structural type domains schema document into the document type shell. Add or remove the model group from the new domain to the appropriate named group.

<xs:group name="pre">
  <xs:choice>
    <xs:group ref="pre"/>
    <xs:group ref="pr-d-pre" />
    <xs:group ref="domainName-d-element"/>
  </xs:choice> 
</xs:group>

For each attribute extended by one or more domains, the document type shell must redefine the attribute extension model group for the attribute to a list of alternatives including the literal name of the attribute and the attribute extension model group from each domain that is providing specializations. To integrate a new attribute domain in the document type shell use the schema <redefine> mechanism to manage the number of attribute domains used by the document type shell.

<xs:attributeGroup name="props-attribute-extensions">
  <xs:attributeGroup ref="props-attribute-extensions"/>
  <xs:attributeGroup ref="newAtt-d-attribute"/>
  <xs:attributeGroup ref="othernewAtt-d-attribute"/>
</xs:attributeGroup>
          
<xs:attributeGroup name="base-attribute-extensions">
  <xs:attributeGroup ref="base-attribute-extensions"/>
  <xs:attributeGroup ref="newfrombaseAtt-d-attribute"/>
  <xs:attributeGroup ref="othernewfrombaseAtt-d-attribute"/>
</xs:attributeGroup>

Module inclusions

The module inclusion section includes the module XSD files for the structural types used in the shell. This section should use the comment:

<!-- =================  MODULE INCLUDE DEFINITION  ==================  -->

For each map or topic type used by the shell, this section must include either the module XSD file for that type or a constraint module for that type . It must also include any other module XSD files required by the topic or map types, normally the common element module, meta declaration module, and table declaration module. For example:

<xs:include schemaLocation="urn:oasis:names:tc:dita:xsd:commonElementMod.xsd:1.2"/>
<!-- ======== Table elements ======== -->
<xs:include schemaLocation="urn:oasis:names:tc:dita:xsd:tblDeclMod.xsd:1.2"/>    
<!-- ======= MetaData elements, plus keyword and indexterm ======= -->
<xs:include schemaLocation="urn:oasis:names:tc:dita:xsd:metaDeclMod.xsd:1.2"/>
<xs:include schemaLocation="urn:oasis:names:tc:dita:xsd:topicMod.xsd:1.2" />  
<xs:include schemaLocation="urn:oasis:names:tc:dita:xsd:conceptMod.xsd:1.2" />

Domains attribute declaration

The @domains attribute declaration section contains the declaration of the domains attribute for the shell. This section should use the comment:

<!-- =================  DOMAINS ATTRIBUTE DECLARATION  ==================  -->

The shell must declare the @domains attribute such that the @domains attribute value reflects each vocabulary module and constraint module integrated by the shell. The declaration has the form:

<xs:attributeGroup name="domains-att">
   <xs:attribute name="domains" type="xs:string"
        default="domain usage declarations"
   />
</xs:attributeGroup>

Where domain usage declarations is a sequence of domain usage specifications (see Domain usage declaration (the @domains attribute) for details). For example, from the learningMap shell:

<xs:attributeGroup name="domains-att">
  <xs:attribute name="domains" type="xs:string"
     default="(map mapgroup-d) 
              (topic delay-d)  
              (topic indexing-d) 
              (topic learningmeta-d) 
              (map learningmap-d) "
  />
</xs:attributeGroup>

Info types definition

Each topic type defines an info types group that defines the default set of allowed subordinate topics for that topic type. Topic shells may redefine this group to change the effective set of allowed subordinate topics.

The info types section contains the definition of the effective value of the info types groups for topics used by the shell. This section should use the comment:

<!-- =================  INFO TYPES DEFINITION  ==================  -->

This section must not be included in map shells.

The shell must define a model group with the name info-types. This model group may define a list of allowed subordinate topics. If the topic type should not allow subordinate topics, then the default value for the info-types model group must be defined as an empty group, as follows:

<xs:group name="info-types">
  <xs:sequence/>
</xs:group>

The document type shell may control how topics are allowed to nest within specific topic types by redefining the topic-type-specific info types group, named topictype-info-types. The info-types group is declared in the module XSD file for a given topic type. For example, in a shell for the concept topic type, allowing concept or generic topic to nest within concept:

<xs:redefine schemaLocation="urn:oasis:names:tc:dita:xsd:conceptMod.xsd:1.2" >
  <xs:group name="concept-info-types">
    <xs:choice>
      <xs:group ref="concept-info-types"/>
      <xs:group ref="topic"/>
    </xs:choice>
  </xs:group>
</xs:redefine>

Note that XSD rules require that the redefined group include a reference to itself in addition to any other components specified for the redefined group.

2.2.1.4.3: Specialization

The specialization feature of DITA allows for the creation of new element types and attributes that are explicitly and formally derived from existing types. The resulting specialization allows for the blind interchange of all conforming DITA content and a minimum level of common processing for all DITA content. It also allows specialization-aware processors to add specialization-specific processing to existing base processing.

Specializations are explicitly declared in documents

The specialization feature of DITA defines both a specialization hierarchy declaration syntax used in document instances and a set of document type implementation requirements. The specialization declarations allow processors to determine what set of specializations and associated local constraints a given DITA document uses. The specialization declarations for individual elements and attributes allow processors to determine what the type hierarchies of those elements and attributes are, from which processors can determine the most appropriate (or available) processing to apply.

Specialization enables controlled extension

Specialization allows you to define new kinds of information (new structural types or new domains of information), while reusing as much of existing design and code as possible, and minimizing or eliminating the costs of interchange, migration, and maintenance.

In traditional XML applications, all semantics for a given element instance are bound to the element type, such as <para> for a paragraph or <title> for a title. The XML specification provides no built-in mechanism for relating two element types to say "element type B is a subtype of element type A". However, in most documentation-focused XML applications there is often a clear hierarchy of types. For example, in a technical manual, there might be generic sections and more specialized sections, e.g. "Troubleshooting" or "Assembly Procedures". The presentation of the generic and specialized sections might be identical, but the more specialized sections might have more restrictive constraints or include additional element types relevant only to those section types. While these relationships might be understood by authors and system implementors, the XML standard provides no direct way to express the relationship, to say explicitly "A Troubleshooting section is a generic section and must conform to all requirements of generic sections". Having created the element type <section> and implemented presentation processing for it and then having later created the element type <troubleshooting>, there is no obvious mechanism for having all <troubleshooting> elements automatically get the processing associated with <section> elements. To get that behavior someone has to explicitly update all processors involved to apply <section> processing to <troubleshooting>.

The DITA specialization feature provides a standard mechanism for saying explicitly, using normal XML syntax, "A Troubleshooting section is a generic section and must conform to all requirements of generic sections" and, having said that, makes it possible for generic section processing to be applied to troubleshooting sections with no further effort.

When to use or not use specialization

Specialization is used when new structural types or new domains are needed. DITA specialization can be used when you want to make changes to your design for the sake of increased consistency or descriptiveness or have specific needs for output that cannot be addressed using the current data model. Specialization is not normally used for simply creating different output types, as DITA documents may be transformed to different outputs.

Do not use specialization to simply eliminate unneeded or unwanted element types from specific content models. The content models for element types defined in vocabulary modules can be configured using separately-defined constraint modules without the need to create new specializations. See Constraints.

Use specialization when you are dealing with new semantics (new, meaningful categories of information, either in the form of new structural types or new domains). The new semantics can be encoded as part of a specialization hierarchy, that allows them to be processed by existing specialization-aware transforms or transformed back to more general equivalents ("generalization") for processing by transforms that only understand the unspecialized base types. Use constraints to configure content models and attribute lists without changing semantics.

Types of specialization hierarchy

There are two kinds of specialization hierarchy: one for structural types (with topic or map at the root) and one for domains (with elements in topic or map at their root, or the @props or @base attributes). Structural types define topic or map structures, such as concept or task or reference, which often apply across subject areas (for example, a user interface task and a programming task may both consist of a series of steps). Domains define markup for a particular information domain or subject area, such as programming, or hardware. Each type of vocabulary module represents an “is a” hierarchy, in object-oriented terms, with each structural type or domain being a subclass of its parent. For example, a specialization of task is still a task and a specialization of the user interface domain is still part of the user interface domain. A given domain can be used with any map or topic type, as appropriate for the domain. In addition, specific structural types may require the use of specific domains.

Specialization of attributes

With structural specializations you can limit the allowed values of attributes defined on the base types of specialized types. You can also define new attributes through domain specializations based off of the @props attribute (for conditional processing) or the @base attribute (for other simple token attributes).

Note

As a general practice, structural specializations should not limit the values of the built-in selection attributes. Use constraint modules to define specific value lists for built-in selection attributes.

Attribute specialization allows you to define new conditional processing attributes that can be used for filtering and flagging (specializations of @props) or new attributes with no existing equivalent that can be managed and generalized in the same way as conditional processing attributes (specializations of @base).

New attributes need to be specialized from either @props or @base:

Attributes specialized from @props are recognized as conditional processing attributes
Attributes specialized from @base have no existing behavior associated with them
Values in specialized attributes should be preserved during generalization and respecialization as for @props
While generalized, the attribute values should still be understandable by both general and specialized behaviors, and be treated as equivalent to their specialized form. For example, conditional filtering should work the same way on specialized attributes and on generalized attributes.

2.2.1.4.3.1: Vocabulary modules

Vocabulary modules are atomic units of XML vocabulary definition (element types and attributes). A given DITA element type or attribute is declared in exactly one vocabulary module.

Vocabulary modules must reflect the implementation requirements defined in this specification for each recognized constraint mechanism. These requirements ensure that all vocabulary modules of a given type follow the same basic coding patterns for how their components are named and organized.

Vocabulary modules intended to be used outside of a narrowly-restricted context should have one or more associated globally-unique names (public IDs, URNs, or absolute URLs) by which modules can be referenced without regard to their local storage location.

There are three types of vocabulary module:

structural

A vocabulary module that defines exactly one top-level map or topic type. Structural modules may also define specializations of elements from domain modules. Structural modules are either topic modules or map modules.

A topic vocabulary module must define exactly one top-level topic type. It may define additional topic types that are then allowed to occur as subordinate topics within the top-level topic. However, such subordinate topic types may not be used as the root elements of conforming DITA documents. For example, a given top-level topic type may require the use of subordinate topic types that would only ever be meaningful in the context of their containing type and thus would never be candidates for standalone authoring or aggregation via maps. In that case, the subordinate topic type may be declared in the module for the top-level topic type that uses it. However, in most cases, potential subordinate topics should be defined in their own vocabulary modules.

A map vocabulary module must define exactly one element type that specializes map.

element domain

A vocabulary module that defines one or more element types that specialize element types used within maps or topics.

attribute domain

A vocabulary module that defines exactly one specialization of either the @base or @props attribute.

A given vocabulary module exists in an exclusive hierarchy relative to its ancestor modules. For example, the <concept> topic type is defined in the concept topic module and is itself derived from the topic topic module (that is, the topic-defining structural module that defines the topic type <topic>). Likewise, the <task> topic type is defined in the task topic module and is derived from the <topic> topic type. Thus the concept and task topic types are children of the <topic> topic type in the module hierarchy rooted at the <topic> topic vocabulary module.

All topic types must ultimately be specialized from <topic>. All map types must ultimately be specialized from <map>. Domain elements intended for use in topics must ultimately be specialized from elements defined in the topic module. Domain elements intended for use in maps must ultimately be specialized from elements defined by or used in the map module (maps share some element types with topics but no map-specific elements may be used within topics). Domain attributes must ultimately be specialized from either the @base or @props attribute.

Each vocabulary module has an associated short name, which is used to identify the module in @class and @domains attribute values. While module names need not be globally unique, module names must be unique within the scope of a given specialization hierarchy. The short name must be a valid XML name token.

For structural types, the module name must be the same as the root element. For example, "task" is the name of the structural vocabulary module whose root element is <task>. For domains, the name is assigned by the developer of the vocabulary module. By convention, domain names end with "-d" and are kept short; for example, "ui-d" for the user interface domain and "pr-d" for the programming domain.

When integrated into concrete document types, vocabulary modules may be further constrained through the use of constraint modules. See Constraints.

2.2.1.4.3.2: Requirements for specialized element types and attributes

When you specialize one element from another, or a new attribute from @props or @base, the new element or attribute must obey certain rules in order to be a conforming specialization.

A specialized element:

Must have a properly formed @class attribute specifying inheritance from its parent.

Must not have a more inclusive content model than its parent has.

Must not have attributes that its parent lacks.

Must not have values or value ranges of these attributes that are more extensive than those in the parent.

An attribute specialized from the @props or @base attribute:

Must follow the rules for attribute domain specialization.

Must not have values or value ranges that are more extensive than those of the parent.

Must conform to the rules for conditional processing values, that is, alphanumeric space-delimited values. In generalized form, the values must conform to the rules for attribute generalization.
Must be declared as a global attribute. Attribute specializations cannot be limited to specific element types.

DITA elements are never in a namespace. Only the @DITAArchVersion attribute is in a DITA-defined namespace. All other attributes, except for those defined by the XML standard, are in no namespace.

This limitation is imposed by the details of the @class attribute syntax, which makes it impractical to have namespace-qualified names for either vocabulary modules or individual element types or attributes. Elements included as descendants of the DITA <foreign> element type may be in any namespace.

Note

For this reason, domain modules that are intended for wide use should take care to define element type and attribute names that are unlikely to conflict with names used in other domains, for example, by using a domain-specific prefix on all names.

2.2.1.4.3.3: Element type specialization hierarchy declaration (the @class attribute)

Each DITA element declares its specialization hierarchy as the value of the @class attribute. The @class attribute usually provides a mapping from the element's current name to its more general equivalents, but it can also provide a mapping from the current name to more general and more specialized equivalents. All specialization-aware processing can be defined in terms of @class attribute values without reference to a given element's tagname.

Specialization hierarchy declaration requirements

Values for the @class attribute must conform to the following syntax requirements:

An initial "-" or "+" character followed by one or more spaces, "-" for element types defined in structural vocabulary modules, "+" for element types defined in domain modules.
A sequence of one or more module/type pair tokens of the form "modulename/typename", with each pair of tokens separated by one or more spaces, where modulename is the short name of the vocabulary module and typename is the element type name. Tokens are ordered left to right from most general to most specialized.
At least one trailing space character (" "). The trailing space ensures that string matches on module/name pairs can always include a leading and trailing space in order to reliably match full tokens.

When the @class attribute is declared in a DTD or XSD, it must be declared with a default value. In order to support generalization round-tripping (generalizing specialized content into a generic form and then returning it to the specialized form) the default value must not be fixed. This allows a generalization process to overwrite the default values defined by a general document type with specialized values taken from the document being generalized.

When a vocabulary module declares new element types, it must provide a @class attribute for each element type that it declares. The @class attribute must include a mapping for every structural type or domain in the specialized type's ancestry, even those in which no element renaming occurred. The mapping must start with the value for the base type (for example topic or map), and finish with the current element type.

A vocabulary module must not change the @class attribute for elements that it does not specialize, but simply reuses by reference from more generic levels. For example, since task, bctask, and guitask use the <p> element without specializing it, they must not declare mappings for it.

The @class attribute should not be modified by authors.

Examples (non-normative)

The @class attribute for the task topic type's <step> element is:

<!ATTLIST step         class  CDATA "- topic/li task/step ">

This tells us that the <step> element is equivalent to the <li> element in a generic topic. It also tells us that <step> is equivalent to a <step> in a task topic, which we already knew, but it's worth noting this in the attribute because it enables round-trip migration between upper level and lower level types without loss of information.

While a given element's tagname is normally the same as the typename of the last token in the @class value, this is not required. Processors that perform generalization may transform elements from specialized types to less-specialized types, leaving the values of the @class attribute unchanged (thus preserving knowledge of the original most-specialized form). For example, if a user runs a generalizing transformation that maps all elements to their first @class value, but preserves their content and attribute values, then the user can follow it up with a "specialize" transformation that maps all elements to their last @class value (preserving content and attribute values), and provide a full round trip for all content between the two document types, using nothing but two generic transformations and the information in the @class attribute.

The @class attribute tells a processor what general classes of elements the current element belongs to. DITA scopes elements by module type (for example topic type, domain type, or map type) instead of document type, which lets document type developers combine multiple topic types in a single document without complicating transformation logic.

The sequence of values in the @class attribute is important because it tells processors which value is the most general and which is most specific. This is especially important for "specializing" transformations, where you can apply a general rule that says: if the element doesn't have a mapping to the target topic type, simply use the last value of the @class attribute (and assume that the specialized topic type is reusing some general element declarations, which only have mappings for the level at which they were declared).

Example of structural type element with @class attribute

<appstep class="- topic/li task/step bctask/appstep ">
  <cmd class="- topic/ph task/cmd ">A specialized step</cmd>
</appstep>

Example of domain element with @class attribute

<wintitle class="+ topic/keyword ui-d/wintitle ">A specialized keyword</wintitle>

While this example is trivial, more complicated hierarchies (say, five levels deep, with renaming occurring at levels two and four only) make explicit intermediate values essential.

The specialization hierarchy for a given element type must reflect any intermediate modules between the base type and the specialization type, as shown in this example:

Example of @class attribute with intermediate value

<windowname class="- topic/keyword task/keyword guitask/windowname ">

The intermediate values are necessary so that generalizing and specializing transformations can map values simply and accurately. For example, if task/keyword was missing as a value, and a user decided to generalize this guitask up to a task topic, then the transformation would have to guess whether to map to keyword (appropriate if task is more general than guitask, which it is) or leave it as windowname (appropriate if task were more specialized, which it isn't). By always providing mappings for more general values, processors can then apply the simple rule that missing mappings must by default be to more specialized values than the one we are generalizing to, which means the last value in the list is appropriate. For example, when generalizing <guitask> to <task>, if a <p> element has no target value for <task>, we can safely assume that <p> does not specialize from <task> and should not be generalized.

2.2.1.4.3.4: Domain usage declaration (the @domains attribute)

Structural types must declare the domain vocabulary modules and constraint modules they use. This is done with the @domains attribute, whose value is a sequence of parenthesized module ancestry specifications. The @domains attribute is declared on the root element for each topic or map type. Structural modules should declare their structural ancestry.

Each structural, element, and attribute domain defines its module ancestry as a parenthesized sequence of space-separated module names from root module to provided module.

For element domains, the group syntax is:

 '(', modulename, (' ', modulename)+, ')'

For attribute domains, the group syntax is:

 'a(', attname, (' ', attname)+, ')'

The module ancestry specifications are added to the effective value of the @domains attribute to form a set of specifications, one for each domain used by the topic or map type.

The @domains values for the different module types are as follows:

structural domains: The structural type ancestry. For example: (topic concept glossentry). When a structural domain depends on one or more element or attribute domains, the structural domain's @domains specification must include the domain dependencies following the name of the specialize structural domain, e.g. (topic reference cppApiRef cpp-d compilerTypeAtt-d), here reflecting a topic specialization that depends on two domains, "cpp-d" and "compilerTypeAtt-d".

Note

The specification of domain dependencies serves in part as a signal to document type shell authors that the domain module must always be integrated along with the structural module.
constraint modules: The structural type ancestry followed by the name of the constraint domain. For example: (topic task strictTaskbody-c).
element domains: The structural type ancestry and, if applicable, the domain module ancestry from which the domain is specialized. For example: (topic hi-d) (topic pr-d cpp-d).
attribute domains: The attribute specialization hierarchy. For example: a(props mySelectAttribute).

The @domains attribute allows processors to determine whether or not two elements use compatible domains. For example, when pasting content from one topic into another topic within an editor, the editor can use the @domains attribute to determine if the paste target topic's domains are compatible with the paste source topic's domains and therefore whether or not the pasted content needs to be generalized before it can be pasted. Likewise, processors can use the value of the @domains attribute to determine if they have whatever may be necessary to support a particular domain.

The effective value of the @domains attribute is constructed using integration mechanisms specific to each XML document constraint language. Each domain and constraint module must provide a @domains attribute value fragment that can be used by DITA document types to construct the effective @domains attribute value. Each structural vocabulary module should provide a @domains attribute value fragment. See Configuration (Document type shells).

Example: task with multiple domains

<task id="mytask" class="- topic/topic task/task " 
	domains="(topic ui-d) (topic sw-d) (topic pr-d)">
...
</task>

In this example, the task allows the use of elements for describing user interfaces (ui-d), software (sw-d), and also programming (pr-d).

If the document used a specialization of the programming domain to describe C++ programming, the new domain would need a separate entry in the @domains attribute, e.g.:

<task id="mytask" class="- topic/topic task/task " 
	domains="(topic ui-d) (topic sw-d) (topic pr-d) (topic pr-d cpp-d)">
...
</task>

Example: How editing tools and processors can use the @domains attribute

The @domains attribute enables processors to determine whether two elements use compatible domains. For example, when pasting content from one topic into another topic within an editor, the editor can use the @domains attribute to determine if the paste target topic's domains are compatible with the paste source topic's domains and therefore whether or not the pasted content needs to be generalized before it can be pasted. Likewise, processors can use the @domains value to determine if they have whatever may be necessary to support a particular domain.

Another example is when an element references an element that is a more specialized version of the element, for example. a <li> element of concept topic references a <step> element in a task topic. During processing, the <step> element will be generalized back to a <li> element.

2.2.1.4.3.5: Generalization

Specialized content can be generalized to any ancestor type. The generalization process can preserve information about the former level of specialization to allow round-tripping between specialized and unspecialized forms of the same content.

Among the purposes of generalization:

Migration of content (for example, when retiring an unsuccessful specialization),
Temporary round-tripping (for example, when moving content through a process that is not specialization aware and has only been enabled for instances of the base structural type),
Reuse of specialized content in an environment that does not support one or more of its specializations (which may be thought of as a special case of round-tripping).

When generalizing for migration, the @class attribute and @domains attribute should be absent from the generalized instance document so that the default values in the DITA document type shell will be used. When generalizing for round-tripping, the @class attribute and @domains attribute should retain the original specialized values in the generalized instance document.

All DITA documents contain a mix of markup from at least one structural type and zero or more domains. When generalizing the document, the generalizer may choose to leave a structural type or domain as-is, or may choose to generalize that type or domain to any of its ancestors.

The generalizer can supply the source and target modules for each generalization, for example, "generalize from reference to topic". The generalizer can specify multiple target modules, for example, "generalize from reference to topic and from ui-d to topic". When the source and target modules are not supplied, generalization is assumed to be from all structural types to the base (topic or map), and no generalization is performed for domains.

The generalizer can also supply the target DITA document type shell. When the target document type is not supplied, the generalized document will not contain a reference to a DITA document-type shell. With the exception of topic nesting constraints, it is possible to generate a document type shell based on the @class and @domains attributes in the specialized documents. If the@ domains attribute includes all structural, domain, and constraint modules used, the @domains attribute alone is sufficient to enable generation of a document type shell.

A generalization process should be able to handle cases where it is given:

Just source modules for generalization (in which case the designated source types are generalized to topic or map),
Just target modules for generalization (in which case all descendants of the target are generalized to that target), or
Both (in which case only the specified descendants of the target are generalized to that target).

For each structural type instance, the generalization process checks whether the structural type instance is a candidate for generalization, or whether it has domains that are candidates for generalization. It is important to be selective about which structural type instances to process; if the process simply generalizes every element based on its @class attribute values, an instruction to generalize "reference" to "topic" could leave an APIReference topic with an invalid content model, since any elements it reuses from "reference" would have been renamed to topic-level equivalents.

The @class attribute for the root element of the structural type is checked before generalizing structural types:

	Source module unspecified	Source module specified
Target module unspecified	Generalize this structural type to its base ancestor	Check whether the root element of the topic type matches a specified source module; generalize to its base ancestor if it does, otherwise ignore the structural type instance unless it has domains to generalize.
Target module specified	Check whether the @class attribute contains the target module. If it does contain the target, rename the element to the value associated with the target module. Otherwise, ignore the element.	It is an error if the root element matches a specified source but its @class attribute does not contain the target. If the root element matches a specified source module and its @class attribute does contain the target module, generalize to the target module. Otherwise, ignore the structural type instance unless it has domains to generalize.

The @domains attribute for the root element of the structural type is checked before generalizing domains:

	Source module unspecified	Source module specified
Target module unspecified	Do not generalize domain specializations in this structural type.	Check whether the @domains attribute lists the specified domain; proceed with generalization if it does, otherwise ignore the structural type instance unless it is itself a candidate for generalization.
Target module specified	Check whether the @domains attribute contains the target module. If it does, generalize to the target module. Otherwise, skip the structural type instance unless it is itself a candidate for generalization.	It is an error if the @domains attribute matches a specified source but the domain value string does not contain the target. If the @domains attribute matches a specified source module and the domain value string does contain the target module, generalize to the target module. Otherwise, ignore the structural type instance unless it is itself a candidate for generalization.

For each element in a candidate structural type instance:

	Source module unspecified	Source module specified
Target module unspecified	If the @class attribute starts with "-" (part of a structural type), rename the element to its base ancestor equivalent. Otherwise ignore it.	Check whether the last value of the @class attribute matches a specified source; generalize to its base ancestor if it does, otherwise ignore the element.
Target module specified	Check whether the @class attribute contains the target module; rename the element to the value associated with the target module if it does contain the target, otherwise ignore the element.	It is an error if the last value in the @class attribute matches a specified source but the previous values do not include the target. If the last value in the @class attribute matches a specified source module and the previous values do include the target module, rename the element to the value associated with the target module. Otherwise, ignore the element.

When renaming elements during round-trip generalization, the generalization process should preserve the values of all attributes. When renaming elements during one-way or migration generalization, the process should preserve the values of all attributes except the @class and @domains attribute, both of which should be supplied by the target document type.

2.2.1.4.3.6: Attribute generalization

There is a particular syntax to generalize attributes that have been specialized from the @props or @base attribute. Specialization-aware processors should be able to recognize and process both the specialized and generalized forms of an attribute as being equivalent in their values.

When a specialized attribute is generalized to an ancestor attribute, the value of the ancestor attribute consists of the name of the specialized attribute followed by its specialized value in parentheses. For example, given that "jobrole" is an attribute specialized from "person", which in turn is specialized from "props":

jobrole="programmer" can be generalized to person="jobrole(programmer)" or to props="jobrole(programmer)"

props="jobrole(programmer)" can be respecialized to person="jobrole(programmer)" or to jobrole="programmer"

In this example, generalization and respecialization can use the @domains attribute to determine the ancestry of the specialized @jobrole attribute, and therefore the validity of the specialized @person attribute as an intermediate target for generalization.

If more than one attribute is generalized, the value of each is separately represented in this way in the value of the ancestor attribute.

Generalized attributes are typically not expected to be authored or edited directly, but are used by generalizing processors to preserve the values of the specialized attributes during the time or in the circumstances in which the document is in a generalized form.

A single element may not contain both generalized and specialized values for the same attribute. For example, this element:

<p person="jobrole(programmer)" jobrole="admin">...</p>

provides two values for the @jobrole attribute, but one is in a generalized syntax and the other in a specialized syntax. This is an error condition, since it means the document has been only partially generalized, or has been generalized and then edited using a specialized document type.

2.2.1.4.3.7: Specializing foreign or unknown content

Specializing the <foreign> or <unknown> element is an open extension to DITA for the purpose of incorporating standard vocabularies for non-textual content, such as MathML and SVG, as in-line objects. These elements should not be used to include textual content or metadata in DITA documents except where such content acts as an example or display, rather than as the primary content of a topic.

Incorporating foreign or unknown content

There are three methods of incorporating foreign content into DITA.

A domain specialization of the <foreign> or <unknown> element. This is the usual implementation.

A structural specialization using the <foreign> or <unknown> element. This affords more control over the content.

Do nothing: simply embed the foreign content within <foreign> or <unknown>.

Foreign or unknown content and the architectural @class attribute

Foreign content that is incorporated in DITA by one of these methods is not specialized. Specialization depends upon the architectural @class attribute found in every DITA element. If the foreign content has interoperability or vocabulary naming issues such as those that are addressed by specialization in DITA, they must be addressed by means that are appropriate to the foreign content.

Example of specializing foreign or unknown content using DTDs

The sample below describes how to create a domain declaration of the svg element, but does not show how to integrate that declaration in a DITA document-type shell. For more specific information on creating document-type shells, see DTD syntax specialization module coding requirements.

<!-- declaration for the specialized wrapper -->
<!ENTITY % svg "svg">

<!-- included SVG document type -->
<!ENTITY % SVG.prefix "svg" >
<!ENTITY % svg-qname.mod
    PUBLIC "-//W3C//ENTITIES SVG 1.1 Qualified Name//EN"
           "svg-qname.mod" 
>%svg-qname.mod;

<!-- definition for the specialized wrapper  -->
<!ENTITY % svg.content "
     (%SVG.svg.qname;)
">
<!ATTLIST % svg.attributes "
">
<!ELEMENT svg %svg.content; >
<!ATTLIST svg %svg.attributes; >

<!ATTLIST svg %global-atts; class CDATA "+ topic/foreign svg-d/svg ">

Note

The example assumes that parameter entity SVG.svg.qname is declared in the SVG DTD or schema.

Example of SVG within a <p> element

<p>This is an ellipse:
  <svg>
    <svg:svg width="100%" height="100%" version="1.1"
xmlns="http://www.w3.org/2000/svg">

<ellipse cx="300" cy="150" rx="200" ry="80"
style="fill:rgb(200,100,50);
stroke:rgb(0,0,100);stroke-width:2"/>

    </svg:svg>    
  </svg>.
</p>

Example of specializing foreign content using XML Schemas

The sample below describes how to create a domain declaration of the mathML element, but does not show how to integrate that declaration in a DITA document-type shell. For more specific information on creating document-type shells, see XSD schema specialization module coding requirements

<!-- importing MathML document type --> 
<xs:import namespace="http://www.w3.org/1998/Math/MathML" schemaLocation="mathml2.xsd">
 
<!-- definition for the specialized wrapper  -->
<xs:element name="mathML" type="mathML.class" />
<xs:complexType name="mathML.class">
  <xs:choice>
      <xs:element ref="mml:math" />
  </xs:choice>
  <xs:attribute name="outputclass" type="xs:string"/>
    <xs:attributeGroup ref="univ-atts"/>
    <xs:attributeGroup ref="global-atts"/>
    <xs:attribute ref="class" default="+ topic/foreign mathML/mathML"/>
</xs:complexType>

<!-- definition for each element extended by the domain  -->    
<xs:group name="ma-d-foreign">
  <xs:choice>
     <xs:element ref="mathML" />
  </xs:choice>
</xs:group>
  
<!-- definition for the named model groups  -->
<xs:group name="foreign">
   <xs:choice>
     <xs:group ref="foreign"/>
     <xs:group ref="ma-d-foreign"/>
   </xs:choice>
</xs:group>

Example of MathML within an <object> element

<p>... as in the formula 
<object>
  <desc>4 + x</desc>
  <mathML>
    <mml:math display="block">
      <mml:mrow>
        <mml:mo>&sum;</mml:mo>
        <mml:mn>4</mml:mn>
        <mml:mo>+</mml:mo>
        <mml:mi>x</mml:mi>
      </mml:mrow>
    </mml:math>    
  </mathML>
 <object>.
</p>

2.2.1.4.3.8: Specialization module coding requirements

The base DITA element and attribute types may be extended through the creation of new vocabulary modules that define specializations of more-general types.

2.2.1.4.3.8.1: DTD syntax specialization module coding requirements

To be extensible and backward compatible, DITA requires that a DTD implementation of structural and domain specialization modules conform to well-defined implementation (coding) requirements.

These coding requirements implement the specialization architecture with the capabilities and within the limitations of the DTD grammar. They are the coding requirements for structural specializations, element domain specializations, and attribute domain specializations.

2.2.1.4.3.8.1.1: General element type declaration coding requirements

Structural and element domain vocabulary modules must reflect the same coding requirements for element type declarations.

Module names

Each vocabulary module has a short name that is used to construct file names, entity names, and other names used in associated declarations. Modules may also have abbreviated names that further shorten the short name, for example "sw" for the "software" domain, where "software" is the short name and "sw" is the abbreviated name.

For structural modules, the module name must be the element type name of the top-level topic or map type defined by the module, such as "concept", "bookmap".

For element domain modules, the module name must be a name that reflects the subject domain to which the domain applies, such as "highlight", "software". Domain module names should be sufficiently unique that they are unlikely to conflict with any other domains.

Module files

A structural or element domain vocabulary module must have two files:

A module entity declaration file, which declares the entities used to integrate the module into a shell DTD.

For structural modules, the file name is the module name plus the ent extension, e.g. concept.ent.

For domain modules, the file name is the domain name plus Domain plus the ent extension, e.g. highlightDomain.ent, newAttDomain.ent.

A definition module, which contains the element type and/or attribute list declarations for the module.

For structural modules, the file name is the module name plus the mod extension, e.g., concept.mod

For domain modules, the file name is the domain name plus "Domain" and the mod extension, e.g., highlightDomain.mod, newAttDomain.mod.

Domain declaration entity

The domain declaration entity must conform to the following implementation pattern:

The declaration file must define an entity that associates the domain with a module. The name of the entity is the structure type name or domain abbreviation plus the -att suffix, e.g. "concept-att", "hi-d-att".

The value of the entity must list the dependencies of the domain module in order of dependency from left to right within enclosing parentheses, starting with the topic module. Domain abbreviations are used in the list, and the defining domain is the last item in the list. The following example declares the dependency of the highlight domain on the base topic module.

<!ENTITY hi-d-att "(topic hi-d)">

The domain declaration entity is used to construct the effective value of the domains attribute for a map or topic type as configured in a shell DTD.

Element definitions

A structural or domain vocabulary module must contain a declaration for each specialized element type named by the module. While the XML standard allows content models to refer to undeclared element types, all element types named in content models or attribute list declarations within a vocabulary module must have an ELEMENT declaration, in one of:

The vocabulary module
A base module of which the vocabulary module is a direct or indirect specialization
A required domain module (if the vocabulary module is a structural module).

The specialized elements must follow the rules of the architecture in defining content models and attributes.

For each element type declared in the vocabulary module there must be an element name parameter entity whose default value is the name of the element, e.g.:

<!ENTITY % conbody "conbody">

The element name entity provides a layer of abstraction that facilitates redefinition. A document type shell can predefine an element entity to add domain-specialized elements or replace a base element type with one or more specializations of that type. Because declarations use the entity rather than the element type name to include the element in a content model, the redefinition given in a shell is propagated to every context in which the base element occurs.

The element name parameter entities must be grouped together at the top of the vocabulary module before any other declarations to ensure they are declared before any use in content models declared in the same module. The declarations may occur in any order. By convention, they are usually ordered alphabetically or grouped logically.

For each element type, the content model and attribute list declarations should start with a descriptive comment. For example:

<!--                    LONG NAME: Topic Head                      -->

Each element type must have a corresponding content model parameter entity named %tagname.content. The value of the entity must be the complete content model definition. For example:

<!ENTITY % topichead.content
  "((%topicmeta;)?, 
    (%anchor; | 
     %data.elements.incl; | 
     %navref; | 
     %topicref;)*)
">

The content model parameter entity may be overridden in shell DTDs or constraint modules to further constrain the content model for the element type.

Each element type must have a corresponding attribute list parameter entity named %tagname.attributes. The parameter entity must declare all attributes used by the element type (except for the attributes provided by the %global-atts; parameter entity, which is always referenced as part of the attribute list declaration for an element's class attribute). For example:

<!ENTITY % topichead.attributes
 "navtitle 
     CDATA 
          #IMPLIED
   outputclass 
     CDATA 
          #IMPLIED
   keys 
     CDATA 
          #IMPLIED
   %topicref-atts;
   %univ-atts;"
>

The ELEMENT declaration for each element type must consist entirely of a reference to the corresponding content model parameter entity:

<!ELEMENT topichead    %topichead.content;>

The ATTLIST declaration for each element type must consist entirely of a reference to the corresponding attribute list parameter entity:

<!ATTLIST topichead    %topichead.attributes;>

The content model parameter entity, attribute list parameter entity, ELEMENT declaration, and ATTLIST declaration should be grouped together within the module. Each such group of declarations may occur in any order within the module. For example:

<!--                    LONG NAME: Topic Head                      -->
<!ENTITY % topichead.content
  "((%topicmeta;)?, 
    (%anchor; | 
     %data.elements.incl; | 
     %navref; | 
     %topicref;)* )
">
<!ENTITY % topichead.attributes
  "navtitle 
      CDATA 
          #IMPLIED
   outputclass 
      CDATA 
           #IMPLIED
   keys 
      CDATA 
          #IMPLIED
   %topicref-atts;
   %univ-atts;"
>
<!ELEMENT topichead    %topichead.content;>
<!ATTLIST topichead    %topichead.attributes;>

Attributes

[RDAnderson, 4 Jan 2010] In the final section about attributes, we should provide a pointer to the topic in the specialization section, "Element type class hierarchy declaration (the class attribute)". This section as written leaves out some details, without mentioning that more is required; we should indicate that complete details of constructing the class attribute are in the other topic.

The attributes of an element type must restrict or conserve those of the element type it specializes. Specialized element types may not add new attributes. New global attributes may be defined via attribute domain modules. Structural modules may require the use of attribute domain modules.

A vocabulary module must define a @class attribute for every specialized element declared in the module. The @class attribute must include the value of the @class attribute of the base element, and append to it the element name qualified by the topic element name with at least one leading and trailing space. The @class attribute for an element introduced by a structural specialization must start with a minus sign ("-"). The @class attribute for a domain specialization must start with a plus sign ("+"). The initial minus or plus sign must be followed by one or more spaces. The attribute value must end with one or more trailing spaces.

The ATTLIST declaration for the @class attribute must also include a reference to the %global-atts parameter entity.

For example, the ATTLIST definition for the <conbody> element (a specialization of the <body> element in the <topic> base type) includes global attributes with an entity, then the definition of the @class attribute, as follows:

<!ATTLIST conbody     %global-atts;  class CDATA "- topic/body  concept/conbody ">

The @class attribute declarations for a module must be grouped together at the end of the module after any other declarations. The declarations may occur in any order. By convention they are often ordered alphabetically or grouped logically.

See Element type specialization hierarchy declaration (the @class attribute) for complete details on the @class attribute.

2.2.1.4.3.8.1.2: Structural module coding requirements

A structural vocabulary module defines a new topic or map type as a specialization of a base topic or map type. The purpose is usually to enhance the user's interaction by adapting the topic or map type to its particular purposes.

A structural type module must conform to the following coding requirements in addition to the general module coding requirements:

Default included domains entity

The module must define the included-domains entity with a default value, as in the following example:

<!ENTITY included-domains "">

A document type shell can predefine the included-domains entity to list domains to be added to the document type.

Structural vocabulary modules may require the use of specific domains. In that case, the default value of the included-domains entity must include the appropriate domain use declaration, for example:

<!ENTITY included-domains "(topic myDomain)">

The list of included domains must declare the domains from most generic (on the left) to most specialized, current domain (on the right). See Domain usage declaration (the @domains attribute).

Topic and map element attributes

The topic or map element type must set the @DITAArchVersion attribute to the DITAArchVersion entity and the @domains attribute to the included-domains entity. These attributes give processors a reliable way to check the architecture version and look up the list of domains available in the document type.

<!ATTLIST concept    
  %concept.attributes;
  %arch-atts;
  domains 
    CDATA 
       "&included-domains;"
>

2.2.1.4.3.8.1.3: Topic type module coding requirements

Topic type vocabulary modules must conform to additional coding requirements for defining default topic nesting.

Default nested topics entity

A topic type module must define an entity to specify default subordinate topics. The entity name must be the topic element name plus the -info-types suffix. For example, the info-types entity for the concept topic is concept-info-types. If the topic has default subordinate topics, this entity can default to a list of element entities. If not, the entity can default to the value of the info-types entity as in the following example:

<!ENTITY % concept-info-types "%info-types;">

A document type shell can then control how topics are allowed to nest by redefining the topictype-info-types entity for each topic type, or it can efficiently create common nesting rules by redefining the main info-types entity.

In the declaration of the root element of a topic type, the last position in the content model must be the topictype-info-types nested topics entity, as in the following example:

<!ENTITY % concept.content
  "((%title;), 
    (%titlealts;)?,
    (%abstract; | 
     %shortdesc;)?, 
    (%prolog;)?, 
    (%conbody;)?, 
    (%related-links;)?,
    (%concept-info-types;)*)"
>

2.2.1.4.3.8.1.4: Element domain module coding requirements

An element domain vocabulary module defines element types that are appropriate for the subject-matter or application domain for which they are designed. The purpose is usually to enhance the user's interaction by providing semantic elements whose names more accurately denote their content, making that content easier to search and retrieve.

Domain entity file

In addition to the domain declaration entity, the entity declaration file for element domain modules must include the following components:

Element extension entity

The declaration (.ent) file must define an entity for each element extended by the domain. The base of the entity name is the abbreviation for the domain and the extension of the entity name is the name of the extended element. For example, the highlight domain (abbreviated as hi-d) extends the ph element, so the entity for the extended element is named hi-d-ph.

The value of the entity is a disjunctive list of the specialized elements that are intended to occur in the same locations as the extended element.

For example, the hi-d-ph entity is defined as follows:

<!ENTITY % hi-d-ph "b | u | i | tt | sup | sub">

2.2.1.4.3.8.1.5: Attribute domain module coding requirements

An attribute domain vocabulary module declares a new attribute specialized from either the @props or @base attribute. An attribute domain module defines exactly one new attribute type.

An attribute domain's name is the name of the attribute plus "Att" to distinguish the domain attribute from any element domains with the same name. For example, for an attribute named "new" the attribute domain name would be "newAtt". The attribute domain name is used to construct filenames and entity names for the domain.

An attribute domain must consist of one file, whose name consists of the module name plus Domain plus the ent extension. For example: newAttDomain.ent for an attribute named "new".

The file must have two parts:

Attribute extension entity

The attribute declaration is in an entity. This entity can then be used in document type shells to add the new attribute. The attribute declaration entity name consists of the attribute name plus "-d-attribute". For example:

<!ENTITY % newAtt-d-attribute "new   CDATA #IMPLIED">

For an attribute named "new".

Domain declaration entity

The attribute domain is declared in @domains attribute values through a general text entity that contains the attribute domain's domain declaration fragment. The entity name consists of the module name plus "-d-att". For example, "newAtt-d-att" for an attribute named "new". See Domain usage declaration (the @domains attribute) for details on attribute domain @domains values.

For example:

<!ENTITY newAtt-d-att       "a(props new)"  >

Attribute domains do not have domain module declaration (.mod) files.

2.2.1.4.3.8.2: XSD schema specialization module coding requirements

To be extensible and backward compatible, DITA requires that an XSD implementation of structural and domain specialization modules conform to well-defined implementation (coding) requirements.

These design patterns implement the specialization architecture with the capabilities and within the limitations of the XML Schema grammar. They are the coding requirements for structural specializations, domain specializations, and attribute domain specializations.

2.2.1.4.3.8.2.1: General element type declaration coding requirements

Structural and element domain vocabulary modules must reflect the same coding requirements for element type declarations.

[Jeff, 3 Jan 2010] I don't think it makes sense to have both a section for "General element type declaration coding requirements" and another for "Element domain module coding requirements". We should either combine them or give them better titles and otherwise reword them to make it clear what they are about what how they differ from each other. I'd favor combining them. I'm none too sure about the differences between the other sections on "Structural" and "Topic type" module coding requirements either. There seems as if there is a good deal over overlap between the sections, which I find confusing

Module names

Each vocabulary module has a short name that is used to construct file names, entity names, and other names used in associated declarations.

For structural modules, the module name must be the element type name of the top-level topic or map type defined by the module, such as "concept", "bookmap".

For attribute domain modules, the module name must be the name of the attribute defined by the module plus "Att" (to avoid conflict with similarly-named structural types or element domains).

Element definitions

A structural or domain vocabulary module must contain a declaration for each specialized element type named by the module. While the XSD standard allows content models to refer to undeclared element types, all element types named in content models within a vocabulary module must have an xs:element declaration, either in the vocabulary module, in a base module of which the vocabulary module is a direct or indirect specialization, or, for structural modules, in a required domain module. The specialized elements must follow the rules of the architecture in defining content models and attributes.

Domain modules must consist of a single XSD document named modulenameMod.xsd. Structural modules must consist of two modules, modulenameGrp.xsd, which contains all element name groups, and modulenameMod.xsd, which contains all other declarations for the module.

For each element type declared in the vocabulary module there must be an xs:group whose name is the element type name and whose one member is a reference to the element type, e.g.:

<xs:group name="codeph">
  <xs:sequence>
    <xs:choice>
      <xs:element ref="codeph"/>
    </xs:choice>
  </xs:sequence>
</xs:group>

The element name group provides a layer of abstraction that facilitates redefinition. A document type shell can redefine an element group to add domain-specialized elements or replace a base element type with one or more specializations of that type.

For domain modules, the group definitions should be grouped together at the start of the domain's XSD document. The definitions may occur in any order.

Each element type must have a corresponding content model group named tagname.content. The value of the group must be the complete content model definition. For example:

<xs:group name="codeph.content">
  <xs:sequence>
    <xs:choice minOccurs="0" maxOccurs="unbounded">
      <xs:group ref="basic.ph.notm" minOccurs="0"/>
      <xs:group ref="data.elements.incl" minOccurs="0"/>
      <xs:group ref="foreign.unknown.incl" minOccurs="0"/>
    </xs:choice>
  </xs:sequence>
</xs:group>

The content model group may be overridden in constraint modules to further constrain the content model for the element type.

Each element type must have a corresponding attribute group named tagname.attributes. The group must declare all attributes used by the element type except for the @class attribute. For example:

<xs:attributeGroup name="codeph.attributes">
  <xs:attribute name="outputclass" type="xs:string"/>
  <xs:attributeGroup ref="global-atts"/>
  <xs:attributeGroup ref="univ-atts"/>
</xs:attributeGroup>

Each element type must have a complex type definition named tagname.class, which references the tagname.content and tagname.attributes groups. For example:

<xs:complexType name="codeph.class" mixed="true">
  <xs:sequence>  
    <xs:group ref="codeph.content"/>
  </xs:sequence>        
  <xs:attributeGroup ref="codeph.attributes"/>
</xs:complexType>

Each element type must have an xs:element declaration named tagname, that uses as its type the tagname.class complex type and extends that complex type to add the class attribute for the element. For example:

<xs:element name="codeph">
  <xs:annotation>
    <xs:documentation>
      The code phrase (&lt;<keyword>codeph</keyword>&gt;) element represents a snippet
      of code within the main flow of text. The code phrase may be displayed in
      a monospaced font for emphasis. This element is part of the DITA programming
      domain, a special set of DITA elements designed to document programming tasks,
      concepts and reference information.
    </xs:documentation>
  </xs:annotation>
  <xs:complexType mixed="true">
    <xs:complexContent>
      <xs:extension base="codeph.class">
        <xs:attribute ref="class" default="+ topic/ph pr-d/codeph "/>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>
</xs:element>

The content model group, attribute group, complex type, and element type definition for an element should be grouped together within the module. Each such group of declarations may occur in any order within the module. It is recommended to sort the element type definitions alphabetically or group them into categories. Here is an example declaration for the <codeblock> element:

  <xs:element name="codeblock">
    <xs:annotation>
      <xs:documentation>
        The &lt;<keyword>codeblock</keyword>&gt; element represents lines of
        program code. Like the <ph>
          <xref href="xref.xml">&lt;<keyword>pre</keyword>&gt;</xref>
        </ph> element,
        content of this element has preserved line endings and is output in a monospaced
        font. This element is part of the DITA programming domain, a special set of
        DITA elements designed to document programming tasks, concepts and reference
        information.
      </xs:documentation>
    </xs:annotation>
    <xs:complexType mixed="true">
      <xs:complexContent>
        <xs:extension base="codeblock.class">
          <xs:attribute ref="class" default="+ topic/pre pr-d/codeblock "/>
        </xs:extension>
      </xs:complexContent>
    </xs:complexType>
  </xs:element>
  
  <xs:complexType name="codeblock.class" mixed="true">
        <xs:sequence>
          <xs:group ref="codeblock.content"/>
        </xs:sequence>
        <xs:attributeGroup ref="codeblock.attributes"/>
  </xs:complexType>
  
  <xs:group name="codeblock.content">
    <xs:sequence>
      <xs:choice minOccurs="0" maxOccurs="unbounded">
          <xs:group ref="basic.ph.notm" minOccurs="0"/>
          <xs:group ref="coderef" minOccurs="0"/>
          <xs:group ref="txt.incl" minOccurs="0"/>
          <xs:group ref="data.elements.incl" minOccurs="0"/>
          <xs:group ref="foreign.unknown.incl" minOccurs="0"/>
        </xs:choice>
    </xs:sequence>
  </xs:group>
  
  <xs:attributeGroup name="codeblock.attributes">
    <xs:attribute name="outputclass" type="xs:string"/>
        <xs:attribute name="spectitle" type="xs:string"/>
        <xs:attributeGroup ref="display-atts"/>
        <xs:attributeGroup ref="univ-atts"/>
        <xs:attribute ref="xml:space" fixed="preserve"/>
        <xs:attributeGroup ref="global-atts"/>
  </xs:attributeGroup>

Each xs:element declaration should include descriptive documentation as in the examples above.

2.2.1.4.3.8.2.2: Structural specialization coding requirements

An XSD structural module declares a top-level map or topic type, implemented as a pair of XSD documents, one that defines groups used to integrate and override the type and one that defines the element types specific to the type.

A structural type module must conform to the following coding requirements in addition to the general module coding requirements:

Module files

A structural vocab

Darwin Information Typing Architecture (DITA) Version 1.2

OASIS Standard

1 December 2010

DITA Version 1.2 Specification

Chapter 1: Introduction

1.1.1: Terminology

1.1.2: Normative references

1.1.3: Non-normative references

1.1.4: Formatting conventions in the XHTML version of the specification

Link previews

Link previews

Navigation links

Navigation links

Chapter 2: Architectural specification

2.2.1: Architectural Specification: Base

2.2.1.1: Introduction to DITA

2.2.1.1.1: About the specification source

2.2.1.1.2: DITA terminology and notation

Notation

Normative and non-normative information

Basic DITA terminology

Specialization terminology

DITA modules

Instances, modules, and declarations

Linking and addressing terms

2.2.1.1.3: Basic concepts

2.2.1.1.4: File naming conventions

Note

2.2.1.1.5: Producing different deliverables from a single source

2.2.1.2: DITA markup

2.2.1.2.1: DITA topics

2.2.1.2.1.1: The topic as the basic unit of information

2.2.1.2.1.2: The benefits of a topic-based architecture

2.2.1.2.1.2.1: Disciplined, topic-oriented writing

Conciseness and appropriateness

Locational independence

Navigational independence

2.2.1.2.1.2.2: Transitional text solutions

2.2.1.2.1.3: Information typing

2.2.1.2.1.4: Generic topics

2.2.1.2.1.5: Topic structure

2.2.1.2.1.6: Topic content

2.2.1.2.1.7: Topic domains: Basic DITA

DITA topic domains: Basic DITA

2.2.1.2.2: DITA maps

2.2.1.2.2.1: Definition of DITA maps

2.2.1.2.2.2: Purpose of DITA maps

2.2.1.2.2.3: DITA map elements

Map and map group elements

Example of a simple map with a relationship table

Example of a simple map that defines keys

Example of a simple map that references another map

Example of maps that use the <anchor> element and the @anchorref attribute

2.2.1.2.2.4: DITA map attributes

Attributes unique to DITA maps

Note

Note

Attributes shared by DITA maps and DITA topics

How the collection-type and linking attributes work in a relationship table

Simple linking example

Linking example with the linking attribute

2.2.1.2.2.5: Subject scheme maps

Defining a list of controlled values

Validating metadata attributes against a subject scheme

Scaling a subject scheme to define a taxonomy

2.2.1.2.3: DITA metadata

2.2.1.2.3.1: Metadata elements

Note

Related information:

2.2.1.2.3.2: Metadata attributes

2.2.1.2.3.2.1: Conditional processing attributes

Filtering and flagging attributes

Other metadata attributes

Related information:

2.2.1.2.3.2.2: Translation and localization attributes

2.2.1.2.3.2.3: Architectural attributes

2.2.1.2.3.3: Metadata in maps and topics

Where metadata about topics can be specified

How metadata set at both the map and topic level is handled

Associating attribute-based metadata with element-based metadata

`test-2.ditamap`