reltable

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.

Relationship tables can be used in conjunction with hierarchies and groups to manage all the related links in an information set.

Contains

( (topicmeta) (optional) then (relheader) (optional) then (relrow) (one or more) )

Contained by

map

Inheritance

map/reltable

Attributes

Name	Description	Data Type	Default Value	Required?
title	An identifying title for this element.	CDATA	#IMPLIED	No
%topicref-atts-no-toc; (collection-type, type, locktitle, format, linking, print, search, chunk)	A related set of attributes. See %topicref-atts-no-toc;.	parameter entity	PE not applicable	Not applicable
%select-atts; (platform, product, audience, otherprops, importance, rev, status)	A set of related attributes, described at %select-atts;	parameter entity	PE not applicable	Not applicable
%global-atts; (xtrf, xtrc)	A set of related attributes, described at %global-atts;	parameter entity	PE not applicable	Not applicable
class	A common attribute described in Other common DITA attributes

Example

In this example, a relationship table is defined with three columns; one for "concept", one for "task", and one for "reference". Three cells are defined within one row. The first cell contains one concept topic: batsonar.xml. The second cell contains two task topics: batcaring.xml and batfeeding.xml. The third cell contains two reference topics: batguano.xml and bathistory.xml.

<map>
 <reltable>
  <relheader>
   <relcolspec type="concept">
   <relcolspec type="task">
   <relcolspec type="reference">
  </relheader>
  <relrow>
   <relcell><topicref href="batsonar.dita"/></relcell>
   <relcell><topicref href="batcaring.dita"/><topicref
   href="batfeeding.dita"/></relcell>
   <relcell><topicref href="batguano.dita"/><topicref
   href="bathistory.dita"/></relcell>
  </relrow>
 </reltable>
</map>

A table view of the tagging would look like this:

type="concept"	type="task"	type="reference"
batsonar.dita	batcaring.dita, batfeeding.dita	batguano.dita, bathistory.dita

On output, links should be added to topics that are in the same row, but not in the same cell. This allows simple maintenance of parallel relationships: for example, in this case, batcaring.dita and batfeeding.dita are two tasks that require the same supporting information (concept and reference topics) but might otherwise be unrelated. When topics in the same cell are in fact related, the cell's collection-type attribute can be set to family. If some cells or columns are intended solely as supporting information and should not link back to topics in other cells, you can set the linking attribute on the cell or column to targetonly.

In this example, the related links would be as follows:

batsonar.dita: batcaring.dita, batfeeding.dita, batguano.dita, bathistory.dita
batcaring.dita: batsonar.dita, batguano.dita, bathistory.dita
batfeeding.dita: batsonar.dita, batguano.dita, bathistory.dita
batguano.dita: batsonar.dita, batcaring.dita, batfeeding.dita
bathistory.dita: batsonar.dita, batcaring.dita, batfeeding.dita

Although the table may initially take some time to learn and manipulate, it is inherently a more efficient form to manage these links. It is also easier to see and manage patterns using the table; for example, the fact that batfeeding.dita and batcaring.dita have the same relationships to supporting information is clear from the table, but would require some comparison and counting to determine from just the definition list summary.