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: FW: FW: [dita] indexing question

Hi, JoAnn and Bruce:

Regardless of whether an index entry is a point (as Chris suggests) or a span (an alternative view), an index entry clearly should never have an impact on flow. An index entry is an annotation on the content much like a metadata property.

So, I would disagree with the recommendation to treat the index entry as an inline if there is any implication of affecting the layout or the parsing of text. An index entry could appear in the middle of a word -- it shouldn't make any difference in the processing.

Regarding interpretation of an index entry based on its container, that applies to an index entry in the prolog. It should be interpretted based on the topic (which is the effective container of everything in the prolog). In particular, for an index entry in the prolog, the index is either a point attached to the start of the topic or a span covering the entire topic.

Even if the processing of index entries _were_ different in different contexts, I don't see that this would necessarily requires a different element name so long as the processing conforms to expectations.

On the range questions, we should keep in mind concerns about topic reuse. If we embed index start and end entries in different topics, we run the risk of breaking the range when the start and end topics are reused independently. That's part of the rationale for putting ranges in the map.


Erik Hennum

Inactive hide details for "JoAnn Hackos" <joann.hackos@comtech-serv.com>"JoAnn Hackos" <joann.hackos@comtech-serv.com>

          "JoAnn Hackos" <joann.hackos@comtech-serv.com>

          07/18/2006 07:24 AM




"Grosso, Paul" <pgrosso@ptc.com>, "Chris Wong" <cwong@idiominc.com>


FW: FW: [dita] indexing question

Here is the suggestion I received from Bruce in response to Rodolfo’s clarification. I’m not certain that everyone has seen it.

JoAnn T. Hackos, PhD
Comtech Services, Inc.
710 Kipling Street, Suite 400
Denver, CO 80215
joannhackos Skype


From: Esrig, Bruce (Bruce) [mailto:esrig@lucent.com]
Monday, July 17, 2006 1:23 AM
JoAnn Hackos
RE: FW: [dita] indexing question

Hi JoAnn,

Every two weeks I have a meeting at 10 Eastern that runs for an hour or two. This is one of those weeks, and it could be a long meeting. So I suspect I won't be able to attend the translation SC meeting this week.

1. Thanks to Rodolfo for explaining "breaking" and the related terms. Is he willing to have his message posted in part or whole to the main DITA list? May I distribute it within Lucent?

2. I agree that treating <indexterm> as a subflow in the prolog and as an inline elsewhere is best among the alternatives presented. Would the translation SC be opposed to specifying that <indexterm> is filtered on the way to/from TM in order to distinguish an <indexterm> that is to be treated as a subflow from an <indexterm> that is to be treated as an inline? This could be done by creating two up to two artificial elements <indextermsubflow> and <indexterminline> that are used only in the TM processing.

If it were possible to distinguish between subflow and inline uses of indexterm, then DITA could also offer the following enhancement: add an attribute to suppress printing in inline contexts, such as <indexterm print="no">. This takes advantage of the ability to distinguish between a subflow and an inline. If print="no" is specified, then in an inline context, the <indexterm> would be treated as a subflow.

3. The translation SC might wish (especially if the filtering proposal is not feasible) to recommend a special element <indextermprolog>. The default treatment of <indexterm> would be as an inline, but <indextermprolog> would be treated as a subflow. Since DITA 1.1 is expected to be backward compatible, <indextermprolog> could be an optional alternative to <indexterm> in prolog contexts in DITA 1.1. Subsequently, <indextermprolog> could become the standard element for use in prolog contexts. This approach would still leave room for the print="no" enhancement.

4. I'm delighted that Rodolfo separates out the issue of multiple-topic ranges. If needed, the translation SC could still discuss for approval or disapproval the point of view that ... those groups that want to support index ranges that span multiple processes will have to take responsibility for ensuring that their translation processes support it. For example, such groups could extract their index range data in advance, translate it in advance, and submit the translated data with the main body of material to be translated.

Best wishes,

Bruce Esrig
<p>Segment one.</p>
<p>Segment two. Second sentence.</p>
<p>Segment with <b font="Times">bold</b> text.</p>
<p>Segment with <footnote>some comment</footnote> footnote.</p>
Breaking Elements that contain text fragments that should be analysed as a unit. A new segment should be created whenever this kind of element is found at text extraction time. In CAT tools maker jargon, it "breaks" the segment being processed and starts a new one. <p>
Inline Elements that delimit text fragments that should be analysed as part of the text from the parent element. These elements usually delimit changes in style. <b>
Subflow Elements that contain text fragments that should be analysed separately. Processing of the enclosing segment does not end. The element is replaced by a marker in the text and its processing is delayed. <footnote>
Ignorable Elements that are not supposed to contain translatable text and can be discarded, except when they appear as children of breaking elements in which case they should be regarded as "inline". <table>, <row>, <col>
<indexterm>term one</indexterm>
<indexterm>term two</indexterm>
<p>Paragraph that contains <indexterm>term one</indexterm>
and <indexterm>term two</indexterm> inside.</p>
The information in this e-mail is intended strictly for the addressee, without prejudices, as a confidential document. Should it reach you, not being the addressee, it is not to be made accessible to any other unauthorised person or copied, distributed or disclosed to any other third party as this would constitute an unlawful act under certain circumstances, unless prior approval is given for its transmission. The content of this e-mail is solely that of the sender and not necessarily that of Heartsome.

GIF image

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