Re: [dita] Error in 1.2 / 1.3 key processing topic for link text

[Eliot Kimber <ekimber@contrext.com>]

I see that @keyref is allowed on <indexterm> (never occurred to me that it
actually is allowed).

Since we allow <ph> within <indexterm> in DITA 1.3, the use case of
getting the index term text via keyref is provided for. So it's hard to
see using @keyref for complete index terms would have much value. It would
certainly be an open question as to what the processing effect would be in
the case where the keydef for a key used by <indexterm> pointed to a
topic: what could that possibly mean (since an index entry is already
implicitly a link to the point in the document where the index term
occurs).

Cheers,

E.

—————
Eliot Kimber, Owner
Contrext, LLC
http://contrext.com




On 1/20/15, 2:26 PM, "Robert D Anderson" <robander@us.ibm.com> wrote:

>Amended list of possible resolutions, though I'm not sure about how I
>feel about the new option (#4):
>
>
>1.
>Remove <term> from the language and examples. It can't break anything
>(term was never valid), just cleans up language.
>
>
>2.
>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.
>
>
>3.
>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.
>
>
>4.
>
>Add a new rule just for indexterm, allowing indexterm to pull from a
>matching indexterm. This is not allowed today in 1.2 or 1.3 but is
>probably what somebody using @keyref on <indexterm> expects. Remove any
>mention of <term>, and every other non-linking element is left pulling
>from <keyword>.
>
>
>Thanks,
>
>Robert D Anderson
>IBM Authoring Tools Development
>Chief Architect, DITA Open Toolkit (http://www.dita-ot.org/)
>
>Robert D Anderson---01/20/2015 14:17:55---In DITA 1.2 and in the latest
>draft of DITA 1.3, we have text that explains how to pull text into an
>
>From:	Robert D Anderson/Rochester/IBM@IBMUS
>To:	DITA TC <dita@lists.oasis-open.org>
>Date:	01/20/2015 14:17
>Subject:	[dita] Error in 1.2 / 1.3 key processing topic for link text
>Sent by:	<dita@lists.oasis-open.org>
>________________________________________
>
>
>
>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:
>1.
>Remove <term> from the language and examples. It can't break anything
>(term was never valid), just cleans up language.
>
>
>2.
>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.
>
>
>3.
>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/)