I know that the existing DITA 1.x behavior was designed intentionally â but I really donât know how often that behavior is used as intended, or how often authors are surprised by it. Itâs likely that neither of those happens often, because the most common case is âI want my link text to match the topic titleâ, for which case link text is not even specified.
I think part of the reasoning behind the current behavior is: because maps are providing an explicit context and also generating links, any link text overriding the title is also contextual. For example: if Iâve set up an ordered list of tasks in my map, I could provide link text so that any Next/Previous/Child links refer to that context. The link text would be inappropriate for most other links to that topic.
I donât know how often anyone makes use of this. To me, the current behavior seems logical, and the new behavior would be unexpected. Iâm sure that comes from how Iâve always thought of these elements â any link text, short description, or navigation title specified inside <topicmeta> are specific to the context. So, Iâm curious to hear from others who have used the current <linktext>, either making use of the current behavior or being surprised by it.
Thanks,
Robert
From: <dita@lists.oasis-open.org> on behalf of Gershon Joseph <gershon@precisioncontent.com>
Date: Monday, December 14, 2020 at 6:50 AM
To: Chris Nitchie <cnitchie@gmail.com>, "dita@lists.oasis-open.org" <dita@lists.oasis-open.org>
Subject: Re: [dita] Applicability of <linktitle>
Iâm fine with the new behavior. As you say Chris, itâs now consistent. We just need to state this change in behavior clearly in the spec as well as in our migration doc.
Letâs see if anyone has serious concerns with this approachâ
Gershon Joseph | Senior Information Architect | Precision Content
Direct: +972 (54) 658-3887| Email: gershon@precisioncontent.com | www.precisioncontent.com
Unlock the Knowledge in Your Enterpriseâ
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. Please notify us by return email if you have received this email in error. Â2020, Precision Content Authoring Solutions Inc, Toronto, Ontario, Canada
From: dita@lists.oasis-open.org <dita@lists.oasis-open.org>
Date: Sunday, 13 December 2020 at 21:39
To: dita@lists.oasis-open.org <dita@lists.oasis-open.org>
Subject: [dita] Applicability of <linktitle>
In Robert's review of the alternative titles proposal, he pointed out something that I was entirely unaware of that throws a small wrench into the proposal that I'm going to need the committee's help resolving.
The proposal for alternate title improvements replaces <linktext> in maps with <linktitle>, which can be specified either in maps or topics, with the value from the topicref taking precedence over that in the topic when both are specified. Any <link> that does not specify an explicit <linktext> derives its text from the effective <linktitle> for the referenced topic, if any. If none is specified, the <title> of the topic should be used.
I thought this behavior was essentially backwards-compatible with DITA 1.3, with the only differences being that the element is now <linktitle> instead of <linktext>, and it can exist at the topic level as well as in the topicref. To my shock and dismay, it is not; this represents a fairly substantial breaking change.
In DITA 1.3, the <linktext> element, when used in a map, only applies to related-links generated by the processor from a map's structure (parent/child/sibling) or relationship tables. All other links derive their text from the topic's <title> and ignore any <linktext> in topicrefs pointing to that topic. With the proposal as-is, output of existing maps will change, with <link> elements that used to display the topic's title now displaying its <linktitle> instead.
And I'm stumped. I think the behavior described by the proposal is better. I find it difficult to believe that authors expect different text to be used in related links depending on whether the link was generated by the processor or not. But it does beak backwards-compatibility with DITA 1.3 in a way I hadn't anticipated, an for which I can think of no reasonable remedy. (I can think of some unreasonable ones, like separate elements/@title-roles for generated vs. authored links, but I really don't want to go down that route.)
I'd like to discuss this at Tuesday's meeting.
Chris