Working with maps

DITA maps collect and organize references to DITA topics to indicate the relationships among the topics. They can be used to identify the topics you want to include in a deliverable, and to create tables of contents and related links for the information.

Maps can organize topics into hierarchies, tables, and groups, and also have special elements for referencing other maps. You can use multiple maps to pull different deliverables out of the same set of topics, and to separate the concerns of managing deliverables and architecting information from the concerns of topic authoring.

The architectural specification describes DITA maps and relationship tables at

http://docs.oasis-open.org/dita/v1.1/OS/archspec/dita_spec_23_maps.html.

For a practical approach to setting up relationship tables, see

http://dita.xml.org/improving-relationships-relationship-tables

Controlling heading hierarchies using ditamaps

People often ask what to do to make extra headings and levels of hierarchy appear within a table of contents.

A common misconception is that if a map includes a submap, the title of the submap will appear as an extra heading in output. This does not occur. Also, the topics within the submap appear at the same hierarchy level as other topics that are peer to the submap itself; being in a submap does not cause extra "indenting".

To add an extra heading to a map, a good method is to use a <topicref> element pointing to a topic that contains a title and nothing else. This method is easy to manage for translation.

Another method is to use the <topichead> element. This element did not appear in PDF output using previous versions of the DITA Open Toolkit. However, version 1.4 of the DITA Open Toolkit does create headings from <topichead>.

Tools for modeling maps

The Information Architecture Workbench (formerly IBM Task Modeler) enables you to analyze the organization of your content and creates a corresponding DITA map along with stub topics for to-be-developed topics in the map.

This tutorial provides a quick but comprehensive introduction to using the IAWB to analyze and create a complete map of a sample scenario: IAWB Handout by Ben Welman.

Editors for the Architecture area:

Improving Relationships in Relationship Tables

A team encounters quite a few challenges when transitioning from unstructured to structured writing. For my team, the struggles associated with learning DITA and following the DITA structure were minor compared with the challenges presented by corralling hundreds of individual topics into a logical hierarchy. The biggest challenge we faced was managing topic relationships.

In DITA, related topics can be managed either in the DITA topics themselves, or via DITAMAPs using relationship tables <reltable>.

While topic relationships can be stored in the topics themselves, as products evolve and user interfaces change, a topic that was required for release 1.0 of a product may no longer be needed in release 2.3. If related topics are maintained at the topic level, removing a topic that is no longer part of the system may involve modifying the related topics of a dozen different DITA files.

However, if related topics are managed using a relationship table in a DITAMAP, removing a topic that is no longer needed involves changing only one file. Relationship tables can be used to easily manage the related topics that are associated with each DITA topic.

After doing a lot of research into relationship tables, my team nearly abandoned the effort because mapping a large number of topics in the standard three-column relationship table was too complex. However, once we realized that a four-column approach was much more effective in creating and maintaining the relationships between DITA topics, our information modeling and online help creation process became much easier to manage.

Example Files

To illustrate the benefits of a four-column relationship table, the following example topics will be used.

Concept Topics

The following concept topics are designed to introduce the subject matter to the reader. These topics will cover information ranging from, "What is it?" to "Why should the reader care?"

What is a user? (user_c.dita)
What is a role? (role_c.dita)
How are users and roles related? (user_role_c.dita)

Task Topics

The following task topics are designed to walk the user through a procedure that goes from step 1 to step N, with the end result being the successful completion of the task at hand.

Create a new user account (user_create_t.dita)
Edit an existing user account (user_edit_t.dita)
Create a new role (role_create_t.dita)
Edit an existing role (role_edit_t.dita)
Associate a user account with a role (user_role_associate_t.dita)

Reference Topics

The following reference topics are designed to support the user in completing a task. For example, if step 3 of our task instructs the user to complete field xyz, the reference topic for that window will describe field xyz and include supporting background information that may not appear in the task.

User Account window details (user_r.dita)
Role window details (role_r.dita)

Desired Outcome

Using a standard three-column relationship table and a four-column relationship table, the following relationships will be applied to each topic in the example documentation set:

Standard Three-Column Relationship Table

Each row in a relationship table defines an individual set of relationships between topics. In the relationship table diagram below, there are seven rows that are used to define the relationships between ten different topics. The difficulty in dealing with this type of relationship table is that the relationships for some topics are defined in multiple rows. So when a topic relationship changes, the writer maintaining the DITAMAP must perform a detailed analysis of the relationship between topics in several rows to enact a change.

In DITA, these relationships are expressed as follows:

Four-Column Relationship Table

While the four-column relationship table below has three more rows than the standard three-column relationship table, the larger table makes it much easier to maintain the relationships between the various relationships between the topics. In the example below, when a topic relationship changes, the writer can simply locate and modify a single row that defines the links for that topic.

In DITA, these relationships are expressed as follows:

Conclusion

Using a four column relationship table in our SunGard Higher Education DITAMAPs, we are able to easily maintain the relationships between hundreds of topics authored by a distributed writing team. Each team member can modify the specific row that applies to the topic in question without having to analyze the relationships of any other topic.

While proper up-front planning is still vital to assign topic relationships, knowing that each source topic is always located in the first column and all target topics can be found in columns based on the topic type has made the job of maintaining those relationships much easier. -->

-Zak Binder
Advisory Technical Writer
SunGard Higher Education
zak.binder@sungardhe.com