[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)
Deborah_Pickett@m
oldflow.com
To
08/07/2007 07:01 "JoAnn Hackos"
PM <joann.hackos@comtech-serv.com>
cc
dita-translation@lists.oasis-open.o
rg
Subject
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
Deborah_Pickett@moldflow.com
"JoAnn Hackos"
<joann.hackos@comtech-serv.com>
To
07/08/2007 01:29 AM <dita-translation@lists.o
asis-open.org>
cc
Subject
[dita-translation] FW: re
Acronym proposal for DITA
Hello Translation Subcommittee members:
Please review Kara's suggestions attached before the next meeting.
JoAnn
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: 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
some
changes to the element names (to account, for example, for other types
of
abbreviations in addition to acronyms), but then after looking more
deeply
into DITA I began to wonder whether it is wise to specialize from
<keyword>
(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
ago.
http://www.oasis-open.org/committees/download.php/17513/Issue14a.html
http://www.oasis-open.org/committees/download.php/15140/Issue14.html
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
are
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
the
"terms.dita" file (see below) be the glossary or become the source for
the
glossary.
An abbreviation is a type of term, so why don't we use <term> which
already
exists in DITA, and add a type attribute. Like <keyword>, <term> is also
an
inline element. It also has the same limitations as <keyword> in terms
of
what it can contain (text and tm). So implementation using <term> would
not
seem to have any more impacts re changes to DITA as using a
specialization
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
terminology
markup and would allow us to specify a range of possible type values.
The
current set of values being proposed for TBX (an XML markup format for
terminology being submitted to ISO) are the following:
full form
acronym
abbreviation
short form
variant
phrase
Also, in line with ITS
(http://www.w3.org/TR/2007/WD-xml-i18n-bp-20070628/#DevTerm) and the
Text
Encoding Initiative
(http://www.tei-c.org/release/doc/tei-p5-doc/html/ref-gloss.html)
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>
<short>ABS</short>
<definition>A braking system for automobiles that prevents locking
blah
blah.</definition>
</term>
<term id="yyy" type="abbreviation">
<surface_form>abnormal end of task (abend)</surface_form>
<long>abnormal end of task</long>
<short>abend</short>
<definition>The termination of a task, job, or subsystem because of
an
error condition that recovery facilities cannot resolve during
execution.
</definition>
</term>
Note in the following example the surface form actually doesn't use any
of
the short forms in it, but rather, a different formulation. This is the
flexibility permitted by having a separate element for surface forms.
Also
note, 2 short forms are provided. It should be possible to have
multiple
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
Monetary
Affairs and Development</long>
<short>Group of Twenty-Four</short>
<short>G-24</short>
<definition>A group of 24 countries whose main objective is to
concert
the position of developing countries on monetary and development finance
issues. . </definition>
</term>
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
group
of nations whose objective is to promote world peace and
harmony</definition>.</p>
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
905-413-2170
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"
<joann.hackos@com
tech-serv.com>
To
<dita-translation@lists.oasis-open.
15/07/2007 06:43 org>, <mambrose@sdl.com>,
PM <bhertz@sdl.com>, "Bryan
Schnabel"
<bryan.s.schnabel@tek.com>,
<charles_pau@us.ibm.com>,
<christian.lieske@sap.com>,
<dpooley@sdl.com>,
<dschell@us.ibm.com>,
<esrig-ia@esrig.com>,
<fsasaki@w3.org>,
<rfletcher@sdl.com>,
"Howard.Schwartz"
<Howard.Schwartz@trados.com>,
<ishida@w3.org>,
<tony.jewtushenko@productinnovator.
com>, Kara
Warburton/Toronto/IBM@IBMCA,
<ysavourel@translate.com>
cc
Subject
OASIS DITA Translation
Subcommittee
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)
http://wiki.oasis-open.org/dita/TranslationSubcommittee
3) Review open action items
3.1 ACTION: Gershon to investigate whether he can use a client's
samples.
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
in
the Best Practice.
3.2 ACTION: Gershon and Don will present the approved best practices
on
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
complete
OASIS
customization and deliver to TC for review; now working with
Mary
McRae to get these
Documents in shape for a vote.
Don asked Gershon to make new Wiki page with links to the latest
drafts
of the Translation SC BPs for review.
COMPLETED
3.5 ACTION: Rodolfo will continue to work on the Best Practice for
XLIFF
CONTINUED.
3.6 ACTION: JoAnn will try writing the sort order addition to the
indexing
Best Practice for review.
CONTINUED.
3.7 ACTION: JoAnn will contact Richard Ischida to get clarification
on
the need for a pronunciation
element
or attribute for the acronym proposal.
IN PROGRESS -- note sent to Richard. JoAnn raised the issue at
the
OASIS Symposium
with the Accessibility working group headed by Peter Brunet
from
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
the
Indexing best practice.
5) New business:
5.1 New Translation WIKI page (Question: how to attach documents)
http://wiki.oasis-open.org/dita/TranslationSubcommittee
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
http://www.w3.org/TR/2007/WD-xml-i18n-bp-20070628/#dita
Comment from Deborah Pickett (Moldflow)
Curious. It gives some advice on how to handle Ruby, which DITA
probably
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
element
names and classes.
- There's no mention of incorporating the domain into DITA maps, which
can
have translatable text.
- It doesn't look like much attention has been given to is-a
relationships
and overrides (i.e., <step> is-a <li>). But, looking at the spec for
ITS,
the override logic for <its:rules> isn't sophisticated enough to cope
with
mixing-in of DITA domain specializations anyway. Darn.
JoAnn T. Hackos, PhD
President
Comtech Services, Inc.
710 Kipling Street, Suite 400
Denver CO 80215
303-232-7586
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
www.comtech-serv.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]