[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita-translation] Re: Introduction of <surface-form> to the acronymproposal
Hi everybody,
The proposal to use keyword was made because that has (so far) been the
fallback for bits of reusable text that need to be used virtually anywhere.
It's allowed in more places than any of the other phrase-like elements. So,
using it for acronym would have the smallest impact to the rest of the spec
-- using term would probably mean that we're also adding term to new places
in the base DITA specification.
That said - I do think that details like this one are somewhat less
important. As far as I can tell, we still haven't made any progress on
figuring out what exactly this requirement is supposed to do. My starter
list from a couple weeks ago is unchanged:
http://wiki.oasis-open.org/dita/AcronymRequirements
I still think that several of us have different ideas of what this
requirement is supposed to do. It seems silly to argue over the technical
details of the solution when we don't agree on what we're trying to
accomplish. I really don't think it is possible to get agreement on a final
proposal unless we get agreement on the requirement. If we can figure out
what this needs to do, then it becomes much easier to discard extraneous
parts of the solution. If we try to discard one person's input without
being able to point to a requirement, then most likely this just means that
we are not going to meet that person's true requirements.
Does that make sense? I feel like we've gone back and forth on this issue a
lot, and this has always seemed to be at the root of it. We kind of took on
the proposal "I need an acronym requirement" and started designing without
spending much time on the requirement itself. I think we also still haven't
asked the main TC what *they* expect from this requirement; that might have
been my to-do before I left on vacation, but if so I'll have to apologize
for not getting to it.
Robert D Anderson
IBM Authoring Tools Development
Chief Architect, DITA Open Toolkit
(507) 253-8787, T/L 553-8787 (Good Monday & Thursday)
"JoAnn Hackos"
<joann.hackos@com
tech-serv.com> To
<Deborah_Pickett@moldflow.com>,
08/26/2007 08:34 "Andrzej Zydron"
PM <azydron@xml-intl.com>
cc
<dita-translation@lists.oasis-open.
org>, <bhertz@sdl.com>, "Bryan
Schnabel"
<bryan.s.schnabel@tek.com>, Charles
Pau/Cambridge/IBM@Lotus,
<christian.lieske@sap.com>,
<dpooley@sdl.com>,
<esrig-ia@esrig.com>,
<fsasaki@w3.org>,
<rfletcher@sdl.com>,
<mambrose@sdl.com>,
<ishida@w3.org>,
<tony.jewtushenko@productinnovator.
com>, <KARA@CA.IBM.COM>,
<ysavourel@translate.com>
Subject
RE: [dita-translation] Re:
Introduction of <surface-form> to
the acronym proposal
Hello Deborah,
The recommendation to use <keyword> in the acronym proposal came from
Robert Anderson. Perhaps (if Robert is back from holiday), he can comment
on the reasons for his recommendation. We have not discussed using <term>
Thanks for your input.
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
From: Deborah_Pickett@moldflow.com [mailto:Deborah_Pickett@moldflow.com]
Sent: Wednesday, August 22, 2007 5:30 PM
To: Andrzej Zydron
Cc: bhertz@sdl.com; bryan.s.schnabel@tek.com; charles_pau@us.ibm.com;
christian.lieske@sap.com; DITA Translation SC; dpooley@sdl.com;
dschell@us.ibm.com; fsasaki@w3.org; Gershon L Joseph;
Howard.Schwartz@trados.com; ishida@w3.org; Jennifer Linton; Kara Warburton;
mambrose@sdl.com; nick@salftrans.co.uk; pcarey@lexmark.com;
rfletcher@sdl.com; Sukumar.Munshi@lionbridge.com;
tony.jewtushenko@productinnovator.com; ysavourel@translate.com
Subject: Re: [dita-translation] Re: Introduction of <surface-form> to the
acronym proposal
Andrzej Zydron <azydron@xml-intl.com> wrote on 23/08/2007 12:09:10 AM:
> http://wiki.oasis-open.org/dita/TranslationSubcommittee/Acronyms
It's looking good. I've got a couple of comments on the current draft.
(I'm sorry I can't raise these personally at the conference call, but it's
at 1 am for me.)
1. Kara raised the good point about whether to use <term> or <keyword> as
the specialization base. Here are the descriptions of both elements from
the DITA 1.1 language spec:
-----
keyword
The <keyword> element identifies a keyword or token, such as a single value
from an enumerated list, the name of a command or parameter, product name,
or a lookup key for a message.
"Keyword" means any text that has a unique or key-like value. For example,
a product name. Where there is a element that has a better meaning for what
you are describing, use that element. The keyword element is a generic
element; use it when no other element applies. The keyword element can also
be used to contain reusable text.
-----
term
The <term> element identifies words that may have or require extended
definitions or explanations. In future development of DITA, for example,
terms might provide associative linking to matching glossary entries.
-----
It looks to me that <term> is a closer match.
2. Even though this proposal deliberately avoids talking about
abbreviations (that aren't acronyms), we should assume that users aren't
going to make the distinction, and that they will use this feature for
their abbreviations too. The "scope" section of the proposal should state
that the proposal is not intended to cover non-acronym abbreviations, and
why. (I assume that capitalization at the start of a sentence is one of
the aspects. I had a go at a proposal for a solution to the capitalization
issue, and it got so hairy that I doubt it would ever pass the TC vote. If
anyone wants a copy for posterity or humour value, call me.)
--
Deborah Pickett
Information Architect, Moldflow Corporation, Melbourne
Deborah_Pickett@moldflow.com
> Kara Warburton wrote:
> > Hi everyone,
> >
> > I have just returned from a business trip... sorry for being unable to
> > comment on the proposals or attend the meetings in recent weeks.
> >
> > I would like to make a few comments on the proposal....
> >
> > 1. We still have not addressed the situation of abbreviations that are
NOT
> > acronyms, such as "abend" for "abnormal end of task". These also have
to be
> > handled similar to acronyms but they need to be marked up with their
own
> > element. Marking them with <acronym> would be a mistake.
> >
> > 2. There are some ambiguities in the added text from Don... although
very
> > helpful I would like to suggest some changes to correct them. A few
> > examples would also help. Please see the attached doc file which has
"track
> > changes" enabled.
> >
> > (See attached file: Acronyms_and_translation_kw.doc)
> >
> >
> >
> > 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
> >
> >
> >
> > Andrzej Zydron -
> > XML-INTL
> > <azydron@xml-intl
To
> > .com> Gershon L Joseph
> > <gershon@tech-tav.com>
> > 14/08/2007 03:10
cc
> > PM DITA Translation SC
> >
<dita-translation@lists.oasis-open.
> > org>, mambrose@sdl.com,
> > pcarey@lexmark.com,
> > rfletcher@sdl.com,
bhertz@sdl.com,
> > ishida@w3.org,
> >
tony.jewtushenko@productinnovator.c
> > om, christian.lieske@sap.com,
> >
jennifer.linton@comtech-serv.com,
> > Sukumar.Munshi@lionbridge.com,
> > charles_pau@us.ibm.com,
> > dpooley@sdl.com,
> > nick@salftrans.co.uk,
> > fsasaki@w3.org,
> > ysavourel@translate.com,
> > dschell@us.ibm.com,
> > bryan.s.schnabel@tek.com,
> > Howard.Schwartz@trados.com, Kara
> > Warburton/Toronto/IBM@IBMCA
> >
Subject
> > Introduction of <surface-form>
to
> > the acronym proposal
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Hi Everyone,
> >
> > Subsequent to the TC discussion yesterday I have updated the proposal
> > accordingly:
> >
> > http://wiki.oasis-open.org/dita/TranslationSubcommittee/Acronyms
> >
> > The main point has been the addition of the <surface-form> element, and
> > the modification of the relevant text. I have also copied Don's
> > excellent 'Acronym and Translation' list into the proposal as it
> > defines succinctly the issues involved. I hope we are now very close to
> > full agreement on the acronym proposal.
> >
> > Best Regards,
> >
> > AZ
> >
> > --
> >
> >
> > email - azydron@xml-intl.com
> > smail - c/o Mr. A.Zydron
> > PO Box 2167
> > Gerrards Cross
> > Bucks SL9 8XF
> > United Kingdom
> > Mobile +(44) 7966 477 181
> > FAX +(44) 1753 480 465
> > www - http://www.xml-intl.com
> >
> > This message contains confidential information and is intended only
> > for the individual named. If you are not the named addressee you
> > may not disseminate, distribute or copy this e-mail. Please
> > notify the sender immediately by e-mail if you have received this
> > e-mail by mistake and delete this e-mail from your system.
> > E-mail transmission cannot be guaranteed to be secure or error-free
> > as information could be intercepted, corrupted, lost, destroyed,
> > arrive late or incomplete, or contain viruses. The sender therefore
> > does not accept liability for any errors or omissions in the contents
> > of this message which arise as a result of e-mail transmission. If
> > verification is required please request a hard-copy version. Unless
> > explicitly stated otherwise this message is provided for informational
> > purposes only and should not be construed as a solicitation or offer.
> >
> >
> >
> >
> > (See attached file: azydron.vcf)
>
>
> --
> email - azydron@xml-intl.com
> smail - c/o Mr. A.Zydron
> PO Box 2167
> Gerrards Cross
> Bucks SL9 8XF
> United Kingdom
> Mobile +(44) 7966 477 181
> FAX +(44) 1753 480 465
> www - http://www.xml-intl.com
>
> This message contains confidential information and is intended only for
> the individual named. If you are not the named addressee you may not
> disseminate, distribute or copy this e-mail. Please notify the sender
> immediately by e-mail if you have received this e-mail by mistake and
> delete this e-mail from your system.
> E-mail transmission cannot be guaranteed to be secure or error-free as
> information could be intercepted, corrupted, lost, destroyed, arrive
> late or incomplete, or contain viruses. The sender therefore does not
> accept liability for any errors or omissions in the contents of this
> message which arise as a result of e-mail transmission. If verification
> is required please request a hard-copy version. Unless explicitly stated
> otherwise this message is provided for informational purposes only and
> should not be construed as a solicitation or offer.
>
>
> [attachment "azydron.vcf" deleted by Deborah A Pickett/MOLDFLOW]
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]