[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita] Applicability of <linktitle>
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> 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 Unlock the Knowledge in Your Enterpriseâ
From: dita@lists.oasis-open.org <dita@lists.oasis-open.org> 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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]