A map describes the relationships among a set of DITA topics. The following
are some examples of relationships that can be described in a map:
- Hierarchical (Parent/Child). Nested topics create a hierarchical relationship.
The topic that does the nesting is the parent, and the topics that are nested
are the children.
- Ordered. Child topics can be labeled as having an ordered relationship,
which means they are referenced in a definite sequence.
- Family. Child topics can be labeled as having a family relationship, which
means they all refer to each other.
The relationships defined in a map can be used to create a Table of Contents
(TOC), aggregate topics into a PDF document, or to create links between topics
The <map> element is used to define a map
which describes the relationships among a set of resources, such as DITA topics.
Maps consist of references to topics and other resources organized into hierarchies,
groups, and tables. Maps provide a way to express these relationships in a
single common format that can be used for different outputs.
The <anchor> element is used for runtime
integration of navigation. It provides an integration point that another map
can point to in order to insert its navigation into the current navigation
tree. It is currently supported by Eclipse output only.
The <navref> element references a map file
from within a map file. The reference is resolved at runtime for Eclipse
navigation, typically to pull together the navigation for multiple components
into a product navigation. This element is for runtime resolution
of references, and is for navigation only. It is currently only supported
by Eclipse output.
The relationship table (<reltable>) defines
relationships between topics, based on the familiar table model of rows (<relrow>),
columns (<relheader>), and cells (<relcell>).
The <relcell> elements can contain <topicref>
elements, which are then related to other <topicref>
elements in the same row (although not necessarily in the same cell). By default,
the contents of a <reltable> element are not output
for navigation or TOC purposes, and are used only to define relationships
that can be expressed as topic-to-topic links.
A <relrow> is a row in the relationship table.
This creates a relationship between the cells in the row, which will end up
expressed as links among the <topicref> elements in
A <relcell> element is a cell in the relationship
table. The <topicref> elements it contains will be related
to topicrefs in other cells of the same row. By default, topicrefs in the
same cell are not related to each other, unless you change the relcell's collection-type
attribute to indicate that they are related.
The <relheader> element is a row of column
definitions (<relcolspec> elements) in a relationship
table. Each table can have only one set of column definitions.
A column definition in the relationship table. You can use <relcolspec>
column definitions to set defaults for the attributes of <topicref>
elements in the column. For example, you can set type="concept" to treat all
untyped <topicref> elements in the column as concepts.
The <topicmeta> element defines the metadata
that applies to a topic when it appears in a map, and to the other topics
in the map that are contained by the same element that contains the <topicmeta>
element. When creating links, it can also be used to override the title and
short description of the topic. In addition, it can be used to add index entries
to referenced content using the <keywords> element.
The <topicref> element identifies a topic
(such as a concept, task, or reference) or other resource. A <topicref>
can contain other<topicref> elements, allowing you to
express navigation or table-of-contents hierarchies, as well as implying relationships
between the containing <topicref> and its children.
You can set the collection-type of a container <topicref>
to determine how its children are related to each other. You can also express
relationships among <topicref>s using group and table
structures (using <topicgroup> and <reltable>).
Relationships end up expressed as links in the output (with each participant
in a relationship having links to the other participants by default).
OASIS DITA Language Specification v1.0 -- 09 May 2005
Copyright (c) OASIS Open 2005. All Rights Reserved.