OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita-translation message

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

Subject: Re: [dita-translation] FW: re Acronym proposal for DITA

In looking at the wiki page, I am still not clear that we have a good idea
of the whole purpose behind this acronym element. Personally, I think this
is responsible for a lot of the disconnect. We are trying to agree on a
solution, and even some very specific details of that solution, when we do
not have the same idea of what we are trying to solve. That was the
conclusion I got from last week's meeting - if we do not know about,
understand, or recognize the other person's premise then their suggestions
will never make sense.

The 3 cases currently listed under "Requirements for the use of acronyms"
only represent a description of what acronyms are. I think the presentation
section comes the closest to representing the requirement, but it is still
only one aspect of the requirement. Given that this requirement originally
came from the main TC - and was given to the subcommittee because there was
a recognition of translation impacts - I think we need to get this input
from the main TC as well.

The input should really be of the form "Why do you need an acronym
element". Possible examples, not exhaustive, some may not be real:
* We need to be able to automatically display the long form of an acronym
once, and the short form every other time.
* We need to be able to associate an acronym with a definition.
* We need to be able to define an acronym inline.
* We need to be able to pull a list of acronyms used in an information set.
* We need to be able to highlight an acronym so that users can click on it
for a definition or for more information.

If we can agree on what we're trying to cover, then the rest should be
easier. If we miss out on use cases that the original submitters needed,
then anything we come up with will be discarded by the main TC, so we need
to ask them as well.

Does this make sense? Anybody mind if I create a wiki page dedicated to the
actual user requirements?

Robert D Anderson
IBM Authoring Tools Development
Chief Architect, DITA Open Toolkit
(507) 253-8787, T/L 553-8787 (Good Monday & Thursday)

             08/07/2007 07:01          "JoAnn Hackos"                      
             PM                        <joann.hackos@comtech-serv.com>     
                                       Re: [dita-translation] FW: re       
                                       Acronym proposal for DITA           

Hi all,

I agree with Kara that <term> is a better base for abbreviations/acronyms
than <keyword>.  Its content model is (at the moment) too strict for our
uses but any proposal from the Translation Subcommittee will address that.

I also agree about the need to distinguish abbreviations from acronyms from
short forms (and so on).  Text-to-speech converters are going to care about
the difference, for instance.  Rather than using an attribute to
distinguish the types, a more DITA-ish way would be to specialize <term>
into domain elements <abbreviation>, <acronym>, <variant> and so on.  The
usual DITA advantages of this would ensue: companies can permit the use of
the domain or not*, depending on corporate style guides; each can have a
different content model (so that abbreviations must spell out a full form
whereas variants don't have to, or so that strict acronyms don't need a
surface form); specialized <term> can forbid mixed content whereas base
<term> can allow it; users can further specialize abbreviations to classes
of abbreviation that are relevant to their field (e.g., <gene-name> in
genetic engineering).  If it's important to have a "type" attribute for
interoperability with some other standard, that can still be done, with
specializations setting default values for the attribute.

I'm cooler about the idea of an inline definition; it seems to repeat work
already done with the DITA glossary entry document type, which is already
in DITA 1.1.  But I could be convinced.  It seems to be out-of-band
information akin to a footnote in terms of content model, particularly if
it allows block content.  Maybe the inline definition could pull the text
from the relevant glossentry by conref . . .

Again, sorry I can't bring this up at the meeting in person.

* Or parts thereof, if #12008 is approved.

Deborah Pickett
Information Architect, Moldflow Corporation, Melbourne

 "JoAnn Hackos"                                                            
 07/08/2007 01:29 AM                             <dita-translation@lists.o 
                                                 [dita-translation] FW: re 
                                                 Acronym proposal for DITA 

Hello Translation Subcommittee members:
Please review Kara's suggestions attached before the next meeting.

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

-----Original Message-----
From: Kara Warburton [mailto:KARA@CA.IBM.COM]
Sent: Monday, July 16, 2007 12:32 PM
To: JoAnn Hackos
Cc: bhertz@sdl.com; Bryan Schnabel; charles_pau@us.ibm.com;
christian.lieske@sap.com; dita-translation@lists.oasis-open.org;
dpooley@sdl.com; esrig-ia@esrig.com; fsasaki@w3.org; Howard.Schwartz;
ishida@w3.org; mambrose@sdl.com; rfletcher@sdl.com;
tony.jewtushenko@productinnovator.com; ysavourel@translate.com
Subject: re Acronym proposal for DITA

Here are my suggested changes. After the call, I was going to suggest
changes to the element names (to account, for example, for other types
abbreviations in addition to acronyms), but then after looking more
into DITA I began to wonder whether it is wise to specialize from
(sorry I didn't raise this before... it just occurred to me now as I dig
more deeply into the proposal).

NOTE ALSO that we also need to consider how the proposal will work in
conjunction with a glossary specialization which was requested YEARS
These proposals are now so old that we may need to update them and can
modify them if needed to fit the acronym (now "term") proposal. If we
going to identify acronyms and other terms, we should be able to re-use
this information to generate a glossary. In fact, I would like to see
"terms.dita" file (see below) be  the glossary or become the source for

An abbreviation is a type of term, so why don't we use <term> which
exists in DITA, and add a type attribute. Like <keyword>, <term> is also
inline element. It also has the same limitations as <keyword>  in terms
what it can contain (text and tm). So implementation using <term> would
seem to have any more impacts re changes to DITA as using a
of <keyword>

So instead of having:

<acronym conref="acronyms.dita#acronyms/abs"/>

we would have

<term conref="terms.dita#terms/abs"/>

If I understand correctly, the conref would resolve using the
<surface_form> element, i.e.

The optional <term conref="terms.dita#terms/abs"/> costs $1000.

Would appear in the final text as:

The optional Anti-Lock Braking System (ABS)costs $1000.

Using <term> with type attributes is more in line with standard
markup and would allow us to specify a range of possible type values.
current set of values being proposed for TBX (an XML markup format for
terminology being submitted to ISO) are the following:

  full form
  short form

Also, in line with ITS
(http://www.w3.org/TR/2007/WD-xml-i18n-bp-20070628/#DevTerm) and  the
Encoding Initiative
we should allow an element for a definition.

We would then have the following types of markup in the terms.dita file

<term id="abs" type="acronym">
  <surface_form>Anti-lock Braking System (ABS)</surface_form>
  <long>Anti-lock Braking System</long>
  <definition>A braking system for automobiles that prevents locking

<term id="yyy" type="abbreviation">
  <surface_form>abnormal end of task (abend)</surface_form>
  <long>abnormal end of task</long>
  <definition>The termination of a task, job, or subsystem because of
error condition that recovery facilities cannot resolve during

Note in the following example the surface form actually doesn't use any
the short forms in it, but rather, a different formulation. This is the
flexibility permitted by having a separate element for surface forms.
note, 2 short forms are provided. It should  be possible to have
short forms.

<term id="yyy" type="short form">
  <surface_form>Intergovernmental Group of Twenty-Four on International
Monetary Affairs and Development  (Group of 24)</surface_form>
  <long>Intergovernmental Group of Twenty-Four on International
Affairs and Development</long>
  <short>Group of Twenty-Four</short>
  <definition>A group of 24 countries whose main objective is to
the position of developing countries on monetary and development finance
issues. . </definition>

Note also that ITS and TEI have definitions as inline elements, such as:

<p>The <term id="UN">United Nations</term> is <definition id="UN">a
of nations whose objective is to promote world peace and

Maybe we could also permit this and then the inline <definition> element
could be automatically added to the terms.dita file.

Kara Warburton
IBM LanguageWare & Terminology
Team Lead, Language & Data Integration

IBM terminology: http://w3.ibm.com/standards/terminology
LanguageWare: http://languageware.redirect.webahead.ibm.com/
My blog: http://blogs.tap.ibm.com/weblogs/page/kara@ca.ibm.com

            "JoAnn Hackos"



            15/07/2007 06:43          org>, <mambrose@sdl.com>,

            PM                        <bhertz@sdl.com>, "Bryan











                                      com>, Kara




                                      OASIS DITA Translation
                                      Agenda -- 16 July 2007

Hello All,

Toll Numbers: USA +1-770-615-1250
Toll-Free Numbers: USA 877-421-0033
Participant Passcode: 610708

ITN: 2-421-0033

In addition, if you are calling from one of these countries, even the
toll-based charges should be lower than standard long distance--use
whatever works from your location:

Country Toll-free (IBM Pays) Toll (Caller Pays)
Austria +43 179576264
Belgium 0800-7-3026 +32 22006114
Denmark 80-888377 +45 38323070
Finland 0800-914-630 +358 972519061
France 0800-902366 +33 157323040 or  +33 157323041
Germany 0800-181-6323 +49 6951709081
Ireland 1800-558728 +353 16569209
Italy 800-788634 +39 0269430413
Netherlands 0800-022-8558 +31 202008077
Norway 800-18373 +47 24159528
Spain 900-95-1089 +34 912754171
Sweden 020-799414 +46 850163259
Switzerland 0800-564-331 +41 44654562
United Kingdom 0808-234-1969 +44 2070260533
USA 877-421-0033 770-615-1250
1)  Roll Call

2) Accept Minutes from 16 July 2007 (need from Gershon

 New Translation SC wiki page (Thank you, Bob Doyle)

3)  Review open action items

   3.1 ACTION: Gershon to investigate whether he can use a client's
       Gershon will assemble all the examples into the template for the
TC; need to add the examples to the Multilanguage Best Practice.

       CONTINUED. Awaiting legal OK; Gershon is selecting items for use
the Best Practice.

   3.2 ACTION: Gershon and Don will present the approved best practices
       indexing, conrefs, Translation Memory, and multilanguage as
committee drafts for approval by
       the    DITA Technical Committee.

       CONTINUED. Gershon to complete marking up in DITA XML and
       customization and deliver to TC for review; now working with
McRae to get these
           Documents in shape for a vote.

       Don asked Gershon to make new Wiki page with links to the latest
       of the Translation SC BPs for review.


   3.5 ACTION: Rodolfo will continue to work on the Best Practice for

   3.6 ACTION: JoAnn will try writing the sort order addition to the
       Best Practice for review.

   3.7 ACTION: JoAnn will contact Richard Ischida to get clarification
the need for a pronunciation
           or attribute for the acronym proposal.

       IN PROGRESS -- note sent to Richard. JoAnn raised the issue at
OASIS Symposium
       with  the Accessibility working group headed by Peter Brunet
IBM. They are working on
       Accessibility for ODF. Suggested that DITA be included in the
accessibility discussions. No response as yet.

4)  Returning business:

   4.1 Vote on the final version of Andrzej and Rodolfo's  acronym
proposal. See the new wiki

   4.2 Discussion of the 4.2 Discuss Rodolfo's  proposed additions to
Indexing best practice.

5)  New business:

   5.1 New Translation WIKI page (Question: how to attach documents)


   5.1 Comment on the W3C working draft.

A W3C working draft document entitled "Best Practices for XML
Internationalization" was published last week.

It includes a section on DITA at

Comment from Deborah Pickett (Moldflow)

Curious.  It gives some advice on how to handle Ruby, which DITA
needs a domain for sooner or later.

There are a few errors/omissions with respect to their coverage of DITA:

- The XPath selectors are all of the form "//term" rather than
"//*[contains(@class, ' topic/term ')]".  Selectors appear to be able to
use all XPath 1.0 patterns, so they should Do The DITA Thing with
names and classes.

- There's no mention of incorporating the domain into DITA maps, which
have translatable text.

- It doesn't look like much attention has been given to is-a
and overrides (i.e., <step> is-a <li>).  But, looking at the spec for
the override logic for <its:rules> isn't sophisticated enough to cope
mixing-in of DITA domain specializations anyway.  Darn.

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

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

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