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