[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]