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
To
<>
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
joannhackos Skype
www.comtech-serv.com
-----Original Message-----
From: Kara Warburton [mailto:]
Sent: Monday, July 16, 2007 12:32 PM
To: JoAnn Hackos
Cc: ; Bryan Schnabel; ;
; ;
; ; ; Howard.Schwartz;
; ; ;
;
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/[email protected]
"JoAnn Hackos"
<joann.hackos@com
tech-serv.com>
To
<-open.
15/07/2007 06:43
org>, <>,
PM
<>,
"Bryan
Schnabel"
<>,
<>,
<>,
<>,
<>,
<>,
<>,
<>,
"Howard.Schwartz"
<>,
<>,
<tony.jewtushenko@productinnovator.
com>,
Kara
Warburton/Toronto/IBM@IBMCA,
<>
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 T. Hackos, PhD
President
Comtech Services, Inc.
710 Kipling Street, Suite 400
Denver, CO 80215
303-232-7586
www.comtech-serv.com
