[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [oaxal] Re: OAXAL in OASIS XHTML format
Hi Andrzej,
Depending on the changes, believe it or not, it might be easier (better) to do it with a tool other than AI. Though I have the utmost respect for that tool, it puts lots of goop in the XML. And the SVG files I made are 100% true to the spec (and clean). If it's a matter of removing or changing text, that might be best done with a text editor. I can do it, if the changes were easy enough for me to spot.
Thanks,
Bryan
-----Original Message-----
From: Andrzej Zydron [mailto:azydron@xml-intl.com]
Sent: Thursday, April 02, 2009 10:13 AM
To: Schnabel, Bryan S
Cc: mary.mcrae@oasis-open.org; oaxal@lists.oasis-open.org
Subject: Re: [oaxal] Re: OAXAL in OASIS XHTML format
Hi Bryan,
Thank you for your kind offer. I will see what I can do to help. I may
have access to the latest version of Adobe Illustrator suite. I will be
able to report back tomorrow if I can pitch in.
Best Regards,
AZ
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
>
>
>
>
> ---------------------------------------------------------------------
> 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
>
>
--
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]