OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [dita] Continuing discussion of issue 16: alternate titles

I like it, Chris.  Much simpler and straight forward.

Bill Burns
Content Architect | Healthwise
bburns@healthwise.org | www.healthwise.org
208.331.6917 (office)Â |Â 208.345.1897 (fax)

-----Original Message-----
From: dita@lists.oasis-open.org <dita@lists.oasis-open.org> On Behalf Of Chris Nitchie
Sent: Saturday, January 25, 2020 4:27 PM
To: dita@lists.oasis-open.org
Subject: [dita] Continuing discussion of issue 16: alternate titles

*** External email: use caution ***

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.


To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at:

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]