FW: Revisions to Acronym proposal

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

Another comment from Bruce 


JoAnn T. Hackos, PhD
President
Comtech Services, Inc.
710 Kipling Street, Suite 400
Denver CO 80215
303-232-7586
joann.hackos@comtech-serv.com
 

-----Original Message-----
From: Bruce Esrig [mailto:esrig@alumni.princeton.edu] 
Sent: Wednesday, January 23, 2008 5:45 AM
To: Robert D Anderson; Bruce Esrig
Cc: bhertz@sdl.com; Bryan Schnabel; christian.lieske@sap.com;
dpooley@sdl.com; Erik Hennum; fsasaki@w3.org; ishida@w3.org; JoAnn
Hackos; jogden@ptc.com; KARA@CA.IBM.COM; Michael Priestley;
rfletcher@sdl.com; rmraya@maxprograms.com;
tony.jewtushenko@productinnovator.com; ysavourel@translate.com; JoAnn
Hackos; Rodolfo M. Raya; Andrzej Zydron
Subject: Re: Revisions to Acronym proposal

Robert, Kara,

Thank you for these answers.

The mechanism that generates multiple glossary entries with "see" 
references to the preferred term seems very well-designed. It should be
adequate for all needs within the glossary. Kara's ATM example clarifies
how multiple expanded forms for a single acronym would be handled.

Perhaps this statement is an incorrect explanation of a correct
decision:
2. The glossFullForm (also called glossExpandedForm) element can be
removed, because the expanded form of the term is already encoded as the
term.

Instead:
2. The glossFullForm (also called glossExpandedForm) element can be
removed because the expanded form of the term only needs to stand alone
in the glossary. The surface form can be used on first occurrence in the
text, and the preferred form can be used on subsequent occurrences.

Best wishes,

Bruce

At 09:59 AM 1/22/2008, Robert D Anderson wrote:
>Hi Bruce,
>
>Kara addressed the second two, so I'll try to address the first two.
>
>The first occurrence of an acronym will pull in the content of the 
>glossSurfaceForm element. This allows translators control over how the 
>content should appear. The element may contain "expanded (acronym)" or 
>it may contain "acronym (expanded)", depending on the rules for a 
>particular language, or on the most common usage for a particular
acronym.
>
>On the call we discussed whether or not a <glossAcronym> element should

>be left empty when the acronym does not exist in a target language. The

>consensus was that this would be difficult in the translation tools, 
>because they typically warn when content is left blank instead of 
>translated. So the best practice suggestion was to place the expanded 
>form in that location. Because tools will not automatically be 
>constructing the "expanded (acronym)" form, having the full value in 
>both places should not cause problems with the generated output.
>
>Thanks -
>
>Robert D Anderson
>IBM Authoring Tools Development
>Chief Architect, DITA Open Toolkit
>(507) 253-8787, T/L 553-8787 (Good Monday & Thursday)
>
>Bruce Esrig <esrig-ia@esrig.com> wrote on 01/22/2008 03:01:07 AM:
>
> > Thanks again for the copy ... I have four remarks.
> >
> > 3a. Is there an enumeration value in order to instruct that the 
> > first occurrence be of the form "expansion (acronym)"? If not, 
> > authors who want
>
> > this format will have to know which occurrence is the first. If they

> > must
>
> > explicitly write "<abbreviated-form> (<abbreviated-form>)", then 
> > they
>must
> > do so at the first occurrence.
> >
> > 3b. Translators should not fill in the expanded form where the 
> > acronym is
>
> > requested if my suggestion in 3a is implemented. Otherwise, 
> > "expansion (expansion)" will result at the first occurrence in the
translation.
>There
> > seems to be a process issue, which is that translators need a way to

> > indicate that they have completed translating a glossary entry, 
> > including
>
> > the acronym. An alternate way of supporting that need would be to 
> > provide
>
> > an explicit attribute that the translator sets to indicate that the
>acronym
> > has been left empty deliberately. Then an empty attribute is 
> > consistently
>a
> > sign that the expanded form should be used.
> >
> > 1. Are there controls to permit alternate titles (aside from the 
> > expanded
>
> > form) for the glossary topics in the generated glossary? These would

> > indicate that in the generated glossary, the topic should appear 
> > under
>the
> > expanded form, under the abbreviated form, or both. If the 
> > abbreviated
>form
> > is not unique, the control could be on that element so that multiple

> > instances could be generated. This mechanism assumes that there is a

> > capability to sort the generated glossary topics by title.
> >
> > 6. Is there a see/see-also/compare mechanism for glossary entries as

> > was discussed for index entries?
> >
> > Best wishes,
> >
> > Bruce
> >
> > At 07:14 PM 1/21/2008, Robert D Anderson wrote:
> >
> > >Hi,
> > >
> > >As we agreed at today's call, I had a follow-up meeting with Erik 
> > >Hennum
>to
> > >discuss the translation group's suggestions. As a result, there are

> > >now several concrete suggestions as changes to the original 
> > >proposal (
> >
> >http://lists.oasis-open.org/archives/dita-translation/200801/msg00003
> >.html
> > >). I'll list the specifics below, and then send a more general note

> > >to
>the
> > >main TC list.
> > >
> > >1. The group suggested that expanded forms should come first. So, 
> > >the proposal can remove glossAcronym and glossAbbreviation as 
> > >options for
>the
> > >main 'title' of the glossary topic. Instead, the expanded term will

> > >be located first, using the glossterm markup that is used for every
>glossary
> > >entry. The glossAcronym or glossAbbreviation are listed after that 
> > >as alternate versions of the expanded term.
> > >
> > >2. The glossFullForm (also called glossExpandedForm) element can be

> > >removed, because the expanded form of the term is already encoded 
> > >as the term.
> > >
> > >3. When authors reference an acronym inline with the 
> > ><abbreviated-form> element, the rules will follow those defined by 
> > >the translation
> > >subcommittee:
> > >- The first instance in one context will pull text from the 
> > >glossSurfaceForm
> > >- Future instances will pull from the first glossAcronym (similar 
> > >to today's discussion, in that we cannot prevent many but users 
> > >should only have one)
> > >- The consensus on today's call was that if an acronym is not 
> > >available
>in
> > >a target language, the expanded value should be specified. However,

> > >if
>the
> > >acronym is empty because a translator removed it, the primary term 
> > >(the expanded form) should be used.
> > >
> > >4. The existing <glossStatus> element has a new value of 
> > >"preferred" in
>the
> > >enumeration. This can be used to indicate that an alternate form 
> > >(such
>as
> > >an acronym) is the preferred representation of a term. This is 
> > >still not
>a
> > >required element for acronym processing. If a <term> element is 
> > >used to reference a glossary entry, the following rules will be 
> > >used when retrieving the term:
> > >- As a first choice, the form of the term marked "preferred" will 
> > >be retrieved
> > >- If no term is marked preferred, or if the preferred term is empty

> > >(possibly because it does not exist in a target language), the 
> > >primary
>term
> > >will be retrieved
> > >- NOTE: using <abbreviated-form> will always use the processing 
> > >rules defined in #3, regardless of what is marked "preferred"
> > >
> > >5. As mentioned at the call, the language in the proposal about 
> > >acronyms needs to be cleaned up to include all of the translation 
> > >issues
>described
> > >in the original proposal.
> > >
> > >Please send any comments back to the list. Unfortunately Erik 
> > >hasn't had time to review this, so if I mis-characterized something

> > >he may be
>speaking
> > >up soon.
> > >
> > >Robert D Anderson
> > >IBM Authoring Tools Development
> > >Chief Architect, DITA Open Toolkit
> > >(507) 253-8787, T/L 553-8787 (Good Monday & Thursday)
> >