Re: [dita] ITEM: Cross-references to Topicheads and ImplicitTitle-only Topics

[Eliot Kimber <ekimber@reallysi.com>]

On 4/7/09 9:55 AM, "Michael Priestley" <mpriestl@ca.ibm.com> wrote:

> Why is it acceptable for href and conref to mean different things, but not
> href and keyref?

Conref is establishing a different *semantic* from href/keyref, namely a
use-by-reference link, rather than a navigation relationship.

Keyref/href are alternatives forms of addressing for establishing the same
relationship, navigation.

That is, conref/conkeyref are alternative forms of address for a single
semantic and href/keyref are alternative forms of address for a *different*
single semantic.

The key is the nature of the relationship, not the form of address used.

Or said another way, conref is a shorthand for having *different* element
types, one for each existing element type, that mean only "use by
reference". If DITA had such elements, there would only be href/keyref
attributes because the linking semantic would be defined by the element
type. Because DITA allows a single element type to convey two different core
semantics, there have to be different pointing attributes to make the
semantic distinction.

If we had been able to come up with a syntax that allowed keyrefs where URIs
are allowed, we would have avoided the need for keyref/conkeyref entirely
but we determined that such a syntax would be too difficult to use, so we
defined distinct attributes.

In the case of elements like <term>, we added keyref= in recognition that
href= would *never be a good idea* because it's not manageable (because it's
a hard address, irrespective of whether it went through a topicref
indirection or not) and it would be pointless to allow people to create
unmanageable pointers when the whole point is to enable reuse of topics
within multiple contexts.

Xref in DITA has always been a problem because without late-bound,
context-specific addresses there is no way to make it manageable when
pointing to other topics. Even if DITA had *always* said that topicrefs act
as indirections (which in some implementations they did), it wouldn't have
helped because the problem is the href= itself, not the lack of indirection.

Keyref= solves the problem by being late-bound, which *enables* the
manageable use of indirection.

The keyref facility requires that topicrefs act as indirectors, at least in
some circumstances. Either they *always were* indirectors (and the spec
failed to mention it) or they *are now* and therefore need to be for all
uses of topicref from other elements (possibly modified by controls on the
initial linking element).

I think this is a very simple principle for which the processing
implications can be clearly enumerated by applying the principle.

That is, the question is "source element X is pointing to a topicref that
has property configuration Y, what is the ultimate link target?" The answer
should be arrived at by a purely mechanical process that is independent of
the form of initial address.

Cheers,

Eliot
----
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>