dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Error in 1.2 / 1.3 key processing topic for link text
- From: "Robert D Anderson" <robander@us.ibm.com>
- To: DITA TC <dita@lists.oasis-open.org>
- Date: Tue, 20 Jan 2015 14:17:23 -0600
In DITA 1.2 and in the latest draft of DITA 1.3, we have text that explains how to pull text into an empty, non-linking element that uses @keyref. For example,
<keyword keyref="prodname"/> or <term keyref="widget"/>
The text has been cleaned up but the meaning is the same:
- DITA 1.2: "For elements on which no @href attribute is available (such as cite, dt, keyword, term, ph, indexterm, index-base, and indextermref, and their specializations), matching content is taken from the <keyword> or <term> elements within <keywords> within <topicmeta>. If more than one <keyword> or <term> is present, the matching content is taken from the first of them. "
- DITA 1.3: "If an element does not allow the @href attribute, content is taken from the first <keyword> or <term> element inside of <keywords> inside of the <topicmeta>. "
Jarno just pointed out that <keywords> does not actually allow <term> -- so with the language above, replacement text can only come from <keyword>. Thus while the normative text is not exactly invalid, it's misleading / causing implementations to check for something that can't exist. We also examples that are invalid, because they show <term> as a child of <keywords>.
The <keywords> element does allow <indexterm> -- but I'm as close to certain as I can be that the intent here was actually to match keyword or term. I don't think we ever want to pull text from <indexterm> in a key definition into <keyword> or <term> in a topic.
I see the following options for cleaning up the language:
- Remove <term> from the language and examples. It can't break anything (term was never valid), just cleans up language.
- Change the text to read "<keyword> or <indexterm>". I don't think this matches the original intent and may give different key resolution results in DITA 1.2 processors vs DITA 1.3 processors.
- Add <term> as a child of <keywords> - suddenly the text is correct. I consider this a no-go, it's too late to modify content models, just including for completeness.
Clearly, I favor option #1 as the easiest / only non-disruptive change, but I need TC signoff before making the update.
Thanks,
Robert D Anderson
IBM Authoring Tools Development
Chief Architect, DITA Open Toolkit (http://www.dita-ot.org/)
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]