<map>
A DITA map is the mechanism for aggregating topic references and defining a context for those references. It contains references to topics, maps, and other resources. These references are organized into hierarchies, groups, and tables.
Usage information
A map describes the relationships among a set of DITA topics. The following are some types of relationships that can be described in a map:
- Hierarchical
- 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.
In addition, a DITA map can contain relationship tables. Relationship tables can define relationships between resources that are not directly related based on their location in the navigation structure.
I moved this content about titles in maps from "Rendering expectations," where I do not think it belonged. I think we probably ought to be clearer about the scenarios in which titles are rendered; certainly users get confused about this. And do we cover processing expectations for submaps somewhere?
The <title> element can
be used to provide a title for the map. In some scenarios the
title is purely informational and is present only as an aid to
the author. In other scenarios, the title might be useful or even
required. In a map referenced by another map, the title might be
discarded as topics from the submap are aggregated into a larger
publication.
Rendering expectations
When rendering a map, processors might make use of the relationships defined in the map to create a table of contents (TOC), aggregate topics into a PDF document, or create links between topics in the output.
Processing expectations
See DITA maps and DITA processing.
Content model
<title>?, <topicmeta>?, (<data> | <navref> | <reltable> | <topicref>)*
Not contained by any element.
- Optional
<title> - Optional
<topicmeta> - Zero or more of the following
Not contained by any element.
Inheritance
- map/map
The <map> element is a base element type. It is defined in the map module.
Attributes
The following attributes are available on this element: architectural
attributes, common map attributes, universal
attributes, @format, @scope, and @type.
The following attributes are available on this element: universal attributes and the attributes defined below.
@cascade(common map attributes)-
Specifies how metadata attributes cascade within a map. The specification defines the following values:
- merge
- Indicates
that the metadata attributes cascade, and that the
values of the metadata attributes are additive. This is the
processing default for the
@cascadeattribute. - nomerge
- Indicates
that the metadata attributes cascade, but that they are
not additive for
<topicref>elements that specify a different value for a specific metadata attribute. If the cascading value for an attribute is already merged based on multiple ancestor elements, that merged value continues to cascade until a new value is encountered. That is, settingcascade="nomerge"does not undo merging that took place on ancestor elements.
Processors can also define custom, implementation-specific tokens for this attribute.
See Cascading of metadata attributes in a DITA map for more information about how this attribute interacts with metadata attributes.
@chunk(common map attributes)- Specifies how a processor should render a map or branch of a map. For example, it can be used to specify that individual topic
documents should be rendered as a single document, or that a single document with
multiple topics should be rendered as multiple documents.The following values are valid:
- combine
- Instructs a processor to combine the referenced source documents for rendering purposes. This is intended for cases where a publishing process normally results in a single output artifact for each source XML document.
- split
- Instructs a processor to split each topic from the referenced source document into its own document for rendering purposes. This is intended for cases where a publishing process normally results in a single output artifact for each source XML document, regardless of how many DITA topics exist within each source document.
Processors can also define custom, implementation-specific tokens for this attribute.
For a detailed description of the
@chunkattribute and its usage, see Chunking. @collection-type(common map attributes)- Specifies how topics or links relate to each other. The
processing default is unordered, although no
default is specified in the OASIS-provided grammar files. The
following values are valid:
- unordered
- Indicates that the order of the child topics is not significant.
- sequence
- Indicates that the order of the child topics is significant. Output processors will typically link between them in order.
- choice
- Indicates that one of the children should be selected.
- family
- Indicates a tight grouping in which each of the
referenced topics not only relates to the current topic
but also relate to each other. Draft comment: Kristen J Eberlein 28 September 2022
Here is the content from the "DITA map attributes" topic:
@collection-type- The
@collection-typeattribute 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-typevalue 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. This attribute is available in topics on the<linklist>and<linkpool>elements, where it has the same behavior. Where the@collection-typeattribute is available on elements that cannot directly contain elements, the behavior of the attribute is undefined.
Draft comment: robanderTO RESOLVE 13 May 2026: Make sure nothing here conflicts, and add a link from this to the architectural sectionDraft comment: Kristen J Eberlein 28 September 2022In the definitions of the supported values, do we want to refer to "resources" instead of "topics"? Since we specify that
@collection-typespecifies "how topics or links relate to each other" ...Draft comment: robanderTO RESOLVE 13 May 2026: Good point, no strong feeling, but we should be consistent here, we already use "topics", "child topics", "children", and "referenced topics". Maybe:- Start with "Specifies how child topic references or links within the current element relate to each other"? Since this applies to children and we only sort of say that in the definitions of the tokens
- When describing the tokens, maybe use "referenced resources", as in "Indicates that the order of the referenced resources is not significant"
@DITAArchVersion(architectural attributes)- Specifies the version of the DITA architecture that is in
use. This attribute is in the namespace
http://dita.oasis-open.org/architecture/2005/. This attribute is specified in the topic and map modules, and it uses a default value of the current version of DITA. The current default is 2.0. @format(link-relationship attributes)- Specifies the format of the resource that is referenced. See The format attribute for detailed information on supported values and processing implications.
@keyscope(common map attributes)- Specifies that the element marks the boundaries of a key
scope.
See The keyscope attribute for information on using this attribute.
Draft comment: Kristen J Eberlein 28 September 2022Here is the content from the "DITA map attributes" topic:
@keyscope- Defines a new scope for key definition and resolution, and gives the scope one or more names. For more information about key scopes, see Indirect key-based addressing.
Draft comment: robanderTO RESOLVE 13 May 2026: Double check each to make sure the latest content is consistent, and remove the draft commentBut also … it might be a good idea to keep this draft comment (and others for the keys/keyref stuff) until after that section is fully reviewed, so that we have an easy way to find these "content should be consistent" issues
@linking(common map attributes)- Specifies linking characteristics of a topic specific to the location of this
reference in a map. If the value is not specified
locally, the value might cascade from another element in the map
(for cascade rules, see Cascading of metadata attributes in a DITA map).
The following values are valid:Draft comment: robander Dec 28 2021The text below matches 1.3 spec text but I'm nervous about "cannot link" type definition. It's describing how to generate links based on the current context in the map - it's not describing what the topic itself is allowed to link to, which is how I interpret "can".Draft comment: robanderTO RESOLVE 13 May 2026: Yeah we should remove the can/cannot and replace with a description of the intent here... like, targetonly "The topic or resource can be the target of any context based linking, but is not meant to be updated with links related to this context."
similarly, none could be "The topic or resource does not participate in any context-based linking"
- targetonly
- A topic can only be linked to and cannot link to other topics.
- sourceonly
- A topic cannot be linked to but can link to other topics.
- normal
- A topic can be linked to and can link to other topics. Use this to override the linking value of a parent topic.
- none
- A topic cannot be linked to or link to other topics.
- -dita-use-conref-target
- See Using the -dita-use-conref-target value for more information.
Draft comment: Kristen J Eberlein 28 September 2022Here is the content from the "DITA map attributes" topic:
@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
@linkingattribute, which enables an author or information architect to specify how a topic participates 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.
Draft comment: robanderTO RESOLVE 13 May 2026: Ensure there is nothing conflicting, and add a link from here to the more architectural info that gives all the details @processing-role(common map attributes)- Specifies whether the referenced resource is processed
normally or treated as a resource that is only included in order to resolve references,
such as key or content references. The following values are valid:
- normal
- Indicates that the resource 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. - resource-only
- Indicates that the resource should be used only for processing purposes. 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.
- -dita-use-conref-target
- See Using the -dita-use-conref-target value for more information.
If no value is specified but the attribute is specified on a containing element within a map or within the related-links section, the value cascades from the closest containing element.
@scope(link-relationship attributes)- Specifies the closeness of the relationship between the
current document and the referenced resource. The following values are valid:
local, peer,
external, and
-dita-use-conref-target.
See The scope attribute for detailed information on supported values and processing implications.
@search(common map attributes)- Specifies whether the target is available for searching. If the value is not specified
locally, the value might cascade from another element in the map
(for cascade rules, see Cascading of metadata attributes in a DITA map). The following values are valid:
yes, no, and
-dita-use-conref-target.Draft comment: Kristen J Eberlein 28 September 2022
Here is the content from the "DITA map attributes" topic:
@search- Specifies whether the topic is included in search indexes.
Draft comment: robanderTO RESOLVE 13 May 2026: Update to use the same description, these are very similar but not exact. If the description is this short and similar it should be reused with conref. @specializations(architectural attributes)- Specifies the attribute-domain specializations that are
included in the document-type shell. This attribute is set as a
default within the document-type shell. The value varies
depending on what domains are integrated into the document-type
shell. For example, a
grammar file that includes the specialized attributes
@audience,@deliveryTarget, and@newBaseAttwould set the value to@props/audience @props/deliveryTarget @base/newBaseAtt. @subjectrefs(common map attributes)- Specifies one or more keys that are each defined by a subject definition in a subject scheme map. Multiple values are separated by white space.
@toc(common map attributes)- Specifies whether a topic appears in the table of contents (TOC) based on the current
map context. If the value is not specified
locally, the value might cascade from another element in the map
(for cascade rules, see Cascading of metadata attributes in a DITA map). The following values are valid:
- yes
- The topic appears in a generated TOC.
- no
- The topic does not appear in a generated TOC.
- -dita-use-conref-target
- See Using the -dita-use-conref-target value for more information.
Draft comment: Kristen J Eberlein 28 September 2022Here is the content from the "DITA map attributes" topic:
@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.
Draft comment: robanderTO RESOLVE 13 May 2026: I read that and kind of hate "web site map". Kind of think we should delete that bit from the other topic, and replace the first sentence there with a reused sentence from here. @type(link-relationship attributes)- Describes the target of a reference. See The type attribute for detailed information on supported values and processing implications.
Example
This section is non-normative.
The following code sample contains four
<topicref> elements. The
<topicref> elements are nested and so have
a hierarchical relationship. The file
widget.dita is the parent topic, and the
other topics are its children. The hierarchy could be used to
generate a PDF, a navigation pane in a web-based
information system, a summary of the topics, or related
links between the parent topic and its children.
<map id="widget-setup">
<title>Widget set up</title>
<topicref href="widget.dita">
<topicref href="widget-installation.dita"/>
<topicref href="widget-configuration.dita"/>
<topicref href="widget-integration.dita"/>
</topicref>
</map>
Most of the information below was authored for DITA 1.0 and subsequently edited.
Zoe Lawson identified a key problem with this information; it does not discuss key definition or key resolution. If this section is going to contain all this info about navigation relationships, then it really also needs to discuss keys.
And then the example should illustrate not just a DITA map creating navigational hierarchy, but also a map that references a key-definition map.