Continuing discussion of issue 16: alternate titles

[Chris Nitchie <cnitchie@gmail.com>]

I think I've got my head around this again. Thanks to Eliot's
thoughtful contribution to the list last month, which I'd reply to if
it wasn't to an e-mail address I don't have access to any more.

So we have the following alternate title types that should probably be
supported by most processors:

- Navigation title - ToC and other navigation
- Related link title
- Variable text for empty key references
- Hint for map authors, with no processing implications
- Title for use in empty cross-references

(This last is not supported, so far as I know, in DITA 1.3, and hasn't
really been discussed but makes sense to me for completeness' sake.)

The more I think about it, the more I think Eliot's right that having
separate specializations for all of these cases, and relationships
between them for fallback and whatnot, while technically complete and
maximally flexible, would be overwhelming for most authors, as well as
unnecessary, since the text for all four cases will almost certainly
be the same in the vast majority of cases.

So let me amend my proposal (again) to the following:

1. Each of the above use-cases will have a dedicated, specific
@title-role token described in the spec.
2. In addition, there will be a "default" title-role token whose
purpose is to act as the fallback alternate title in the absence of a
more specific alternate title for a given use case. For example, in
the absence of a specific <titlealt title-role="searchtitle">,
<titlealt title-role="default"> would be used.
3. The only <titlealt> specialization provided in the default grammar
files will be <navtitle>. The title-role for <navtitle> will be
"default", or maybe "navtitle default".
4. <searchtitle> and <linktext> (in maps) will be removed from the
grammar files. The migration plan for them will be to change them to /
combine them with <navtitle> by default, and to make them a <titlealt>
elements with the appropriate @title-role if and only iff there is
also a <navtitle> present with different content (unless
@locktitle="yes" in which case things get more complicated; the full
rules will be spelled out in the proposal).
5. The removal of <linktext> obviously has major implications for
variable text in key references, which will be discussed in detail in
a separate proposal for simplifying the rules around variable text
resolution in empty key references.

I think this gives us the best of both worlds. The <navtitle> element
becomes the One Alternate Title to Rule them All, and will support the
majority/simple case where there is no need for more use-case-specific
alternate titles. However, the ability to author such specific
alternate titles remains available to those who need it.

Chris