[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [oaxal] Re: OAXAL in OASIS XHTML format
Hi Bryan, I think Andrzej has the images; they're just referenced to an external server. I need to have all the images locally - the easiest way to get them is in a zip. Thanks! Mary Mary P McRae Director, Technical Committee Administration OASIS: Advancing open standards for the information society email: mary.mcrae@oasis-open.org web: www.oasis-open.org twitter: fiberartisan phone: 1.603.232.9090 On Apr 1, 2009, at 5:17 PM, <bryan.s.schnabel@tektronix.com> <bryan.s.schnabel@tektronix.com > wrote: > Hi Andrzej and Mary, > > Do you need me to stop dragging my feet and update the SVG files? Or > does the spec link to the bitmaps? > > Sorry if I'm delaying things. > > Bryan > > > -----Original Message----- > From: Mary McRae [mailto:mary.mcrae@oasis-open.org] > Sent: Wednesday, April 01, 2009 11:54 AM > To: Andrzej Zydron > Cc: oaxal@lists.oasis-open.org > Subject: [oaxal] Re: OAXAL in OASIS XHTML format > > > Hi Andrzej, > > Can you zip up all the images and send those to me as well? We need > to make sure everything is on the OASIS servers. > > thanks! > > Mary > > Mary P McRae > Director, Technical Committee Administration > OASIS: Advancing open standards for the information society > email: mary.mcrae@oasis-open.org > web: www.oasis-open.org > twitter: fiberartisan > phone: 1.603.232.9090 > > > > > On Mar 28, 2009, at 4:41 PM, Andrzej Zydron wrote: > >> Hi Mary, >> >> Please find attached the zipped up version of the XHTML. The images >> are held externally, but all of the links work. We are in the >> process of moving the images to SVG format. I have also moved the >> references to sections 1.6 and 1.7 as well as improving the table of >> contents layout. >> >> >> I have tried to upload the document to the OAXAL Committee Documents >> page, but have totally failed (in spite of extensively referencing >> the online help). I cannot find any icon/link to upload documents. >> Could you please help? >> >> Best Regards, >> >> AZ >> >> Mary McRae wrote: >>> Hi Andrzej, >>> >>> The document is appearing in the text of the message and I'm >>> unable to extract it as xhtml ... can you zip the xhtml and image >>> files and send it that way? >>> >>> The only thing that's out of place (besides the metadata I can add >>> to the front matter for you) is that the references need to be in >>> the first Section following 1.5 (1.6 and 1.7). Everything else >>> looks okay at this level. >>> >>> thanks! >>> >>> Mary >>> >>> Mary P McRae >>> Director, Technical Committee Administration >>> OASIS: Advancing open standards for the information society >>> email: mary.mcrae@oasis-open.org <mailto:mary.mcrae@oasis-open.org> >>> web: www.oasis-open.org <http://www.oasis-open.org> >>> twitter: fiberartisan >>> phone: 1.603.232.9090 >>> >>> >>> >>> >>> On Mar 26, 2009, at 3:54 PM, Andrzej Zydron wrote: >>> >>>> Hi Mary, >>>> >>>> Please find attached the draft OAXAL Reference Architecture >>>> Specification document in OASIS required format for review by >>>> OASIS. Please feed back any problems. >>>> >>>> Best Regards, >>>> >>>> AZ >>>> >>>> -- >>>> email - azydron@xml-intl.com <mailto: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. >>>> >>>> >>>> OASIS logo >>>> >>>> Reference Model for Open Architecture for XML Authoring and >>>> Localization 1.0 >>>> >>>> Draft for Review >>>> >>>> 20 March 2009 >>>> >>>> Specification URIs: >>>> >>>> This Version: 1.0 draft >>>> >>>> http://docs.oasis-open.org/oaxal/V1.0/oaxal.html >>>> >>>> Technical Committee: >>>> >>>> Chair(s): >>>> >>>> Andrzej Zydron >>>> >>>> Editor(s): >>>> >>>> Andrzej Zydron >>>> Derek Saldana >>>> >>>> Related Work: >>>> >>>> This specification replaces or supercedes: >>>> >>>> Declared XML Namespace(s): >>>> >>>> oaxal >>>> >>>> Abstract: >>>> >>>> The Open Architecture for XML Authoring and Localization (OAXAL) >>>> provides a comprehensive, efficient, and cost-effective model for >>>> building an XML lifecycle production framework based completely on >>>> Open Standards from ic trademarked names, abbreviations, etc. >>>> here] are trademarks of OASIS <http://www.oasis-open.org>,LISA >>>> OSCAR <http://www.lisa.org/Standards.30.0.html> and W3C <http://www.w3.org >>>>> . >>>> >>>> Status: >>>> >>>> This document was last revised or approved by the [TC name | >>>> membership of OASIS] on the above date. The level of approval is >>>> also listed above. Check the "Latest Version" or "Latest Approved >>>> Version" location noted above for possible later revisions of this >>>> document. >>>> >>>> Technical Committee members should send comments on this >>>> specification to the Technical Committee's email list. Others >>>> should send comments to the Technical Committee by using the "Send >>>> A Comment" button on the Technical Committee's web page at http://www.oasis-open.org/committees/ >>>> [specific location]. >>>> >>>> For information on whether any patents have been disclosed that >>>> may be essential to implementing this specification, and any >>>> offers of patent licensing terms, please refer to the Intellectual >>>> Property Rights section of the Technical Committee web page (http://www.oasis-open.org/committees/ >>>> [specific location]/ipr.php. >>>> >>>> The non-normative errata page for this specification is located >>>> at http://www.oasis-open.org/committees/ >>>> [specific location]. >>>> >>>> Notices >>>> >>>> Copyright (c) OASIS(r) 2008. All Rights Reserved. >>>> >>>> All capitalized terms in the following text have the meanings >>>> assigned to them in the OASIS Intellectual Property Rights Policy >>>> (the "OASIS IPR Policy"). The full Policy may be found at the >>>> OASIS website. >>>> >>>> This document and translations of it may be copied and furnished >>>> to others, and derivative works that comment on or otherwise >>>> explain it or assist in its implementation may be prepared, >>>> copied, published, and distributed, in whole or in part, without >>>> restriction of any kind, provided that the above copyright notice >>>> and this section are included on all such copies and derivative >>>> works. However, this document itself may not be modified in any >>>> way, including by removing the copyright notice or references to >>>> OASIS, except as needed for the purpose of developing any document >>>> or deliverable produced by an OASIS Technical Committee (in which >>>> case the rules applicable to copyrights, as set forth in the OASIS >>>> IPR Policy, must be followed) or as required to translate it into >>>> languages other than English. >>>> >>>> The limited permissions granted above are perpetual and will not >>>> be revoked by OASIS or its successors or assigns. >>>> >>>> This document and the information contained herein is provided on >>>> an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR >>>> IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF >>>> THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR >>>> ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A >>>> PARTICULAR PURPOSE. >>>> >>>> OASIS requests that any OASIS Party or any other party that >>>> believes it has patent claims that would necessarily be infringed >>>> by implementations of this OASIS Committee Specification or OASIS >>>> Standard, to notify OASIS TC Administrator and provide an >>>> indication of its willingness to grant patent licenses to such >>>> patent claims in a manner consistent with the IPR Mode of the >>>> OASIS Technical Committee that produced this specification. >>>> >>>> OASIS invites any party to contact the OASIS TC Administrator if >>>> it is aware of a claim of ownership of any patent claims that >>>> would necessarily be infringed by implementations of this >>>> specification by a patent holder that is not willing to provide a >>>> license to such patent claims in a manner consistent with the IPR >>>> Mode of the OASIS Technical Committee that produced this >>>> specification. OASIS may include such claims on its website, but >>>> disclaims any obligation to do so. >>>> >>>> OASIS takes no position regarding the validity or scope of any >>>> intellectual property or other rights that might be claimed to >>>> pertain to the implementation or use of the technology described >>>> in this document or the extent to which any license under such >>>> rights might or might not be available; neither does it represent >>>> that it has made any effort to identify any such rights. >>>> Information on OASIS' procedures with respect to rights in any >>>> document or deliverable produced by an OASIS Technical Committee >>>> can be found on the OASIS website. Copies of claims of rights made >>>> available for publication and any assurances of licenses to be >>>> made available, or the result of an attempt made to obtain a >>>> general license or permission for the use of such proprietary >>>> rights by implementers or users of this OASIS Committee >>>> Specification or OASIS Standard, can be obtained from the OASIS TC >>>> Administrator. OASIS makes no representation that any information >>>> or list of intellectual property rights will at any time be >>>> complete, or that any claims in such list are, in fact, Essential >>>> Claims. >>>> >>>> The names "OASIS", [insert specific trademarked names, >>>> abbreviations, etc. here] are trademarks of OASIS <http://www.oasis-open.org >>>>> , the owner and developer of this specification, and should be >>>> used only to refer to the organization and its official outputs. >>>> OASIS welcomes reference to, and implementation and use of, >>>> specifications, while reserving the right to enforce its marks >>>> against misleading uses. Please see http://www.oasis-open.org/who/trademark.php >>>> for above guidance. >>>> >>>> Table of Contents >>>> >>>> 1 Introduction <#head-48c825f199b0e6630d9832f61b5b9bc0b5879d24> >>>> 1.1 What is a reference model >>>> <#head-64b1ba88ee723c2d958965b0d4c77fe1e3b9f1db> >>>> 1.2 A Reference Model for Open Architecture for XML Authoring and >>>> Localization <#head-5c7d8eed45828b079645f402af408ef060b942f9> >>>> 1.3 Audience <#head-0e5d969527a005e49d625f628f5baa5c3b196577> >>>> 1.4 Guide to using the reference model >>>> <#head-4d7c324538ab3d9dbdad8359e068df2819461ccb> >>>> 1.5 Notational Conventions <#head- >>>> abeb8f4573db27c622a33ba4084df5e8443903ee> >>>> >>>> 2 Open Architecture for XML Authoring and Localization >>>> <#head-662fc4cce449a0e31f6b3ace36591f785cea8575> >>>> 2.1 Authoring and Localization Reference Workflow <#head- >>>> bfc19ad58357f53f2e1556c7600c4da3655f55c6> >>>> 2.2 OAXAL Components >>>> <#head-39688d8756520fe5c9794dc7d0390812b1ede00a> >>>> 2.2.1 Unicode <#head-ed917814f1e98cd2e73b3652d70278bcf60bc3ac> >>>> 2.2.2 XML <#head-6408d392ffaa15d0293e8dcc0b9b4a35c4b2a7e3> >>>> 2.2.3 W3C ITS <#head-fe6c590672e4f8f3da39bd74f15128ef7c03ae80> >>>> 2.2.4 Unicode TR29 <#head-35454ca9c783cdeba18b4df84a30a497585cc505> >>>> 2.2.5 SRX <#head-ea58f85c18f2ed474538b91f395a0226edb5f34c> >>>> 2.2.6 xml:tm <#head-0faa13878c574639901c16adc58837899e2809be> >>>> 2.2.7 GMX <#head-8d420069c2d976dffe4dd4f53e73991c4cb3e756> >>>> 2.2.8 TMX <#head-54c33fcd17ca0bad4c7ed4eb33146e1e1d55a480> >>>> 2.2.9 XLIFF <#head-dc453440c67b92b2b38db3b56c824da23fed5969> >>>> >>>> 2.3 Interaction of Standards >>>> <#head-9881e384a3d39e0a15f95de2aa2d922233544611> >>>> 2.3.1 Unicode TR29 <#head-c23ab7b38d13cd52bc91f866825ed660fdd1c8c6> >>>> 2.3.2 SRX <#head-8fb790176ffc347919d81dc21d1f6942bc0f07a3> >>>> 2.3.3 W3C ITS <#head-f60bb40bb850050abe4d8aaef38afad49805d3d4> >>>> 2.3.4 xml:tm <#head-1cc2f6eb09ba51cb461ab3ee3f170c902a531d63> >>>> 2.3.5 GMX/V <#head-8d720bfea02ca857c3deabfb4afce2bdb7c13ca2> >>>> 2.3.6 XLIFF <#head-bae9ed73d96444d68b055ea34979c892fa6b93a8> >>>> >>>> 2.4 Major Processing Features >>>> <#head-9e9f259fdc206e56a020fcca9d7939d1bcccd33b> >>>> 2.4.1 The Traditional Localization Workflow >>>> <#head-92cd0fcb54cfe7640b7bbf6aec19a35f7decdf72> >>>> 2.4.2 OAXAL Localization Workflow >>>> <#head-12097263753e74024216c4f6c203a53667bcb64e> >>>> >>>> >>>> 3 The Reference Model >>>> <#head-4ee01ab1a80717538e069b0c2a1fc1d3b6361560> >>>> 3.1 OAXAL within a CMS environment >>>> <#head-8631426d1a9aa72d4261f85331b85324defa3b6c> >>>> 3.1.1 Authoring Workflow <#head- >>>> b0ea5247dfd7b6ef2a6dfa6aeda33c1bd9cea03f> >>>> 3.1.2 Localization Workflow >>>> <#head-8672590f2ca9af50b01ed352e728ca71074862a1> >>>> >>>> 3.2 OAXAL within a Localization-only Workflow >>>> <#head-948cd793c43e080f701918d7b17f25ffeab6158a> >>>> 3.3 OAXAL Alternative Translation-only Workflow >>>> <#head-83b76380e6d000ec1eb1b2f6c68196e51fec287c> >>>> 3.4 OAXAL Operations <#head- >>>> fc540ed99e62bdc86e3916a6fe47cdd000212019> >>>> 3.4.1 SEEDING <#head-2cddd2f3919afa11cb9a710ffa398a26778d9d84> >>>> 3.4.2 DIFFING <#head-3180625f6a1a24699fa41d29d02506286000f8e6> >>>> 3.4.3 EXTRACTION <#head-66cd8063f0faa4ad9a8ac25050240989dad9ac5f> >>>> 3.4.4 ALTERNATIVE EXTRACTION >>>> <#head-66292d6f73ba71ebfa327910a858684c6dd35588> >>>> 3.4.5 MERGING <#head-df0006e6512f83acf96e7fa636b6140aaa8059c8> >>>> 3.4.6 PACKING <#head-92dd46abbf543fec4c3c85b276a6790dea4fe3ae> >>>> 3.4.7 STRIPPING <#head-c5069f7ed03dbb303ffef9911b40f1b21758758a> >>>> >>>> >>>> 4 Conformance Guidelines >>>> <#head-5993852a27e05d73cc307b963763f76f988fda8d> >>>> 5 References <#head-66e9b74bb48a9861e5d5b6da9d695a084352de9c> >>>> 5.1 Normative <#head-53ab44b77f4c433510357361e4004be984109d5e> >>>> 5.2 Non-Normative <#head-a71c0de9bc202c65c84832f097a0e470a00bebee> >>>> >>>> A. Glossary <#head-eb06ae6f7d87ff239c33af868cd3c4a16f5c555a> >>>> B. Acknowledgments <#head-e45e69c0489a679be15bd4f277e791b1eaf9ca73> >>>> >>>> >>>> 1 Introduction >>>> >>>> The Open Architecture for XML Authoring and *Localization >>>> <#Localization>* (OAXAL) represents a comprehensive, efficient, >>>> and cost-effective model regarding the authoring and translation >>>> aspects of XML publishing. OAXAL encompasses the following key >>>> Open Standards: >>>> >>>> * >>>> >>>> XML <http://www.w3.org/XML/> - Extensible Markup Language (XML) >>>> is a simple, flexible text format originally designed to meet >>>> the challenges of large-scale electronic publishing. XML also >>>> plays an increasingly important role in the exchange of a wide >>>> variety of data on the Web and elsewhere. >>>> >>>> * >>>> >>>> Unicode <http://www.unicode.org/> - A character encoding scheme >>>> that encompasses all character sets. >>>> >>>> * >>>> >>>> W3C ITS <http://www.w3.org/TR/2007/REC-its-20070403/> - An XML >>>> vocabulary that defines translatability rules for a given XML >>>> document type. >>>> >>>> * >>>> >>>> SRX <http://www.lisa.org/Segmentation-Rules-e.40.0.html> - >>>> Segmentation Rules eXchange, a LISA OSCAR >>>> <http://www.lisa.org/OSCAR-LISA-s-Standa.79.0.html> standard >>>> defining text-subdivision rules for each language. >>>> >>>> * >>>> >>>> xml:tm <http://www.lisa.org/XML-Text-Memory-xml.107.0.html> - >>>> XML-based text memory, a LISA OSCAR >>>> <http://www.lisa.org/OSCAR-LISA-s-Standa.79.0.html> standard >>>> for author memory (a history of segments and revisions) and >>>> translation memory (a history of translated segments). >>>> >>>> * >>>> >>>> GMX <http://www.lisa.org/Global-information-m.104.0.html> - >>>> Global Information Management Metrics Exchange, a LISA OSCAR >>>> <http://www.lisa.org/OSCAR-LISA-s-Standa.79.0.html> standard >>>> for word and character count and metrics (for volume, >>>> complexity, and quality) exchange. >>>> >>>> * >>>> >>>> TMX <http://www.lisa.org/Translation-Memory-e.34.0.html> - >>>> Translation Memory eXchange, a LISA OSCAR >>>> <http://www.lisa.org/OSCAR-LISA-s-Standa.79.0.html> standard >>>> for exchanging translation memories. >>>> >>>> * >>>> >>>> Unicode TR29 <http://unicode.org/reports/tr29/> - The primary >>>> Unicode standard defining word and sentence boundaries. >>>> >>>> * >>>> >>>> Open Standard XML Vocabularies, including DITA >>>> <http://www.oasis-open.org/apps/org/workgroup/dita/>, Docbook >>>> <http://www.oasis-open.org/apps/org/workgroup/docbook/>, XHTML >>>> <http://www.w3.org/TR/xhtml11/>, SVG >>>> <http://www.w3.org/Graphics/SVG/>, ODF >>>> <http://www.oasis-open.org/apps/org/workgroup/office/>, and >>>> others that may emerge as standards. >>>> >>>> * >>>> >>>> XLIFF <http://www.oasis-open.org/apps/org/workgroup/xliff/> - >>>> XML Localization <#Localization> Interchange File Format, >>>> an OASIS <http://www.oasis-open.org/> standard for >>>> exchanging Localization <#Localization> data. >>>> >>>> The architectural model for OAXAL is as follows: >>>> >>>> >>>> OAXAL-elegant-arch-noLegend >>>> >>>> *Figure 1: OAXAL Standards Component Stack* >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> The following diagram represents the interaction of the key OAXAL >>>> standards: >>>> >>>> oaxal-diag-IV >>>> >>>> *Figure 2: OAXAL Interaction of Standards* >>>> >>>> This diagram is annotated and described in detail in subsequent >>>> parts of this document. OAXAL is designed to cope with the common >>>> requirements for XML authoring and Localization <#Localization>. >>>> The authoring plus Localization <#Localization> aspects of OAXAL >>>> are most effective within a Content Management System (*CMS >>>> <#CMS>*) environment. For a translation-only *workflow >>>> <#Workflow>*, OAXAL can be implemented without a CMS <#CMS> system. >>>> >>>> OAXAL is designed to integrate tightly and transparently within >>>> the document-life-cycle workflow <#Workflow> model which includes: >>>> >>>> * document creation >>>> * the authoring cycle >>>> * >>>> >>>> Localization <#Localization> >>>> >>>> * >>>> >>>> subsequent document updates and the Localization >>>> <#Localization> thereof >>>> >>>> For the translation-only environment, OAXAL provides an elegant >>>> and open architecture for processing XML documents for translation. >>>> >>>> >>>> 1.1 What is a reference model >>>> >>>> A /reference model/ is an abstract framework for understanding >>>> significant relationships among the entities of some environment. >>>> It enables the development of specific reference or concrete >>>> architectures using consistent standards or specifications >>>> supporting that environment. A reference model consists of a >>>> minimal set of unifying concepts, axioms, and relationships within >>>> a particular problem domain and is independent of specific >>>> standards, technologies, implementations, or other concrete >>>> details. >>>> >>>> As an illustration of the relationship between a reference model >>>> and the architectures that can derive from such a model, consider >>>> what might be involved in modeling important aspects of >>>> residential housing. In the context of a reference model, we know >>>> that concepts such as eating areas, hygiene areas, and sleeping >>>> areas are all important in understanding what goes into a house. >>>> There are relationships among these concepts and constraints on >>>> their implementation. For example, there may be a physical >>>> separation between eating areas and hygiene areas. >>>> >>>> The role of a reference architecture for housing would be to >>>> identify abstract solutions to the problems of providing housing. >>>> A general pattern for housing, one that addresses the needs of its >>>> occupants in the sense of, say, noting that there are bedrooms, >>>> kitchens, hallways, and so on is a good basis for an abstract >>>> reference architecture. The concept of "eating area" is a >>>> reference model concept; a kitchen is a realization of "eating >>>> area" in the context of the reference architecture. >>>> >>>> There may be more than one reference architecture that addresses >>>> how to design housing; for example, there may be a reference >>>> architecture to address the requirements for developing housing >>>> solutions in large apartment complexes, another to address >>>> suburban single family houses, and another for space stations. In >>>> the context of high-density housing, there may not be a separate >>>> kitchen but rather a shared cooking space or even a communal >>>> kitchen used by many families. >>>> >>>> An actual - or /concrete/ - architecture would introduce >>>> additional elements. It would incorporate particular architectural >>>> styles, particular arrangements of windows, construction materials >>>> to be used, and so on. A blueprint of a particular house >>>> represents a specific architecture as it applies to a proposed or >>>> an actual constructed dwelling. >>>> >>>> The reference model for housing is, therefore, at least three >>>> levels of abstraction away from a physical entity that can be >>>> lived in. The purpose of a reference model is to provide a common >>>> conceptual framework that can be used consistently across >>>> different implementations and is of particular use in modeling >>>> specific solutions. >>>> >>>> >>>> 1.2 A Reference Model for Open Architecture for XML Authoring and >>>> Localization >>>> >>>> The goal of this reference model is to define the component parts >>>> of XML publishing with respect to the authoring and Localization >>>> <#Localization> aspects of the process. It provides a normative >>>> reference that remains relevant for OAXAL as a comprehensive model. >>>> >>>> The OAXAL standards components stack <#OAXAL-diag-II> shows how >>>> the reference model for OAXAL is constructed from its constituent >>>> Open Standards. The concepts and relationships defined by the >>>> reference model are the basis for describing the reference >>>> architecture. >>>> >>>> Architecture must account for the goals, motivation, and >>>> requirements that define the actual problems being addressed. >>>> While reference architectures can form the basis of classes of >>>> solutions, concrete architectures will define specific solution >>>> approaches. >>>> >>>> Architecture is often developed in the context of a pre-defined >>>> environment, such as the protocols, profiles, specifications, and >>>> standards that are pertinent. >>>> >>>> OAXAL implementations combine all of these elements, from the more >>>> generic architectural principles and infrastructure to the >>>> specifics that define the current needs, and represent specific >>>> implementations that will be built and used in an operational >>>> environment. >>>> >>>> >>>> 1.3 Audience >>>> >>>> The intended audiences of this document include (non-exhaustively): >>>> >>>> * Architects and developers designing, identifying, or developing >>>> a system based on OAXAL >>>> * Standards architects and analysts developing specifications >>>> that rely on OAXAL >>>> * Decision makers seeking a "consistent and common" understanding >>>> of OAXAL >>>> * Users who need a better understanding of the concepts and >>>> benefits of OAXAL >>>> >>>> >>>> 1.4 Guide to using the reference model >>>> >>>> New readers are encouraged to read this reference model in its >>>> entirety. Concepts are presented in an order that the authors hope >>>> promote rapid understanding. >>>> >>>> This section introduces the conventions, defines the audience, and >>>> sets the stage for the rest of the document. Non-technical readers >>>> are encouraged to read this information because it provides >>>> background material necessary to understand the nature and use of >>>> reference models. >>>> >>>> * >>>> >>>> The Open Architecture for XML Authoring and Localization >>>> <#OAXAL> section introduces the concept of OAXAL and identifies >>>> some of the ways that it differs from previous paradigms for >>>> authoring and translation systems. This section offers guidance >>>> on the basic principles of OAXAL. This section can be used by >>>> non-technical readers to gain an explicit understanding of the >>>> core principles of OAXAL and by architects as guidance for >>>> developing OAXAL-based architectures. >>>> >>>> * >>>> >>>> The Reference Model <#ReferenceModel> section introduces the >>>> Reference Model for OAXAL. >>>> >>>> * >>>> >>>> The Conformance Guidelines <#ConformanceGuidelines> section >>>> addresses compliance with this reference model. >>>> >>>> The glossary <#Glossary> provides definitions of terms within the >>>> reference-model specification but does not necessarily form part >>>> of the specification itself. Terms that are defined in the >>>> glossary are marked in bold at their first occurrence in this >>>> document. >>>> >>>> Note that while the concepts and relationships described in this >>>> reference model may apply to other "service" environments, the >>>> definitions and descriptions contained herein focus on the field >>>> of software architecture and make no attempt to completely account >>>> for use outside of the software domain. Examples included in this >>>> document that are taken from other domains are used strictly for >>>> illustrative purposes. >>>> >>>> >>>> 1.5 Notational Conventions >>>> >>>> The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, >>>> SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to >>>> be interpreted as described in RFC2119 <http://www.ietf.org/rfc/rfc2119.txt >>>>> . >>>> >>>> >>>> >>>> 2 Open Architecture for XML Authoring and Localization >>>> >>>> Open Architecture for XML Authoring and Localization >>>> <#Localization> (OAXAL) is a reference model of how to construct >>>> an effective and efficient system for XML authoring and >>>> Localization <#Localization> based on Open Standards. OAXAL >>>> comprises the following standards: >>>> >>>> * >>>> >>>> XML <http://www.w3.org/XML/> -- Extensible Markup Language >>>> (XML) is a simple, flexible text format originally designed to >>>> meet the challenges of large-scale electronic publishing. XML >>>> also plays an increasingly important role in the exchange of a >>>> wide variety of data on the Web and elsewhere. >>>> >>>> * >>>> >>>> Unicode <http://www.unicode.org/> - A character encoding scheme >>>> that encompasses all character sets. >>>> >>>> * >>>> >>>> W3C ITS W3C ITS <http://www.w3.org/TR/2007/REC-its-20070403/> - >>>> An XML vocabulary that defines translatability rules for a >>>> given XMLdocument type. >>>> >>>> * >>>> >>>> Unicode TR29 <http://unicode.org/reports/tr29/> - The primary >>>> Unicode standard defining word and sentence boundaries. >>>> >>>> * >>>> >>>> SRX <http://www.lisa.org/Segmentation-Rules-e.40.0.html> - >>>> Segmentation Rules eXchange, an XML vocabulary defining >>>> segmentation rules for each language. >>>> >>>> * >>>> >>>> xml:tm <http://www.lisa.org/XML-Text-Memory-xml.107.0.html> - >>>> XML-based text memory, a LISA OSCAR >>>> <http://www.lisa.org/OSCAR-LISA-s-Standa.79.0.html> standard >>>> for author and translation memory. >>>> >>>> * >>>> >>>> GMX <http://www.lisa.org/Global-information-m.104.0.html> - >>>> Global Information Management Metrics Exchange, a LISA OSCAR >>>> <http://www.lisa.org/OSCAR-LISA-s-Standa.79.0.html> standard >>>> for word and character count and metrics exchange. >>>> >>>> * >>>> >>>> TMX <http://www.lisa.org/Translation-Memory-e.34.0.html> - >>>> Translation Memory eXchange, a LISA OSCAR >>>> <http://www.lisa.org/OSCAR-LISA-s-Standa.79.0.html> standard >>>> for exchanging translation memories. >>>> >>>> * >>>> >>>> Open Standard XML Vocabularies, including DITA >>>> <http://www.oasis-open.org/apps/org/workgroup/dita/>, Docbook >>>> <http://www.oasis-open.org/apps/org/workgroup/docbook/>, XHTML >>>> <http://www.w3.org/TR/xhtml11/>, SVG >>>> <http://www.w3.org/Graphics/SVG/>, ODF >>>> <http://www.oasis-open.org/apps/org/workgroup/office/>, and >>>> others that may emerge as standards. >>>> >>>> * >>>> >>>> XLIFF <http://www.oasis-open.org/apps/org/workgroup/xliff/> - >>>> XML Localization <#Localization> Interchange File Format, >>>> an OASIS <http://www.oasis-open.org/> standard for >>>> exchanging Localization <#Localization> data. >>>> >>>> This Reference Model will demonstrate the integration of the >>>> standards listed above to present a complete automated package >>>> from authoring through translation; additional standards may be >>>> added by the Technical Committee (TC), and the TC may elect not to >>>> include (or to make optional) any of the standards listed above >>>> that prove, upon review, not to be feasible or useful to integrate >>>> in its profiles. Authors are provided with a systematic way to >>>> identify and store all previously authored sentences. OAXAL allows >>>> for some variation in how the standards are used and integrated. >>>> OAXAL variants may not use all of the standards enumerated above. >>>> >>>> >>>> 2.1 Authoring and Localization Reference Workflow >>>> >>>> Key to the concept of OAXAL are Authoring and Localization >>>> <#Localization>. Authoring in OAXAL implies XML-based source and >>>> the concept of a document lifecycle centered around some form of >>>> content management. Content management may be achieved by means of >>>> a fully fledged Content Management System (CMS <#CMS>) or a Source >>>> Control System (*SCS <#SCS>*). The document lifecycle implies one >>>> or more of the following stages: >>>> >>>> 1. Initial document creation >>>> 2. Authoring, Editing, and Validation/Approval >>>> 3. Publishing of the source-language version >>>> 4. >>>> >>>> Localization <#Localization>/Translation and Post-editing of >>>> the translated content >>>> >>>> 5. Publishing of the target-language material >>>> 6. >>>> >>>> Subsequent changes to the source material that require >>>> re-publishing and Localization <#Localization>/translation. >>>> >>>> OAXAL is designed to provide an effective and elegant solution to >>>> these requirements within an authoring/localization >>>> <#Localization> workflow <#Workflow>: >>>> >>>> SourceDocumentLifecycle-noLegend >>>> >>>> *Figure 3: Source Document Lifecycle* >>>> >>>> OAXAL can also be used to design Localization <#Localization>-only >>>> solutions. In this instance, a document is submitted for >>>> Localization <#Localization>. The format of the document may not >>>> be XML; nevertheless, OAXAL assumes a conversion to an XML form of >>>> the data prior to processing and a conversion back into the >>>> original format on completion. Translation/Localization >>>> <#Localization> comprises the following steps: >>>> >>>> 1. Identification of the text to be localized >>>> 2. Segmentation of the text into sentences if required >>>> 3. Matching of the sentences with previous translated versions of >>>> the document if possible >>>> 4. Translation of the text >>>> 5. QA/Post-editing of the translated text >>>> 6. Merging/recreation of the original document in the target >>>> language >>>> >>>> LocalizationLifecycleWorkflow-noLegend >>>> >>>> *Figure 4: Document Localization Lifecycle* >>>> >>>> >>>> 2.2 OAXAL Components >>>> >>>> >>>> 2.2.1 Unicode >>>> >>>> Unicode <http://www.unicode.org/> provides the underlying >>>> character encoding for OAXAL. Although XML allows various encoding >>>> schemes based on 7 and 8 bits, OAXAL mandates full Unicode >>>> encoding, preferably using UTF-8 or UTF16 encoding. The benefits >>>> of using Unicode character encoding for OAXAL are as follows: >>>> >>>> * There are no character restrictions. Even if the text does not >>>> require non-ASCII characters, Unicode allows for the use of >>>> special-width spaces, hyphens, and other frequently-used >>>> characters that fall outside of the scope of 7- and 8-bit >>>> character-encoding schemes. >>>> * The same encoding scheme is used for both source- and any >>>> target-language character requirements, thus greatly >>>> simplifying all aspects of editing and publication. >>>> >>>> >>>> 2.2.2 XML >>>> >>>> The key characteristic of OAXAL is the use of an Open Architecture >>>> based on Open Standards with XML as the source format for both the >>>> document format and, in most cases, the vocabulary of the >>>> standards. XML underpins the foundations of OAXAL. The XML source >>>> content provides semantic and structured text that can be >>>> localized. XML provides many benefits regarding authoring and >>>> Localization <#Localization>: >>>> >>>> 1. The separation of form and content provides an elegant and >>>> convenient way of identifying text and markup. >>>> 2. The extensible nature of XML allows the creation of specialist >>>> vocabularies that can be shared and adopted by interested >>>> parties. >>>> 3. The syntax of XML allows for the quick and easy validation of >>>> XML document instances against specific rules. >>>> 4. The widespread adoption of XML means that there are many tools >>>> to validate and transform XML documents. >>>> >>>> At the center of authoring and Localization <#Localization> is the >>>> actual XML document text to be authored and/or localized. OAXAL >>>> encompasses all publishing-oriented Open Standard XML vocabularies >>>> such as DITA <http://www.oasis-open.org/apps/org/workgroup/dita/>, >>>> Docbook <http://www.oasis-open.org/apps/org/workgroup/docbook/>, >>>> XHTML <http://www.w3.org/TR/xhtml11/>, SVG <http://www.w3.org/Graphics/SVG/ >>>>> , ODF <http://www.oasis-open.org/apps/org/workgroup/office/>, and >>>> others that may emerge as standards. OAXAL may also be used with >>>> proprietary XML vocabularies or with non-XML based documents that >>>> are converted into a non-Open Standard XML format. >>>> >>>> >>>> 2.2.3 W3C ITS >>>> >>>> W3C ITS <http://www.w3.org/TR/2007/REC-its-20070403/> is the >>>> Internationalization Tag Set Recommendation. ITS allows for the >>>> declaration of Document Rules for Localization <#Localization>. In >>>> effect, it provides a vocabulary that allows the declaration of >>>> the following for a given XML document type: >>>> >>>> 1. Which attributes are translatable >>>> 2. Which elements are 'in line'-that is, which elements do not >>>> break the linguistic flow of text (for example: 'emphasis' >>>> elements) >>>> 3. Which inline elements are 'sub flows'-that is, although they >>>> are inline, which inline elements do not form part of the >>>> linguistic flow of the encompassing text (for example: 'footer' >>>> and 'index' markers) >>>> >>>> W3C ITS provides many more features, including a namespace >>>> vocabulary that allows for fine-tuning Localization >>>> <#Localization> for individual instances of elements within a >>>> document instance. W3C ITS is therefore at the core of XML >>>> Localization <#Localization> processing. >>>> >>>> In OAXAL, W3C ITS stipulates the rules by which an XML document is >>>> localized in terms of its translatable content. >>>> >>>> >>>> 2.2.4 Unicode TR29 >>>> >>>> Unicode TR29 <http://unicode.org/reports/tr29/> is the Unicode >>>> standard defining word and sentence boundaries. It allows for a >>>> uniform way of defining word boundaries for OAXAL and, as such, is >>>> used by SRX <#SRX> and GMX/V <#GMXV> to tokenize text into >>>> individual words. It plays a fundamental role in OAXAL. >>>> >>>> >>>> >>>> 2.2.5 SRX >>>> >>>> SRX <http://www.lisa.org/Segmentation-Rules-e.40.0.html> - >>>> Segmentation Rules eXchange is an Open Standard XML vocabulary for >>>> defining the segmentation rules for a given language published by >>>> LISA OSCAR <http://www.lisa.org/OSCAR-LISA-s-Standa.79.0.html>. >>>> Segmentation is an important aspect of both the authoring and >>>> Localization <#Localization> processes. SRX allows OAXAL to have a >>>> sentence-level granularity. SRX depends on Unicode TR29 in order >>>> to provide the basis for tokenizing text into individual words. >>>> >>>> >>>> 2.2.6 xml:tm >>>> >>>> xml:tm <http://www.lisa.org/XML-Text-Memory-xml.107.0.html> is a >>>> namespace vocabulary providing a LISA OSCAR <http://www.lisa.org/OSCAR-LISA-s-Standa.79.0.html >>>>> standard for author and translation memory. xml:tm is a key >>>> component of OAXAL. xml:tm introduces the concept of XML-based >>>> text memory that encompasses both in-document author memory and >>>> translation memory. In the xml:tm scenario, author and translation >>>> memory are embedded within the XML document, providing both an >>>> edit-change history of the document as well as the mechanism for >>>> 'In Context Exact' (ICE) translation-memory matching. ICE matching >>>> guarantees that the text-unit matches are from exactly the same >>>> source as the previous iteration of an updated document, as >>>> opposed to leveraged matching which cannot guarantee the >>>> provenance of a 100% match. >>>> >>>> Given a W3C ITS rule set for a given XML vocabulary and the SRX >>>> segmentation rules for a given language, it is possible to >>>> construct a totally generic process for embedding the xml:tm text- >>>> memory namespace within the source document. xml:tm relies on W3C >>>> ITS and SRX. xml:tm allocates immutable unique identifiers to each >>>> translatable text content or a subdivision of such text content, >>>> resulting in identifiable individual sentences. >>>> >>>> The key role of xml:tm within OAXAL is in preparing an XML >>>> document for further processing as well as providing the >>>> syntactical basis for ICE matching. >>>> >>>> >>>> 2.2.7 GMX >>>> >>>> GMX <http://www.lisa.org/Global-information-m.104.0.html> - Global >>>> Information Management Metrics Exchange is a LISA OSCAR <http://www.lisa.org/OSCAR-LISA-s-Standa.79.0.html >>>>> standard for word and character count and metrics exchange. GMX >>>> is a tri-partite set of standards: >>>> >>>> >>>> * GMX/V - Volume, detailing word- and character-count metrics >>>> * GMX/C - Complexity, detailing the level of complexity of a >>>> given document in translation terms >>>> * GMX/Q - Quality, detailing the level of quality required for >>>> the translation of a given document >>>> >>>> Currently only GMX/V has been defined. GMX/V is a key component of >>>> OAXAL in terms of providing a uniform and consistent way of >>>> calculating the word- and character-count metrics for a given >>>> document or set of documents, as well as providing a way of >>>> embedding and exchanging such information. GMX/V depends on >>>> Unicode TR29 in order to provide the basis for tokenizing text >>>> into individual words. GMX/V also uses XLIFF as the canonical form >>>> for counting. >>>> >>>> >>>> 2.2.8 TMX >>>> >>>> TMX <http://www.lisa.org/Translation-Memory-e.34.0.html> - >>>> Translation Memory eXchange is a LISA OSCAR <http://www.lisa.org/OSCAR-LISA-s-Standa.79.0.html >>>>> standard for exchanging translation memories. TMX is a key >>>> component of OAXAL, allowing for the free exchange of translation >>>> memories. >>>> >>>> >>>> 2.2.9 XLIFF >>>> >>>> XLIFF <http://www.oasis-open.org/apps/org/workgroup/xliff/> - XML >>>> Localization <#Localization> Interchange File Format is an OASIS <http://www.oasis-open.org/ >>>>> standard for exchanging Localization <#Localization> data. >>>> Within OAXAL, the previously described standards help prepare the >>>> XML document for translation. The xml:tm version of the document >>>> contains all of the information required for extraction and both >>>> ICE and in-document leveraged and fuzzy matching. The >>>> transformation and matching process that goes into creating an >>>> XLIFF version of the document creates a document that can be >>>> processed and exchanged by any software that can read and >>>> understand an XLIFF file. XLIFF provides an important element of >>>> protection regarding the original XML document as well as a means >>>> to embed matching information. >>>> >>>> >>>> 2.3 Interaction of Standards >>>> >>>> The key concept of OAXAL concerns how to build an efficient and >>>> effective systems architecture based on its constituent standards. >>>> The most important aspect of this architecture is how the >>>> standards interact with one another. >>>> >>>> oaxal-diag-III >>>> >>>> *Figure 5: OAXAL Interaction of Standards* >>>> >>>> >>>> 2.3.1 Unicode TR29 >>>> >>>> Unicode TR29 <http://unicode.org/reports/tr29/> is used by SRX and >>>> GMX/V to tokenize text into white space, words, and punctuation. >>>> This tokenization is key to processing text for segmentation (SRX) >>>> and metrics (GMX/V). >>>> >>>> >>>> 2.3.2 SRX >>>> >>>> SRX <http://www.lisa.org/Segmentation-Rules-e.40.0.html> is used >>>> to segment text into individual sentences by xml:tm. >>>> >>>> >>>> 2.3.3 W3C ITS >>>> >>>> W3C ITS <http://www.w3.org/TR/2007/REC-its-20070403/> provides the >>>> rule set and in-document namespace directives for identifying >>>> translatable text within document elements and attributes. It is >>>> sufficient to create a W3C ITS rules file for a given XML >>>> vocabulary such as DITA or ODF to allow all such documents to be >>>> processed by OAXAL. There is no need to write separate filter >>>> programs for each XML vocabulary. W3C ITS is used by xml:tm to >>>> identify translatable text and segment it using SRX. >>>> >>>> >>>> 2.3.4 xml:tm >>>> >>>> xml:tm <http://www.lisa.org/XML-Text-Memory-xml.107.0.html> >>>> provides the basis of sentence-based text extraction by XLIFF as >>>> well as the foundation for ICE matching and all in-document >>>> leveraged and fuzzy matching. xml:tm can also be used to create >>>> TMX files from the aligned source and target versions of the >>>> document. >>>> >>>> xml:tm relies on: >>>> >>>> * W3C ITS to identify the translatable text content of a document >>>> * SRX (which requires Unicode TR29) to segment text into >>>> individual sentences, and >>>> * GMX/V to produce authoring and document statistics >>>> >>>> >>>> 2.3.5 GMX/V >>>> >>>> GMX/V <http://www.lisa.org/Global-information-m.104.0.html> is >>>> used to provide all of the metrics for XLIFF extraction and >>>> matching, as well as xml:tm authoring metrics during the document >>>> life cycle. >>>> >>>> >>>> 2.3.6 XLIFF >>>> >>>> XLIFF <http://www.oasis-open.org/apps/org/workgroup/xliff/> is >>>> used by GMV/V as the canonical form for metric-counting purposes, >>>> as well as providing the basis for TMX files based on the source >>>> and translated segments. Within OAXAL, XLIFF uses xml:tm to >>>> identify *text units <#TU>* requiring translation, as well as GMX/ >>>> V for metrics in terms of how many words/characters require >>>> translation. >>>> >>>> >>>> 2.4 Major Processing Features >>>> >>>> The true benefits of OAXAL accrue from the ability to produce a >>>> generic processing model for XML Authoring and Localization >>>> <#Localization>. The xml:tm and XLIFF operations are conducted by >>>> general-purpose programs which are completely parameter driven by >>>> input from the other standards. This parameterization allows for >>>> an elegant and very efficient process that is totally generic and >>>> easy to maintain. This benefit can be extended to non-XML document >>>> formats by converting them to an XML form and then processing them >>>> via OAXAL. >>>> >>>> >>>> 2.4.1 The Traditional Localization Workflow >>>> >>>> In the traditional Localization <#Localization> scenario, there is >>>> little or no automation of the Localization <#Localization> >>>> process. A file, or group of files, is handed over to a >>>> Localization <#Localization> facility, and the subsequent workflow >>>> <#Workflow> is made up of the following activities: >>>> >>>> TradLocalizationWorkflow-noLegend >>>> >>>> *Figure 6: Traditional Localization Workflow* >>>> >>>> Each of the arrows in this workflow <#Workflow> model represents a >>>> potential point of failure as well as manual intervention. Not >>>> only is this process very error prone, it also adds significantly >>>> to the cost of Localization <#Localization>. The following cost >>>> model for this scenario was presented by Prof. Reinhard Schäler of >>>> the Limerick University Localisation Research Centre at the Aslib >>>> Conference in London in 2002: >>>> >>>> CostOfTranslation-noLabel >>>> >>>> *Figure 7: Prof. Reinhard Schäler ASLIB 2002* >>>> >>>> The lack of an automated workflow <#Workflow> has a very >>>> detrimental affect on the Localization <#Localization> process. >>>> Without automation, considerable manual intervention is required, >>>> as is evidenced in the figure Traditional Localization Workflow >>>> <#TraditionalLocalizationWorkflow>. This lack of automation >>>> accounts for up to 50% of the total cost of Localization >>>> <#Localization>. >>>> >>>> >>>> 2.4.2 OAXAL Localization Workflow >>>> >>>> The Localization <#Localization> workflow <#Workflow> using OAXAL >>>> significantly reduces the processing costs: >>>> >>>> OAXALLocalizationWorkflow-noLegend >>>> >>>> *Figure 8: OAXAL Automated Localization Workflow* >>>> >>>> All of the processing steps, apart from the actual translation and >>>> QA activities, are completely automated. In addition, the use of >>>> XLIFF as the interchange standard means that translation can be >>>> presented via a browser interface, thus significantly simplifying >>>> the whole process. >>>> >>>> >>>> >>>> 3 The Reference Model >>>> >>>> oaxal-diag-III >>>> >>>> *Figure 9: OAXAL Reference Model* >>>> >>>> There are two prime use cases for OAXAL: >>>> >>>> 1. >>>> >>>> Handling authoring and Localization <#Localization> consistency >>>> within a CMS <#CMS> environment >>>> >>>> 2. >>>> >>>> Handling Localization <#Localization> consistency within a >>>> translation-only environment >>>> >>>> The essence of OAXAL is to facilitate the following: >>>> >>>> 1. Consistency in the authored source-language text >>>> 2. Consistency in the translated text >>>> 3. >>>> >>>> Substantial automation of the Localization <#Localization> >>>> process >>>> >>>> These results lead in the long term to reduced translation and >>>> authoring costs as well as improvements in the quality of the >>>> documentation. >>>> >>>> >>>> 3.1 OAXAL within a CMS environment >>>> >>>> OAXAL is fundamentally rooted in the concept of a document life >>>> cycle. The life-cycle steps comprise the following: >>>> >>>> 1. Document creation >>>> 2. Authoring cycle, including review >>>> 3. >>>> >>>> Localization <#Localization> >>>> >>>> 4. Update cycle >>>> 5. >>>> >>>> Localization <#Localization> of the updated text >>>> >>>> Thus, a document is created. It is authored by one or more writers >>>> and submitted to editorial review and correction. The document is >>>> subsequently published in the source language and localized into >>>> one or more target languages for publication. The document is then >>>> subjected to further modifications according to the requirements >>>> of the business unit that is charged with maintaining it. The >>>> updated document then requires localization <#Localization> again >>>> to translate any new or modified text, and so on during its >>>> existence. This paradigm is typical of the vast majority of >>>> technical documentation life-cycle processes. >>>> >>>> The unit of granularity defined by OAXAL is the text unit <#TU>. A >>>> text unit <#TU> is either of the following: >>>> >>>> * an identifiable sentence within an XML non-inline element >>>> * the whole text content of a non-inline element, if no further >>>> subdivision into sentences is possible (also known as a >>>> standalone piece of text) >>>> >>>> OAXAL can be viewed in terms of a workflow <#Workflow> comprising >>>> a series of processes that interact with the source text: >>>> >>>> 1. The XML source content provides the semantic and structured >>>> text that needs to be consistently authored and localized. >>>> 2. The W3C ITS rules provide the XML syntax to define which parts >>>> of the XML document are translatable (including translatable >>>> attributes) and additional important information, such as which >>>> XML elements do not break the linguistic integrity of >>>> surrounding text (so-called 'within text' elements, commonly >>>> known as in-line elements). >>>> 3. >>>> >>>> Unicode TR29 provides the definition of what constitutes text >>>> tokens within text. Tokens are words, punctuation, white space, >>>> and so on. Tokenization is an essential process for >>>> segmentation and for classifying text units <#TU>. >>>> >>>> 4. SRX provides an XML vocabulary for defining the detailed >>>> segmentation rules required to identify individual sentences. >>>> 5. >>>> >>>> The xml:tm namespace provides the means to manage the text at >>>> the sentence level. Each individual text unit >>>> <#TU> (identifiable sentence or standalone piece of text) is >>>> allocated, among others, the following: >>>> >>>> 1. An immutable unique identifier >>>> 2. A classification type (normal text, numeric, measurement, >>>> and so on) >>>> 3. >>>> >>>> A key based on the CRC <#CRC> of the text >>>> >>>> 6. >>>> >>>> XLIFF is an XML vocabulary that provides the means for >>>> packaging the text to be translated in a specific format >>>> especially designed for exchanging localizable data. XLIFF also >>>> provides the means for adding matching data, terminology, and >>>> metrics, as well as protecting the original XML document from >>>> accidental damage during the localization >>>> <#Localization> process. The xml:tm namespace version of the >>>> XML document provides all of the information required to easily >>>> and efficiently identify translatable text, but also for 'in >>>> context exact' (ICE) matching based on previous source and >>>> target versions of the document. >>>> >>>> 7. >>>> >>>> GMX/V provides an open, verifiable, and well-defined way of >>>> calculating localization <#Localization> metrics based on the >>>> XLIFF canonical form, Unicode TR29, as well as an XML >>>> vocabulary for exchanging localization <#Localization> metrics. >>>> >>>> 8. TMX is an XML vocabulary for exchanging translation-memory >>>> data. XLIFF files can be generated from translated XLIFF as >>>> well as source and translated xml:tm versions of the same >>>> document. >>>> >>>> The whole OAXAL environment is best viewed in terms of an >>>> authoring and localization <#Localization> workflow <#Workflow>, >>>> encompassing the following: >>>> >>>> 1. Check out for authoring >>>> 2. Check in from authoring >>>> 3. Check out for translation >>>> 4. Check in from translation >>>> >>>> >>>> 3.1.1 Authoring Workflow >>>> >>>> AuthoringFlow-noLabel >>>> >>>> *Figure 10: Authoring Workflow* >>>> >>>> 1. The XML document is created and checked out for authoring. >>>> 2. As part of the check out for authoring, the document is >>>> inspected to see if the xml:tm namespace exists within the >>>> document. If not, the xml:tm namespace is seeded into the >>>> document. >>>> 3. The seeding process includes the following: >>>> 1. Read in the W3C ITS document rules. >>>> 2. Identify all translatable text. >>>> 3. Tokenize the text according to Unicode TR29. >>>> 4. Read in the SRX segmentation rules for the language. >>>> 5. Apply the segmentation rules to the tokenized text >>>> stream. >>>> 6. >>>> >>>> Identify all text units <#TU>. >>>> >>>> 7. >>>> >>>> Allocate unique identifiers and CRC <#CRC> key and >>>> category data to the individual text units <#TU>. >>>> >>>> 8. Update the xml:tm document's overall housekeeping and >>>> administrative data. >>>> 9. >>>> >>>> The xml:tm version of the document is either stored in >>>> the CMS <#CMS> system or is zipped, base-64 encoded, and >>>> stored as a processing instruction within the document >>>> itself. >>>> >>>> 4. The document is authored and checked in again. >>>> 5. The new document is seeded with the xml:tm namespace as >>>> detailed above. >>>> 6. >>>> >>>> The original and new xml:tm versions of the document are >>>> compared with each other, and the text units <#TU> that have >>>> not changed are identified. The immutable identifiers from the >>>> original document are carried over to the new version, while >>>> new or modified text units <#TU>are allocated new immutable >>>> identifiers. >>>> >>>> 7. >>>> >>>> The updated xml:tm version of the document is either packed as >>>> a zipped base-64 processing instruction within the same >>>> document as detailed above or is stored as a separate entity in >>>> the CMS <#CMS> system. >>>> >>>> 8. >>>> >>>> The document is checked into the CMS <#CMS> system. >>>> >>>> >>>> 3.1.2 Localization Workflow >>>> >>>> TranslationFlow-noLegend >>>> >>>> *Figure 11: Localization Workflow* >>>> >>>> 1. >>>> >>>> The document is checked out for translation. A target-language >>>> object is created in the CMS <#CMS> system for this version of >>>> the source document. >>>> >>>> 2. >>>> >>>> The previous target version of the document is located, and the >>>> xml:tm version is either unpacked or located in the CMS >>>> <#CMS> system. >>>> >>>> 3. The current xml:tm version of the source document is produced >>>> in a similar manner. >>>> 4. >>>> >>>> The XLIFF version of the document is produced along with a >>>> skeleton file by navigating through all of the xml:tm text >>>> units <#TU> in the document. In-Context Matching, which >>>> provides a higher quality of translation-memory matching, is >>>> achieved by using the translated text from the previous >>>> localized version of the document, by means of text unit >>>> <#TU> unique identifiers. The previous translated version of >>>> the document also allows for more focused leveraged-memory >>>> matching using the CRC <#CRC> keys for each text unit <#TU>, as >>>> well as fuzzy matching based on modified text-unit identifiers. >>>> A skeleton file is created with placeholders where the >>>> translated text units <#TU> are to be placed. >>>> >>>> 5. >>>> >>>> The XLIFF file is handed off to the localization >>>> <#Localization> process. >>>> >>>> 6. Once the XLIFF file has been translated, then the placeholders >>>> are used to 'merge' the localized text with the skeleton file. >>>> 7. >>>> >>>> The xml:tm version of the target document can either be zipped >>>> and packed as a base-64 processing instruction into a version >>>> of the target document that has had the xml:tm namespace >>>> stripped out, or stored in the CMS <#CMS> system as a separate >>>> object. >>>> >>>> 8. >>>> >>>> The localized target version of the document is checked into >>>> the CMS <#CMS> system. >>>> >>>> 9. The leveraged translation-memory database is updated with the >>>> source and translated text-unit data. >>>> >>>> >>>> 3.2 OAXAL within a Localization-only Workflow >>>> >>>> TranslationOnlyFlow-noLegend >>>> >>>> *Figure 12: OAXAL Localization Only Workflow* >>>> >>>> Within a translation-only workflow <#Workflow>, the same basic >>>> steps apply: >>>> >>>> 1. Introduce the xml:tm namespace into the current source and any >>>> previous versions of the source and target documents. >>>> 2. Align the previous source and target xml:tm versions of the >>>> documents. >>>> 3. Compare the differences between the source versions at the >>>> xml:tm level. >>>> 4. Carry 'backwards' the unique xml:tm identifiers onto the >>>> previous source and target xml:tm versions of the documents >>>> 5. >>>> >>>> Produce the XLIFF version of the document, along with a >>>> skeleton file, by navigating through all of the xml:tm text >>>> units <#TU> in the document. In-Context Matching, which >>>> provides a higher quality of translation-memory matching, is >>>> achieved by using the translated text from the previous >>>> localized version of the document, by means of text-unit unique >>>> identifiers. The previous translated version of the document >>>> also allows for more focused leveraged-memory matching using >>>> the CRC <#CRC> keys for each text unit <#TU> as well as fuzzy >>>> matching based on modified text unit <#TU> identifiers. A >>>> skeleton file is created with placeholders where the >>>> translated text units <#TU> are to be placed. >>>> >>>> 6. >>>> >>>> Hand off the XLIFF file to the localization >>>> <#Localization> process. >>>> >>>> 7. Once the XLIFF file has been translated, then use the >>>> placeholders to 'merge' the localized text with the skeleton >>>> file. >>>> 8. Zip and pack the xml:tm version of the target document as a >>>> base-64 processing instruction into a version of the target >>>> document that has had the xml:tm namespace stripped out. >>>> 9. >>>> >>>> Update the leveraged translation-memory database with the >>>> source and translated text unit <#TU> data. >>>> >>>> >>>> 3.3 OAXAL Alternative Translation-only Workflow >>>> >>>> TranslationAlternativeOnlyFlow-noLegend >>>> >>>> *Figure 13: OAXAL Alternative Translation-only Workflow* >>>> >>>> An alternative translation-only workflow <#Workflow> is possible, >>>> without the use of the xml:tm namespace: >>>> >>>> 1. Using the W3C ITS Document Rules, extract the text into XLIFF >>>> format and create a skeleton file with placeholders for the >>>> translated text. >>>> 2. Segment the XLIFF translation units by using SRX and Unicode >>>> TR29. >>>> 3. Match the segmented XLIFF sentences by using traditional >>>> database matching. >>>> 4. >>>> >>>> Hand off the XLIFF file to the localization >>>> <#Localization> process. >>>> >>>> 5. Once the XLIFF file has been translated, then use the >>>> placeholders to 'merge' the localized text with the skeleton >>>> file, and into paragraphs. >>>> 6. Update the leveraged translation-memory database with the >>>> source and translated text-unit data from the segmented XLIFF >>>> file. >>>> >>>> >>>> 3.4 OAXAL Operations >>>> >>>> The OAXAL processes described in the above-mentioned use cases can >>>> be broken down into the following fundamental operations: >>>> >>>> 1. >>>> >>>> SEEDING - The introduction of the xml:tm namespace into a >>>> document. This operation involves /updating/ an XML document >>>> with the xml:tm namespace. The required standards used are >>>> Unicode TR29, SRX, and W3C ITS. The xml:tm namespace is used to >>>> allocate a unique identifier to each translatable sentence or >>>> individual translatable standalone text segment. These are >>>> referred to as text units <#TU>. The identifier is immutable >>>> for each text unit <#TU> for the lifespan of the document. >>>> SEEDING takes place in the following operations: >>>> >>>> 1. Check out for authoring, where no xml:tm version of the >>>> document exists >>>> 2. Check in from authoring, for the updated document >>>> 3. In the translation-only environment, for all relevant >>>> versions of the source and target documents >>>> 2. DIFFING - The comparison of the current and previous versions >>>> of a document, and maintaining the xml:tm namespace during the >>>> authoring lifecycle. For each update stage of a document, the >>>> original version of the document in its xml:tm form is >>>> required, as well as the updated version with a fresh xml:tm >>>> namespace. The two documents are compared, and any unchanged >>>> xml:tm text elements inherit the identifiers from the original >>>> version, thus maintaining the immutable identifiers. DIFFING >>>> takes place in the following operations: >>>> 1. Check in from authoring >>>> 2. Comparing current and previous versions of the source >>>> document in the translation-only environment >>>> 3. EXTRACTION - The creation of an XLIFF file and commensurate >>>> skeleton file, including document-centric matching based on the >>>> previous target and source versions of the document. Extraction >>>> takes place for all situations for the translation stage. >>>> 4. >>>> >>>> MERGING - The creation of the target version of the document, >>>> based on the translated XLIFF file and the skeleton file. The >>>> extraction process involves the identification of each >>>> translatable text unit <#TU>, transferring it to an XLIFF >>>> document, and replacing the text unit <#TU> with an identifier >>>> marking the location for the resultant translated text unit >>>> <#TU>. A skeleton file is thus created, with the placeholders >>>> for the translated text. The extraction process also involves >>>> extracting all translatable text and implementing all >>>> document-centered matching (ICE, leveraged, and fuzzy) as well >>>> as database matching, resulting in the creation of an XLIFF >>>> file along with a commensurate skeleton file. MERGING takes >>>> place for all situations for the translation stage. >>>> >>>> 5. PACKING - An optional stage that is used to pack the xml:tm >>>> version of the document into the existing document as a zipped, >>>> base-64 encoded processing instruction. PACKING takes place in >>>> the following operations: >>>> 1. Check out for authoring >>>> 2. Check in from authoring >>>> 3. Check in from translation >>>> 6. STRIPPING - The process of removing the xml:tm namespace from >>>> the document. Stripping takes place at all the major stages >>>> where a non-xml:tm version of the document is required. >>>> >>>> >>>> 3.4.1 SEEDING >>>> >>>> SEEDING >>>> >>>> *Figure 14: OAXAL xml:tm SEEDING* >>>> >>>> This operation involves /updating/ an XML document with the xml:tm >>>> namespace. The required standards used are Unicode TR29, SRX, and >>>> W3C ITS. The xml:tm namespace is used to allocate a unique >>>> identifier to each translatable sentence or individual >>>> translatable standalone text segment. These are referred to as >>>> text units <#TU>. The identifier is immutable for each text unit >>>> <#TU> for the lifespan of the document. >>>> >>>> The processing model for SEEDING is as follows: >>>> >>>> 1. Read in the W3C ITS document rules. >>>> 2. Read in the SRX segmentation rules for the language. >>>> 3. Read in the XML document. >>>> 4. Identify the elements and attributes containing translatable >>>> text. >>>> 5. Identify in-line elements and sub-flow elements. >>>> 6. >>>> >>>> Segment translatable text into individual text units <#TU>. >>>> >>>> 7. >>>> >>>> Allocate the following to each text unit <#TU>: >>>> >>>> 1. Unique identifiers >>>> 2. >>>> >>>> CRC <#CRC> signature >>>> >>>> 3. >>>> >>>> Text unit <#TU> classification: normal text, numeric, >>>> alphanumeric, measurement, and so on >>>> >>>> 8. Write out the newly seeded file. >>>> >>>> SEEDING takes place in the following operations: >>>> >>>> 1. Check out for authoring, where no xml:tm version of the >>>> document exists >>>> 2. Check in from authoring, for the updated document >>>> 3. In the translation-only environment, for all relevant versions >>>> of the source and target documents >>>> >>>> >>>> 3.4.2 DIFFING >>>> >>>> DIFFING >>>> >>>> *Figure 15: OAXAL DIFFING* >>>> >>>> For each update stage of a document, the original version of the >>>> document in its xml:tm form is required, as well as the updated >>>> version with a fresh xml:tm namespace. The two documents are >>>> compared, and any unchanged xml:tm text elements inherit the >>>> identifiers from the original version, thus maintaining the >>>> immutable identifiers. >>>> >>>> The processing model for DIFFING is as follows: >>>> >>>> 1. Locate the previous version of the document by either unpacking >>>> the previous xml:tm seeded version of the document or by >>>> locating it from storage. >>>> 2. SEED the current version with the xml:tm namespace. >>>> 3. Open and read in the previous and current seeded documents. >>>> 4. >>>> >>>> Compare the two documents to identify which text units >>>> <#TU> have not changed. >>>> >>>> 5. Carry over the previous unique identifiers to the new document. >>>> 6. >>>> >>>> Allocate new identifiers to new or modified text units <#TU>. >>>> For text units <#TU> that have changed, keep a note of the >>>> previous identifier to be used for in-document fuzzy matching. >>>> >>>> 7. Write out the updated file. >>>> >>>> DIFFING takes place in the following operations: >>>> >>>> 1. Check in from authoring >>>> 2. Comparing current and previous versions of the source document >>>> in the translation-only environment >>>> >>>> >>>> 3.4.3 EXTRACTION >>>> >>>> EXTRACTION >>>> >>>> *Figure 16: OAXAL EXTRACTION* >>>> >>>> The extraction process involves the identification of each >>>> translatable text unit <#TU>, transferring it to an XLIFF >>>> document, and replacing the text unit <#TU> with an identifier >>>> marking the location for the resultant translated text unit <#TU>. >>>> A skeleton file is thus created with the placeholders for the >>>> translated text. The extraction process also involves extracting >>>> all translatable text and implementing all document-centered >>>> matching (ICE, leveraged, and fuzzy) as well as database matching, >>>> resulting in the creation of an XLIFF file along with a >>>> commensurate skeleton file. >>>> >>>> The processing model for EXTRACTION is as follows: >>>> >>>> 1. Locate and read in the previous target xml:tm version of the >>>> document. >>>> 2. Read in the current updated source xml:tm version of the >>>> document. >>>> 3. Create the basic XLIFF document and the skeleton file based on >>>> the updated source xml:tm version of the document. >>>> 4. >>>> >>>> Process each text unit <#TU> in the updated source document >>>> (matching based on identifier) with the previous version, where >>>> possible. >>>> >>>> 5. >>>> >>>> Attempt in-document leveraged matching based on text unit >>>> <#TU> CRC <#CRC>. >>>> >>>> 6. >>>> >>>> Attempt in-document fuzzy matching based on previous >>>> identifiers in the case of modified text units <#TU>. >>>> >>>> 7. >>>> >>>> Where no other matching text unit <#TU> is found, attempt >>>> leveraged matching using traditional database-matching methods. >>>> >>>> If no database matching is attempted, then the whole extraction >>>> process can be implemented as an XSLT transformation. >>>> >>>> EXTRACTION takes place for all situations for the translation >>>> stage. >>>> >>>> >>>> 3.4.4 ALTERNATIVE EXTRACTION >>>> >>>> EXTRACTION-ALT >>>> >>>> *Figure 17: OAXAL ALTERNATIVE EXTRACTION* >>>> >>>> The alternative extraction process does not use xml:tm versions of >>>> the document and does not implement document-centric matching. It >>>> involves the identification of translatable text, segmenting the >>>> text into sentences, transferring the resultant text units <#TU> >>>> to an XLIFF document, and replacing the text units <#TU> with an >>>> identifier marking the location for the resultant translated text >>>> unit <#TU>. A skeleton file is thus created with placeholders for >>>> the translated text. The extraction process also involves >>>> extracting all translatable text and implementing all document- >>>> centered matching (ICE, leveraged, and fuzzy) as well as database >>>> matching, resulting in the creation of an XLIFF file along with a >>>> commensurate skeleton file. >>>> >>>> The processing model for EXTRACTION is as follows: >>>> >>>> 1. Read in the current updated source version of the document. >>>> 2. Identify translatable text by using W3C ITS document rules. >>>> 3. >>>> >>>> Attempt to segment the text into sentences (text units <#TU>) >>>> if possible. >>>> >>>> 4. Create the basic XLIFF document and the skeleton file, based on >>>> the source version of the document. >>>> 5. >>>> >>>> Attempt leveraged matching on each text unit <#TU> by using >>>> traditional database matching. >>>> >>>> If no database matching is attempted, then the whole extraction >>>> process can be implemented as an XSLT transformation. >>>> >>>> >>>> 3.4.5 MERGING >>>> >>>> MERGING >>>> >>>> *Figure 18: OAXAL MERGING* >>>> >>>> MERGING involves recreating the target file from the translated >>>> XLIFF file and original skeleton file. The translated text is >>>> 'merged' with the skeleton file, replacing the placeholders for >>>> the translated text. >>>> >>>> The processing model for MERGING is as follows: >>>> >>>> 1. Read in the skeleton file and translated XLIFF file. >>>> 2. >>>> >>>> Transfer the translated text units <#TU> into the appropriate >>>> placeholders in the skeleton file. >>>> >>>> The whole MERGING process can be implemented as an XSLT >>>> transformation. >>>> >>>> MERGING takes place once the translation has been completed. >>>> >>>> >>>> 3.4.6 PACKING >>>> >>>> PACKING >>>> >>>> *Figure 19: OAXAL PACKING* >>>> >>>> The processing model for PACKING is as follows: >>>> >>>> 1. Read in the xml:tm version of the document as a binary input >>>> stream. >>>> 2. Compress the input stream by using the gzip algorithm. >>>> 3. Base-64 encode the compressed file. >>>> 4. Insert the compressed base-64 encoded file as a processing >>>> instruction into the non-xml:tm namespace version of the >>>> document. >>>> >>>> An optional stage is used to pack the xml:tm version of the >>>> document into the existing document as a zipped, base-64 encoded >>>> processing instruction. PACKING takes place in the following >>>> operations: >>>> >>>> 1. Check out for authoring >>>> 2. Check in from authoring >>>> 3. Check in from translation >>>> >>>> >>>> 3.4.7 STRIPPING >>>> >>>> STRIPPING >>>> >>>> *Figure 20 OAXAL STRIPPING* >>>> >>>> STRIPPING is the process of removing the xml:tm namespace from the >>>> document. STRIPPING takes place at any stage that requires a non- >>>> xml:tm version of the document. >>>> >>>> The processing model for STRIPPING is as follows: >>>> >>>> 1. Read in the xml:tm version of the document. >>>> 2. Remove the xml:tm namespace components from the document. >>>> 3. Write out the non-xml:tm version of the document. >>>> >>>> The whole of the STRIPPING process can be implemented as an XSLT >>>> transformation. The result of this process is then suitable for >>>> output to a variety of output formats by using XSLT. >>>> >>>> >>>> >>>> 4 Conformance Guidelines >>>> >>>> The authors of this reference model envision that architects may >>>> wish to declare that their work is conformant with this reference >>>> model. Conforming to a reference model is not generally an easily >>>> automatable task, given that the reference model's role is >>>> primarily to define concepts that are important to OAXAL rather >>>> than to give guidelines for implementing systems. >>>> >>>> We do expect, however, that any given Service Oriented >>>> Architecture will reference the concepts outlined in this >>>> specification. As such, we expect that any design for a system >>>> that adopts the OAXAL approach will: >>>> >>>> * Implement the key Open Standards referenced herein >>>> * >>>> >>>> Follow the key OAXAL concepts and workflow <#Workflow> >>>> >>>> * Implement an Open and Unencumbered processing model, allowing >>>> for the free and easy interchange of data at any point in the >>>> processing cycle >>>> >>>> It is not appropriate for this specification to identify best >>>> practices with respect to building OAXAL-based systems. The ease >>>> with which the above elements can be identified within a given >>>> OAXAL-based system, however, could have significant impact on the >>>> scalability, maintainability, and ease of use of the system. >>>> >>>> >>>> 5 References >>>> >>>> >>>> 5.1 Normative >>>> >>>> [W3C ITS <http://www.w3.org/TR/2007/REC-its-20070403/>] >>>> Internationalization Tag Set (ITS) Version 1.0 http://www.w3.org/TR/2007/REC-its-20070403/ >>>> 03 April 2007 >>>> >>>> [SRX <http://www.lisa.org/Segmentation-Rules-e.40.0.html>] SRX 2.0 >>>> Specification http://www.lisa.org/Segmentation-Rules-e.40.0.html >>>> OSCAR Recommendation, 7 April 2008 >>>> >>>> [xml:tm <http://www.lisa.org/XML-Text-Memory-xml.107.0.html>] XML >>>> Text Memory (xml:tm) 1.0 Specification http://www.lisa.org/XML-Text-Memory-xml.107.0.html >>>> 26 February 2007 >>>> >>>> [GMX <http://www.lisa.org/Global-information-m.104.0.html>] Global >>>> Information Management Metrics Volume (GMX-V) 1.0 Specification http://www.lisa.org/Global-information-m.104.0.htmlVersion >>>> 1.0, 26 February 2007 >>>> >>>> [TMX <http://www.lisa.org/fileadmin/standards/tmx2/tmx.html>] >>>> Translation Memory eXchange format (TMX) Draft Specification http://www.lisa.org/fileadmin/standards/tmx2/tmx.html >>>> Version 2.0, October 15, 2007 >>>> >>>> [Unicode TR29 <http://unicode.org/reports/tr29/>] Unicode Standard >>>> Annex #29 http://unicode.org/reports/tr29/ Unicode 5.1.0 2008-03-25 >>>> >>>> [DITA <http://docs.oasis-open.org/dita/v1.1/CS01/overview/overview.html >>>>> ] Darwin Information Typing Architecture http://docs.oasis-open.org/dita/v1.1/CS01/overview/overview.html >>>> Verion 1.1 31 May 2007 >>>> >>>> [DocBook <http://www.oasis-open.org/apps/org/workgroup/docbook/>] >>>> DocBook http://www.docbook.org/specs/cs-docbook-docbook-4.2.pdf >>>> Committee Specification 4.2, 16 July 2002 >>>> >>>> [XHTML <http://www.w3.org/TR/xhtml11/>] XHTML(tm) 1.1 - Module- >>>> based >>>> XHTML - Second Edition http://www.w3.org/TR/xhtml11/ W3C Working >>>> Draft 16 February 2007 >>>> >>>> [SVG <http://www.w3.org/Graphics/SVG/>] Scalable Vector Graphics http://www.w3.org/TR/SVG12/ >>>> Working Draft 1.2 13 April 2005 >>>> >>>> [ODF <http://www.oasis-open.org/apps/org/workgroup/office/>] Open >>>> Document Format for Office Applications (OpenDocument) http://docs.oasis-open.org/office/v1.1/OS/OpenDocument-v1.1-html/OpenDocument-v1.1.html >>>> v1.1 1 Feb 2007 >>>> >>>> [XLIFF <http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xliff >>>>> ] XML Localization Interchange File Format (XLIFF) http://docs.oasis-open.org/xliff/v1.2/os/xliff-core.html >>>> Version 1.2 1 February 2008 >>>> >>>> >>>> 5.2 Non-Normative >>>> >>>> [LISA <http://www.lisa.org>] Localization Industry Standards >>>> Association >>>> >>>> [LISA OSCAR <http://www.lisa.org/Standards.79.0.html>] LISA Open >>>> Standards for Container/content Allowing Reuse >>>> >>>> [OASIS <http://www.oasis-open.org/home/index.php>] Organization >>>> for the Advancement of Structured Information Standards >>>> >>>> [W3C <http://www.w3.org>] The World Wide Web Consortium >>>> >>>> >>>> >>>> A. Glossary >>>> >>>> [CMS] - Content Managment System >>>> >>>> [CRC] AUTODIN II Polynomial Cyclical Redundancy Check singature >>>> for a byte sequence. Provides a unique 32-bit signature for a >>>> given byte sequence. >>>> >>>> [Localization] - Localization is the process of adapting a product >>>> or service to a particular language and culture. Translation >>>> usually forms a large part of localization, where the target >>>> language is different from the source language. >>>> >>>> [SCS] - Source Control System >>>> >>>> [Text Unit] - A text unit is either the complete text content of a >>>> document element or a subdivision of the same into identifiable >>>> sentences if possible. >>>> >>>> [Workflow] - Workflow is a term used to describe the tasks, >>>> procedural steps, organizations, or people involved; required >>>> input and output information; and tools needed for each step in a >>>> business process. >>>> >>>> >>>> B. Acknowledgments >>>> >>>> The following Technical Committees provided the constituent Open >>>> Standards for OAXAL: >>>> >>>> OASIS XML Localization Interchange File Format (XLIFF) TC <http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xliff >>>>> >>>> >>>> W3C Internationalization Tag Set (ITS) Working Group <http://www.w3.org/International/its/ >>>>> >>>> >>>> LISA OSCAR TC <http://www.lisa.org/OSCAR-LISA-s-Standa.79.0.html> >>>> >>>> Unicode Consortium <http://www.unicode.org/> >>>> >>>> The following individuals were members of the committee during the >>>> development of this specification and are gratefully acknowledged: >>>> >>>> Participants: >>>> >>>> Hackos, Dr. JoAnn, /Comtech Services, Inc./ >>>> >>>> Domeny, Mr. Doug, /Ektron/ >>>> >>>> Saldana, Mr. Derek, /Freescale Semiconductor, Inc./ >>>> >>>> Schnabel, Mr. Bryan (*secretary*), /Individual Member/ >>>> >>>> Lommel, Mr. Arle, /Localization Industry Standards Assoc. (LISA)/ >>>> >>>> Raya, Rodolfo (*secretary*), /Maxprograms/ >>>> >>>> McRae, Mary, /OASIS/ >>>> >>>> Jewtushenko, Mr. Tony, /Product Innovator Ltd./ >>>> >>>> Zydroń, Mr. Andrzej (*chair*), /XML-INTL/<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. >> >> >> <oaxal-spec.zip><azydron.vcf> > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]