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


Greetings,

 

As a quick update to this… Robert and I hashed this out. I am on board with removing <term> from the 1.3 processing spec. It definitely makes it clearer J

 

Thanks.

 

-Dave H.

 

Dave Helfinstine

dhelfinstine@ptc.com

 

From: dita@lists.oasis-open.org [mailto:dita@lists.oasis-open.org] On Behalf Of Helfinstine, David
Sent: Tuesday, January 27, 2015 11:14 AM
To: Robert D Anderson
Cc: dita@lists.oasis-open.org
Subject: RE: [dita] Error in 1.2 / 1.3 key processing topic for link text

 

Greetings,

 

I can blame this on vacation last week, and I didn’t fully digest this until we were discussing this today. I wasn’t fast enough to find what I was looking for, but have found this now.

  1. 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.

 

An interpretation of this is that the first <term> could be in the form of:  <indexterm><term>hello</term></indexterm>. That is the first <term> element that would be found. The Spec does not say that the <term> would have to be a direct child from my reading of this. This is the interpretation of this sentence that at least one implementation made to make sense of that rule. J

 

I am in favor of leaving this wording as is, realizing that the voting already happened.

 

-Dave H.

 

Dave Helfinstine

dhelfinstine@ptc.com

 

From: dita@lists.oasis-open.org [mailto:dita@lists.oasis-open.org] On Behalf Of Robert D Anderson
Sent: Tuesday, January 20, 2015 2:26 PM
To: DITA TC
Subject: Re: [dita] Error in 1.2 / 1.3 key processing topic for link text

 

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

Inactive hide details for Robert D Anderson---01/20/2015 14:17:55---In DITA 1.2 and in the latest draft of DITA 1.3, we have teRobert 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/)



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