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] Error in 1.2 / 1.3 key processing topic for link text


I agree with option (1).

Cheers,

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




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

>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/)




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