FW: Revisions to Acronym proposal

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

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

-----Original Message-----
From: Robert D Anderson [mailto:robander@us.ibm.com] 
Sent: Tuesday, January 22, 2008 7:59 AM
To: 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
Subject: Re: Revisions to Acronym proposal

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.h
tml
> >). 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)
>