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


Given that I'll soon be shutting down my computer for an extended period, I
went ahead and created a requirements page to get more discussion going:
http://wiki.oasis-open.org/dita/AcronymRequirements

If you are interested in the issue and have a requirement that is not
listed, please add it. At this point, please do not remove any requirements
that you do not agree with, though feel free to add a comment to any item.
If for some reason you don't have access to edit the wiki, please send in
your requirements to the list and somebody will add them.

I also put a link to this page onto the main subcommittee page, and
modified the main page as needed. The "Purpose" section became the 4 bullet
points currently on the requirements page.

Thanks everybody -

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

Robert D Anderson/Rochester/IBM@IBMUS wrote on 08/08/2007 03:04:06 PM:

> 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]