Introduction
Information types and topics
Topics are the building blocks of modular documents, and organising topics by semantic information types is one of the architectural features of DITA.
DITA map files
Syntax and mark-up
Language and punctuation
Graphics and figures
Cross-referencing
Cross-references are a means of binding individual topics into a coherent and navigable document.
Content re-use
Metadata, conditional processing, and indexing
- Conditional processing concepts
  When DITA content is processed to a reading format, rules to exclude or highlight some of the content can be defined in a ditaval file. This conditional processing requires metadata attributes to be set on DITA elements that may possibly be excluded or highlighted.
- Condition (or select) attributes
  The audience, platform, product, otherprops and rev attributes can be applied to most DITA elements. They are used for conditional processing, and are known as the condition (or select) attributes.
- Filtering and flagging
  Content marked with metadata attributes can be conditionally processed so that the content is filtered (excluded) or flagged (highlighted) in the published output.
  - Excluding topics: conditional processing at topic level
    If a whole topic is to be excluded from the output in a conditional processing scenario (that is, the condition applies to a whole topic), the metadata attribute must be defined in the topic reference in the ditamap.
  - Conditional processing dangers
    Any filtering conditions that apply must still result in valid DITA mark-up.
  - Conditions versus transclusion
    Transclusion, or content referencing, can sometimes achieve the same publishing aim as conditional processing. There are pros and cons for either method.
  - Include and exclude filtering actions
    In typical publishing tools, filtering and flagging actions to be taken during processing are defined in a ditaval file.
  - Limiting the use of conditions
    You should take care to limit the complexity of conditions that you apply to content. Context-agnostic writing is often a better approach.
  - Filtering ditamaps
    When filtering a nested ditamap, you should apply the condition attribute to the reference (topicref or mapref element) to the nested ditamap, rather than to the map element.
  - Filtering composite (ditabase) topics
    Care must be taken when applying conditions to composite topics, as filtering a nested topic through the topicref element will not necessarily result in the topic being excluded.
  - Print versus non-print metadata
    You can use condition attributes in topic elements, the print attribute in the topicref element, separate ditamaps, or a combination of these approaches when you need to produce different print and non-print versions of the same document.
- Other metadata
  In addition to the select attributes, DITA content includes many forms of metadata. These metadata elements and attributes are used to manage and organise topics, ditamaps and publications.
- Indexing
  DITA incorporates powerful features for indexing, including multi-level indexing, and see and see-also redirection. Index entries can be applied in the ditamap, in the topic prolog, and inline within the topic content.
The DITA documentation process
DITA authoring concepts
Moving from style-based authoring to a structured authoring methodology such as DITA requires a radically different approach to writing.

Filtering ditamaps

When filtering a nested ditamap, you should apply the condition attribute to the reference (topicref or mapref element) to the nested ditamap, rather than to the map element.

It is possible in DITA, and often good practice, to have nested ditamaps. Although it does depend on circumstance, it is generally better practice to apply conditions to the topicref or mapref element, rather than the map element of the nested ditamap.

The reason for this, and a point that should always be considered when deciding on a filtering strategy, is the reduced processing load during generation of the output. If the processor has to read in a topic, or a nested map, only to find it's not needed in the current build because of the filtering metadata, it is an inefficient model. It is much better for the exclusion to be notified to the processor before having to load the file.