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 <>
>
cc
>
-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
>
>
>
> "JoAnn Hackos"
> <>
>
>
To
> 07/08/2007 01:29 AM
<[email protected]
> 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
>
> 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
>
>
>
>
>
>
