DITA 1.3 Issue: Element-to-Element Relationship Tables (ExternalLinks)

[Eliot Kimber <ekimber@reallysi.com>]

The purpose of this note is to register an issue for discussion in DITA 1.3.

At the DITA NA conference Seth Park's talk about using reltables to link
DITA content to non-DITA content at the element level revealed the problem
that DITA 1.2 provides no standard-defined way to create the equivalent of
relationship tables for element-to-element links.

This is because <topicref> and <link> can only point to whole topics. This
is a core architectural design feature that we would revisit at our peril.

However, Michael Priestly pointed out that one could easily specialize
simple-table to define the equivalent of reltable, using <xref> in place of
<topicref>. This can be done today by anyone who wants to.

Note that these element-to-element relationships are fundamentally different
from conref push, although the desired presentation effect may often be the
same.

For example, you might want to impose commentary or other value-add
information onto content provided by a third party, where the constraints of
conref do not allow you to push your elements onto the source (for example,
because the source is more specialized than your source and in a way that
would be impossible or inappropriate to use as a local specialization base).
In the case of my client at the moment, they want to annotate individual
paragraphs within the DITA-based Codified GAAP accounting standards they
license from the FASB.

A reltable-type approach would satisfy the requirement by allowing the
element-level association without imposing conref's compatibility
constraints. 

I don't think it's necessary, or probably even appropriate, for these sorts
of links to be in a map--MP's point that maps should not know about
sub-topic elements is an important principle and I see no reason to violate
it here. With keyref, a table of links within a topic can still be
manageable.

As the 1.3 process progresses I will take the action to coordinate
development of a more formal proposal for this.

Cheers,

E.

----
Eliot Kimber | Senior Solutions Architect | Really Strategies, Inc.
email:  ekimber@reallysi.com <mailto:ekimber@reallysi.com>
office: 610.631.6770 | cell: 512.554.9368
2570 Boulevard of the Generals | Suite 213 | Audubon, PA 19403
www.reallysi.com <http://www.reallysi.com>  | http://blog.reallysi.com
<http://blog.reallysi.com> | www.rsuitecms.com <http://www.rsuitecms.com>