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
From: Bruce Esrig
[mailto:esrig-ia@esrig.com]
Sent: Monday, July 09, 2007 5:29
AM
To: JoAnn Hackos;
dita-translation@lists.oasis-open.org; mambrose@sdl.com; bhertz@sdl.com; Bryan
Schnabel; charles_pau@us.ibm.com; christian.lieske@sap.com; dpooley@sdl.com;
dschell@us.ibm.com; fsasaki@w3.org; rfletcher@sdl.com; Howard.Schwartz;
ishida@w3.org; tony.jewtushenko@productinnovator.com; KARA@CA.IBM.COM;
ysavourel@translate.com
Subject: Re: Translation
Subcommittee Agenda -- 9 July 2007
In case I cannot attend today, I'd like to offer a few comments on a
recent version of the proposal, starting with contrary comments.
1. The first example Anti-lock braking system (ABS) does not separate the
expanded and short form. The second example (WMD) does separate the expanded
and short form. Separating them is more in line the XML principle: give each
meaningful unit its own markup.
2. The example from Polish is well-explained. There is another example that
could be added, which is that corporate style guides may require a particular
order. Note that if the style guide were to change, or if information were
exchanged among companies with differing style guides, it would be more
convenient to have the expanded and short forms separate.
3. Although the text acknowledges the special context "start of
sentence", more work needs to be done to clarify what this context is and
how it can be recognized.
3a(1). Is it an obligation of the user to use a special form of the
<acronym> element at the start of a sentence? If so, what form should be
used?
3a(2). Or is there some other markup that would indicate this context, so that
processing could present the short form even upon the first occurrence?
3b(1). In case the first occurrence is at the beginning of a sentence, is the
right behavior to put the short form first ***followed by the expanded form***
regardless of what the style guide specifies?
3b(2). Is a global setting of some sort (perhaps in a configuration file)
required in order to specify the order preferred by the style guide? Perhaps a
default would be required per language, followed by an override specified in
the configuration file used when the processing system is set up. The DITA TC
has in the past specified language features and avoided specifying
implementation details for processing, but the TC could provide remarks here stating
what solutions vendors might wish to consider. The proposal should be explicit
about these considerations since they are bound to come up at multiple levels
of review.
4.. The key difference between the use case section and the preceding sections
seems to be that the use case section talks in terms of output. Would it be
possible to talk about each use case in terms of output first, and supporting
markup second? In this way the desired output could be agreed upon, and then
the means to achieve it could be discussed.
5. Basing the <acronym> element on the <data> element seems very
promising.
Best wishes,
Bruce Esrig
At 08:18 AM 7/8/2007, JoAnn Hackos wrote:
Hello All,
If any of you know how to add content to the new translation wiki (please add
Andrzej's proposal and all the comments received). Thank you. JoAnn
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 18 June 2007 . attached
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
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
Don asked Gershon to make new
Wiki page with links to the latest drafts
of the Translation SC BPs for review.
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 Accessibilty 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 attached zip file.
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<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office"
/>