Bryan, all, I hope to walk us all through the TBA changes (as marked in the comments tracker
https://wiki.oasis-open.org/xliff/XLIFF%202.0%20Public%20Review%20submitted%20comments%20tracker ) that are in the recent printout. This is the usual pdf link
https://tools.oasis-open.org/version-control/browse/wsvn/xliff/trunk/xliff-20/xliff-core.pdf and attached please find the html version of the same to facilitate individual browsing, when we are through the spec together. See you in 8 min dF Dr. David Filip ======================= LRC CNGL LT-Web CSIS University of Limerick, Ireland telephone: +353-6120-2781 cellphone: +353-86-0222-158 facsimile: +353-6120-2734
http://www.cngl.ie/profile/?i=452 mailto:
david.filip@ul.ie ---------- Forwarded message ---------- From: <
workgroup_mailer@lists.oasis-open.org > Date: Tue, Dec 17, 2013 at 3:18 PM Subject: [xliff] Version Control Commit by David.Filip To:
xliff@lists.oasis-open.org Author: David.Filip Date: 2013-12-17 15:18:55 +0000 (Tue, 17 Dec 2013) New Revision: 374 Web View:
https://tools.oasis-open.org/version-control/browse/wsvn/xliff/trunk/?rev=374&sc=1 Modified: trunk/PR02_CommentsDisposal/EndGame.xlsx trunk/PR02_CommentsDisposal/Initial_lowHangingFruits_Overview.txt trunk/xliff-20/attributes/subState.xml trunk/xliff-20/attributes/subType.xml trunk/xliff-20/attributes/type.xml trunk/xliff-20/extensions/extensions.xml trunk/xliff-20/inline/inline.xml trunk/xliff-20/xliff-core-v2.0-wd03.html trunk/xliff-20/xliff-core-v2.0-wd03.pdf trunk/xliff-20/xliff-core-v2.0-wd03.xml trunk/xliff-20/xliff-core.html trunk/xliff-20/xliff-core.pdf trunk/xliff-20/xliff-core.xml trunk/xliff-20/xliff20.xml Log: interim printout ------------------- Proposed changes for comments 107 118 119 120 126 135 137 143 144 implemented ----------------- Pending issues: fragemnt identification and uniqueness scopes BiDi mapping xml:land and xml:space inheritance xliff; prefix in slr --------------------------------------------------------------------- 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 Title: XLIFF Version 2.0 XLIFF Version 2.0 Working Draft 03 17 December 2013 Specification URIs This version:
http://docs.oasis-open.org/xliff/xliff-core/v2.0/wd03/xliff-core-v2.0-wd03.html (Authoritative)
http://docs.oasis-open.org/xliff/xliff-core/v2.0/wd03/xliff-core-v2.0-wd03.pdf http://docs.oasis-open.org/xliff/xliff-core/v2.0/wd03/xliff-core-v2.0-wd03.xml Previous version:
http://docs.oasis-open.org/xliff/xliff-core/v2.0/csprd02/xliff-core-v2.0-csprd02.html (Authoritative)
http://docs.oasis-open.org/xliff/xliff-core/v2.0/csprd02/xliff-core-v2.0-csprd02.pdf http://docs.oasis-open.org/xliff/xliff-core/v2.0/csprd02/xliff-core-v2.0-csprd02.xml Latest version:
http://docs.oasis-open.org/xliff/xliff-core/v2.0/xliff-core-v2.0.html (Authoritative)
http://docs.oasis-open.org/xliff/xliff-core/v2.0/xliff-core-v2.0.pdf http://docs.oasis-open.org/xliff/xliff-core/v2.0/xliff-core-v2.0.xml Technical Committee: OASIS XML Localisation Interchange File Format (XLIFF) TC Chair: Bryan Schnabel (
bryan.s.schnabel@tektronix.com ), Individual Editors: Tom Comerford (
tom@supratext.com ), Individual David Filip (
davidf@ul.ie ), Localisation Research Centre Rodolfo M. Raya (
rmraya@maxprograms.com ), Maxprograms Yves Savourel (
ysavourel@enlaso.com ), ENLASO Corporation Additional artifacts: This prose specification is one component of a Work Product that also includes: XML schemas accessible from
http://docs.oasis-open.org/xliff/xliff-core/v2.0/wd03/schemas/ Related Work: This specification replaces or supersedes: XLIFF Version 1.2. 1 February 2008. OASIS Standard.
http://docs.oasis-open.org/xliff/v1.2/os/xliff-core.html Declared XML Namespaces: urn:oasis:names:tc:xliff:document:2.0 urn:oasis:names:tc:xliff:matches:2.0 urn:oasis:names:tc:xliff:glossary:2.0 urn:oasis:names:tc:xliff:fs:2.0 urn:oasis:names:tc:xliff:metadata:2.0 urn:oasis:names:tc:xliff:resourcedata:2.0 urn:oasis:names:tc:xliff:changetracking:2.0 urn:oasis:names:tc:xliff:sizerestriction:2.0 urn:oasis:names:tc:xliff:validation:2.0 Abstract: This document defines version 2.0 of the XML Localisation Interchange File Format (XLIFF). The purpose of this vocabulary is to store localizable data and carry it from one step of the localization process to the other, while allowing interoperability between tools. Status: This document was last revised or approved by the OASIS XML Localisation Interchange File Format (XLIFF) TC on the above date. The level of approval is also listed above. Check the “Latest 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/xliff/ . 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/xliff/ipr.php ). Citation format: When referencing this specification the following citation format should be used: [ XLIFF v2.0 ] XLIFF Version 2.0 . 17 December 2013. OASIS Working Draft 03.
http://docs.oasis-open.org/xliff/xliff-core/v2.0/wd03/xliff-core-v2.0-wd03.html . Notices Copyright © OASIS Open 2013. 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 name OASIS is a trademark of OASIS , 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/policies-guidelines/trademark for above guidance. Table of Contents 1 Introduction 1.1 Terminology 1.1.1 Key words 1.1.2 Definitions 1.1.3 Key concepts 1.2 Normative References 1.3 Non-Normative References 2 Conformance 3 Fragment Identification 3.1 Identifying fragments within <target> elements 3.2 Fragments in XLIFF Modules and Extensions 3.3 External Identification 3.4 Internal Identification 4 The Core Specification 4.1 General Processing Requirements 4.2 Elements 4.2.1 Tree Structure 4.2.2 Structural Elements 4.2.3 Inline Elements 4.3 Attributes 4.3.1 XLIFF Attributes 4.3.2 XML namespace 4.4 CDATA sections 4.5 XML Comments 4.6 XML Processing Instructions 4.7 Inline Content 4.7.1 Text 4.7.2 Inline Codes 4.7.3 Annotations 4.7.4 Sub-Flows 4.7.5 White Spaces 4.7.6 Bidirectional Text 4.7.7 Target Content Modification 4.7.8 Content Comparison 4.8 Segmentation 4.8.1 Segments Representation 4.8.2 Segments Order 4.8.3 Segmentation Modification 4.9 Extension Mechanisms 4.9.1 Extension Points 4.9.2 Processing Requirements 5 The Modules Specifications 5.1 Translation Candidates Module 5.1.1 Introduction 5.1.2 Module Namespace 5.1.3 Module Fragment Identification Prefix 5.1.4 Module Elements 5.1.5 Module Attributes 5.1.6 Example: 5.1.7 XML Schema 5.2 Glossary Module 5.2.1 Introduction 5.2.2 Module Namespace 5.2.3 Module Fragment Identification Prefix 5.2.4 Module Elements 5.2.5 Module Attributes 5.2.6 Example: 5.2.7 XML Schema 5.3 Format Style Module 5.3.1 Introduction 5.3.2 Module Namespace 5.3.3 Module Fragment Identification Prefix 5.3.4 Module Specification 5.3.5 Module Attributes 5.3.6 XML Schema 5.4 Metadata Module 5.4.1 Introduction 5.4.2 Module Namespace 5.4.3 Module Fragment Identification Prefix 5.4.4 Module Elements 5.4.5 Module Attributes 5.4.6 Example: 5.4.7 XML Schema 5.5 Resource Data Module 5.5.1 Introduction 5.5.2 Module Namespace 5.5.3 Module Fragment Identification Prefix 5.5.4 Module Elements 5.5.5 Module Attributes 5.5.6 Examples: 5.5.7 XML Schema 5.6 Change Tracking Module 5.6.1 Introduction 5.6.2 Module Namespace 5.6.3 Module Fragment Identification Prefix 5.6.4 Module Elements 5.6.5 Module Attributes 5.6.6 Example: 5.6.7 XML Schema 5.7 Size and Length Restriction Module 5.7.1 Introduction 5.7.2 Module Namespace 5.7.3 Module Fragment Identification Prefix 5.7.4 Module Elements 5.7.5 Module Attributes 5.7.6 Standard profiles 5.7.7 Third party profiles 5.7.8 Conformance 5.7.9 Example 5.7.10 XML Schema 5.8 Validation Module 5.8.1 Introduction 5.8.2 Module Namespace 5.8.3 Module Fragment Identification Prefix 5.8.4 Module Elements 5.8.5 Module Attributes 5.8.6 Example: 5.8.7 XML Schema Appendixes A XML Schemas and Catalog Listings (Non-Normative) A.1 XML Schemas Tree A.2 XML Catalog A.3 Core XML Schema B Specification Change Tracking (Non-Normative) B.1 Tracking of changes made in response to Public Reviews B.1.1 Tracking of changes in response to the 2nd Public Review B.1.2 Tracking of changes in response to the 1st Public Review C Acknowledgements (Non-Normative) 1 Introduction XLIFF is the XML Localisation Interchange File Format designed by a group of software providers, localization service providers, and localization tools providers. It is intended to give any software provider a single interchange file format that can be understood by any localization provider. While the primary focus is on being a lossless interchange format, usage of XLIFF as a processing format is neither encouraged nor discouraged or prohibited. All text is normative unless otherwise labeled. 1.1 Terminology 1.1.1 Key words The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as described in [ RFC 2119 ]. 1.1.2 Definitions Agent any application or tool that generates (creates), reads, edits, writes, processes, stores, renders or otherwise handles XLIFF Documents . Agent is the most general application conformance target that subsumes all other specialized user agents disregarding whether they are defined in this specification or not. Enrich, Enriching the process of associating module and extension based metadata and resources with the Extracted XLIFF payload Processing Requirements Enriching MAY happen at the time of Extraction . Note Extractor knowledge of the native format is not assumed while Enriching . Extract, Extraction the process of encoding localizable content from a native content or User Interface format as XLIFF payload, so that localizable parts of the content in the source language are available for Translation into the target language along with the necessary context information Extractor, Extractor Agent any Agent that performs the Extraction process Merge, Merging the process of importing XLIFF payload back to the originating native format, based on the full knowledge of the Extraction mechanism, so that the localized content or User Interface strings replace the source language in the native format Merger, Merger Agent an Agent that performs the Merge process Warning Unless specified otherwise, any Merger is deemed to have the same knowledge of the native format as the Extractor throughout the specification. Mergers independent of Extractors can succeed, but it is out of scope of this specification to specify interoperability for Merging back without the full Extractor knowledge of the native format. Modify, Modification the process of changing core and module XLIFF structural and inline elements that were previously created by other Writers Processing Requirements XLIFF elements MAY be Modified and Enriched at the same time. Note Extractor or Enricher knowledge of the native format is not assumed while Modifying . Modifier, Modifier Agent an Agent that performs the Modification process Warning Unless specified otherwise, any Merger is deemed to have the same knowledge of the native format as the Extractor throughout the specification. Mergers independent of Extractors can succeed, but it is out of scope of this specification to specify interoperability for Merging back without the full Extractor knowledge of the native format. Translation, Translate a rendering of the meaning of the source text, expressed in the target language Writer, Writer Agent an Agent that creates, generates, or otherwise writes an XLIFF Document for whatever purpose, including but not limited to Extractor , Modifier , and Enricher Agents . Note Since XLIFF is intended as an exchange format rather than a processing format, many applications will need to generate XLIFF Documents from their internal processing formats, even in cases when they are processing XLIFF Documents created by another Extractor . 1.1.3 Key concepts XLIFF Core The core of XLIFF 2.0 consists of the minimum set of XML elements and attributes required to (a) prepare a document that contains text extracted from one or more files for localization, (b) allow it to be completed with the translation of the extracted text, and (c) allow the generation of Translated versions of the original document. The XML namespace that corresponds to the core subset of XLIFF 2.0 is urn:oasis:names:tc:xliff:document:2.0 . XLIFF-defined (elements and attributes) The following is the list of allowed schema URN prefixes for XLIFF-defined elements and attributes: urn:oasis:names:tc:xliff: However, the following namespaces are NOT considered XLIFF-defined for the purposes of the XLIFF 2.0 specification: urn:oasis:names:tc:xliff:document:1.0 urn:oasis:names:tc:xliff:document:1.1 urn:oasis:names:tc:xliff:document:1.2 Elements and attributes from other namespaces are not XLIFF-defined . XLIFF Document any XML document that declares the namespace urn:oasis:names:tc:xliff:document:2.0 as its main namespace, has <xliff> as the root element and complies with the XML Schemas and the declared Constraints that are part of this specification. XLIFF Module A module is an OPTIONAL set of XML elements and attributes that stores information about a process applied to an XLIFF Document and the data incorporated into the document as result of that process. Each official module defined for XLIFF 2.0 has its grammar defined in an independent XML Schema with a separate namespace. 1.2 Normative References [ BCP 47 ] M. Davis, Tags for Identifying Languages ,
http://tools.ietf.org/html/bcp47 IETF (Internet Engineering Task Force). [ HTML5 ] W3C, HTML5. A vocabulary and associated APIs for HTML and XHTML ,
http://www.w3.org/TR/html5/ W3C Candidate Recommendation 17 December 2012. [ NOTE-datetime ] M. Wolf, C. Wicksteed, Date and Time Formats ,
http://www.w3.org/TR/NOTE-datetime W3C Note, 15th Setember 1997. [ RFC 2119 ] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels ,
http://www.ietf.org/rfc/rfc2119.txt IETF (Internet Engineering Task Force) RFC 2119, March 1997. [ UAX #9 ] M. Davis, UNICODE BIDIRECTIONAL ALGORITHM ,
http://www.unicode.org/reports/tr9/ Unicode Bidirectional Algorithm. [ UAX #15 ] M. Davis, K. Whistler, UNICODE NORMALIZATION FORMS ,
http://www.unicode.org/reports/tr15/ Unicode Normalization Forms. [ Unicode ] The Unicode Consortium, The Unicode Standard ,
http://www.unicode.org/versions/latest/ Mountain View, CA: The Unicode Consortium, 2012. [ XML ] W3C, Extensible Markup Language (XML) 1.0 ,
http://www.w3.org/TR/xml/ (Fifth Edition) W3C Recommendation 26 November 2008. [ XML Schema Datatypes ] W3C, XML Schema Part 2: Datatypes ,
http://www.w3.org/TR/xmlschema-2/ (Second Edition) W3C Recommendation 28 October 2004. 1.3 Non-Normative References [ ITS ] MultilingualWeb-LT WG Internationalization Tag Set (ITS) Version 2.0 , 13 February 2008,
http://www.w3.org/TR/its20/ W3C Working Group. [ LDML ] Unicode Locale Data Markup Language
http://unicode.org/reports/tr35/ [ SRX ] Segmentation Rules eXchange
http://www.gala-global.org/oscarStandards/srx/ [ UAX #29 ] M. Davis, UNICODE TEXT SEGMENTATION ,
http://www.unicode.org/reports/tr29/ Unicode text Segmentation. [ XML I18N BP ] Best Practices for XML Internationalization , 13 February 2008,
http://www.w3.org/TR/xml-i18n-bp/ W3C Working Group. 2 Conformance Document Conformance XLIFF is an XML vocabulary, therefore conformant XLIFF Documents MUST be well formed and valid [XML] documents. Conformant XLIFF Documents MUST be valid instances of the official Core XML Schema that is part of this XLIFF specification. As not all aspects of the XLIFF specification can be expressed in terms of XML Schemas, conformant XLIFF Documents MUST also comply with all relevant elements and attributes definitions, normative usage descriptions, and Constraints specified in this specification document. XLIFF Documents MAY contain custom extensions, as defined in the Extension Mechanisms section. Application Conformance XLIFF Writers MUST create conformant XLIFF Documents to be considered XLIFF compliant. Agents processing conformant XLIFF Documents that contain custom extensions are not REQUIRED to understand and process non-XLIFF elements or attributes. However, conformant applications SHOULD preserve existing custom extensions when processing conformant XLIFF Documents , provided that the elements that contain custom extensions are not removed according to XLIFF Processing Requirements or the extension's own processing requirements. All Agents MUST comply with Processing Requirements for otherwise unspecified Agents or without a specifically set target Agent . Specialized Agents defined in this specification - this is Extractor , Merger , Writer , Modifier , and Enricher Agents - MUST comply with the Processing Requirements targeting their specifically defined type of Agent on top of Processing Requirements targeting all Agents as per point c. above. XLIFF is a format explicitly designed for exchanging data among various Agents . Thus, a conformant XLIFF application MUST be able to accept XLIFF Documents it had written after those XLIFF Documents were Modified or Enriched by a different application, provided that: The processed files are conformant XLIFF Documents , in a state compliant with all relevant Processing Requirements. Backwards Compatibility Conformant applications are NOT REQUIRED to support XLIFF 1.2 or previous Versions. 3 Fragment Identification Because XLIFF Documents do not follow the usual behavior of XML documents when it comes to element identifiers, this specification defines how Agents MUST interpret the fragment identifiers in URIs and IRIs pointing to XLIFF Documents . 3.1 Identifying fragments within <target> elements Since XLIFF Documents will often contain id values duplicate by design between source and target content, this fragment identification mechanism needs to specify a fragment identification prefix for referencing fragments enclosed by a <target> element. The target prefix is: /t . 3.2 Fragments in XLIFF Modules and Extensions XLIFF Module fragment identification prefixes are specified in the respective modules. Extensions that need to specify identifiable fragments, MUST specify their own fragment identification prefixes analogically to XLIFF Module prefixes. Constraints Module and extension fragment identification prefixes MUST start with the / character. The remaining part of the prefix MUST be an NMTOKEN at least 2 characters and at most 5 characters long. Extension prefixes MUST NOT compete for values with fragment identification prefix values specified or reserved within this specification. Modules and Extensions that need to be referenced from XLIFF Core or Modules MUST use an id attribute specified within their own namespace or the xlf:id attribute, whereas allowed id values MUST be compliant with appearing within URIs or IRIs. 3.3 External Identification When identifying an XLIFF fragment from outside the referenced XLIFF Document , the IRI MUST be composed from the following components in the given order: IRI of the referenced document with the xlf extension followed by the character # . If the fragment to be identified is within an XLIFF Module's or extension's element, the respective fragment identifying prefix followed by the ~ character followed by an id value unique within the relevant module or extension scope. If the fragment to be identified is at a lower level, the NMTOKEN string that is the value of the id attribute of the <file> element enclosing the fragment. If the fragment to be identified is within an XLIFF Module's or extension's element, the respective fragment identifying prefix followed by the ~ character followed by an id value unique within the relevant module or extension scope. If the fragment to be identified is at a lower level, character ~ followed by the NMTOKEN string that is the value of the id attribute of the lowermost <unit> or <group> element enclosing the fragment. If the fragment to be identified is within an XLIFF Module's or extension's element, the respective fragment identifying prefix followed by the ~ character followed by an id value unique within the relevant module or extension scope. If the fragment to be identified is at the lowest level and enclosed within a <target> element, prefix /t followed by the character ~ followed by the NMTOKEN string that is the value of the id attribute of the element to be identified. If the fragment to be identified is at the lowest level but not enclosed within a <target> element, character ~ followed by the NMTOKEN string that is the value of the id attribute of the element to be identified. 3.4 Internal Identification Referencing without context is always within the lowermost of the enclosing <unit> , <file>, or <xliff> element. Constraints When referencing an internal fragment of the same XLIFF Document , the fragment identifying string MUST be one of the following: The NMTOKEN string that is a value of one of the id attributes within the lowermost of the enclosing <unit> or <file> . A module prefix followed by the ~ character followed by an id value unique within the relevant module scope. A string composed as per steps 2. through 8. in the section External Identification . 4 The Core Specification XLIFF is a bilingual document format designed for containing text that needs Translation , its corresponding translations and auxiliary data that makes the Translation process possible. At creation time, an XLIFF file MAY contain only text in the source language. Translations expressed in the target language MAY be added at a later time. The root element of an XLIFF document is <xliff> . It contains a collection of <file> elements. Each <file> element contains a set of <unit> elements that contain the text to be translated in the <source> child of one or more <segment> elements. Translations are stored in the <target> child of each <segment> element. 4.1 General Processing Requirements An Agent processing a valid XLIFF Document that contains XLIFF-defined elements and attributes that it cannot handle MUST preserve those elements and attributes. An Agent processing a valid XLIFF Document that contains custom elements and attributes that it cannot handle SHOULD preserve those elements and attributes. 4.2 Elements This section contains a description of all elements used in XLIFF 2.0. 4.2.1 Tree Structure Legend: + = one or more ? = zero or one * = zero, one or more <xliff> +--- <file> + +--- <skeleton> ? +---<any> * +---<any> * +--- <notes> ? +--- <note> + +---At least one of ( <unit> or <group> ) 4.2.2 Structural Elements The structural elements used in XLIFF 2.0 are: <xliff> , <file> , <skeleton> , <group> , <unit> , <segment> , <ignorable> , <notes> , <note> , <originalData> , <data> , <source> and <target> . 4.2.2.1 xliff Root element for XLIFF documents. Contains: - One or more <file> elements Attributes: - version , REQUIRED - srcLang , REQUIRED - trgLang , OPTIONAL - attributes from other namespaces, OPTIONAL Constraints The trgLang attribute is REQUIRED if and only if the XLIFF Document contains <target> elements that are children of <segment> or <ignorable> . 4.2.2.2 file Container for localization material extracted from an entire single document, or another high level self contained logical node in a content structure that cannot be described in the terms of documents. Note Sub-document artifacts such as particular sheets, pages, chapters and similar are better mapped onto the <group> element. The <file> element is intended for the highest logical level. For instance a collection of papers would map to a single XLIFF Document , each paper will be represented with one <file> element, whereas chapters and subsections will map onto nested <group> elements. Contains: - Zero or one <skeleton> element followed by - Zero, one or more elements from other namespaces. - Zero or one <notes> element followed by - One or more <unit> or <group> elements in any order. Attributes: - id , REQUIRED - canResegment , OPTIONAL - original , OPTIONAL - translate , OPTIONAL - srcDir , OPTIONAL - trgDir , OPTIONAL - attributes from other namespaces, OPTIONAL Constraints The following XLIFF Module elements are explicitly allowed by the wildcard other : - Zero or one <ctr:changeTrack> elements - Zero or one <mda:metadata> elements - Zero, one or more <res:resourceData> elements - Zero or one <slr:profiles> elements - Zero or one <slr:data> elements - Zero or one <val:validation> elements Module and Extension elements MAY be used in any order. The following XLIFF Module attributes are explicitly allowed by the wildcard other : - fs:fs , OPTIONAL - fs:subFs , OPTIONAL - slr:storageRestriction , OPTIONAL - slr:sizeRestriction , OPTIONAL - slr:sizeInfo , OPTIONAL - slr:sizeInfoRef , OPTIONAL 4.2.2.3 skeleton Container for untranslatable material pertaining to the parent <file> element. Contains: Either - Untranslatable text - XML elements from any namespace or - is empty. Attributes: - href , OPTIONAL Constraints The attribute href is REQUIRED if and only if the <skeleton> element is empty. Processing Requirements Modifiers and Enrichers processing an XLIFF Document that contains a <skeleton> element MUST NOT change those elements. Extractors creating an XLIFF Document with a <skeleton> element MUST leave the <skeleton> element empty if and only if they specify the attribute href . 4.2.2.4 group Provides a way to organize units into a structured hierarchy. Note that this is especially useful for mirroring a source format's hierarchical structure. Contains: - Zero, one or more elements from other namespaces. - Zero or one <notes> element followed by - Zero, one or more <unit> or <group> elements in any order. Attributes: - id , OPTIONAL - name , OPTIONAL - canResegment , OPTIONAL - translate , OPTIONAL - srcDir , OPTIONAL - trgDir , OPTIONAL - type , OPTIONAL - attributes from other namespaces, OPTIONAL Constraints The following XLIFF Module elements are explicitly allowed by the wildcard other : - Zero or one <ctr:changeTrack> elements - Zero or one <mda:metadata> elements - Zero or one <slr:data> elements - Zero or one <val:validation> elements Module and Extension elements MAY be used in any order. The following XLIFF Module attributes are explicitly allowed by the wildcard other : - fs:fs , OPTIONAL - fs:subFs , OPTIONAL - slr:storageRestriction , OPTIONAL - slr:sizeRestriction , OPTIONAL - slr:sizeInfo , OPTIONAL - slr:sizeInfoRef , OPTIONAL 4.2.2.5 unit Static container for a dynamic structure of elements holding the extracted translatable source text, aligned with the Translated text. Contains: - Zero, one or more elements from other namespaces. - Zero or one <notes> elements followed by - Zero or one <originalData> element followed by - One or more <segment> or <ignorable> elements in any order. Attributes: - id , REQUIRED - name , OPTIONAL - canResegment , OPTIONAL - translate , OPTIONAL - srcDir , OPTIONAL - trgDir , OPTIONAL - type , OPTIONAL - attributes from other namespaces, OPTIONAL Constraints A <unit> MUST contain at least one <segment> element. The following XLIFF Module elements are explicitly allowed by the wildcard other : - Zero or one <ctr:changeTrack> elements - Zero or one <mtc:matches> elements - Zero or one <gls:glossary> elements - Zero or one <mda:metadata> elements - Zero, one or more <res:resourceData> elements - Zero or one <slr:data> elements - Zero or one <val:validation> elements Module and Extension elements MAY be used in any order. The following XLIFF Module attributes are explicitly allowed by the wildcard other : - fs:fs , OPTIONAL - fs:subFs , OPTIONAL - slr:storageRestriction , OPTIONAL - slr:sizeRestriction , OPTIONAL - slr:sizeInfo , OPTIONAL - slr:sizeInfoRef , OPTIONAL 4.2.2.6 segment This element is a container to hold in its aligned pair of children elements the minimum portion of translatable source text and its Translation in the given Segmentation . Contains: - One <source> element followed by - Zero or one <target> element Attributes: - id , OPTIONAL - canResegment , OPTIONAL - state , OPTIONAL - subState , OPTIONAL 4.2.2.7 ignorable Part of the extracted content that is not included in a segment (and therefore not translatable). For example tools can use <ignorable> to store the white space and/or codes that are between two segments. Contains: - One <source> element followed by - Zero or one <target> element Attributes: - id , OPTIONAL 4.2.2.8 notes Collection of comments. Contains: - One or more <note> elements 4.2.2.9 note This is an XLIFF specific way how to present end user readable comments and annotations. A note can contain information about <source> , <target> , <unit> , <group> , or <file> elements. Contains: - Text Attributes: - id , OPTIONAL - appliesTo , OPTIONAL - category , OPTIONAL - priority , OPTIONAL - attributes from other namespaces, OPTIONAL Constraints The following XLIFF Module attributes are explicitly allowed by the wildcard other : - fs:fs , OPTIONAL - fs:subFs , OPTIONAL 4.2.2.10 originalData Unit-level collection of original data for the inline codes. Contains: - One or more <data> elements 4.2.2.11 data Storage for the original data of an inline code. Contains: - Untranslatable text - Zero, one or more <cp> elements. Untranslatable text and <cp> elements MAY appear in any order. Attributes: - id , REQUIRED - dir , OPTIONAL 4.2.2.12 source Portion of text to be translated. Contains: - Text - Zero, one or more <cp> elements - Zero, one or more <ph> elements - Zero, one or more <pc> elements - Zero, one or more <sc> elements - Zero, one or more <ec> elements - Zero, one or more <mrk> elements - Zero, one or more <sm> elements - Zero, one or more <em> elements Text and inline elements may appear in any order. Attributes: - xml:lang , OPTIONAL - xml:space , OPTIONAL - dir , OPTIONAL Constraints When a <source> element is a child of <segment> or <ignorable> and the OPTIONAL xml:lang attribute is present, its value MUST be equal to the value of the srcLang attribute of the enclosing <xliff> element. 4.2.2.13 target The translation of the sibling <source> element. Contains: - Text - Zero, one or more <cp> elements - Zero, one or more <ph> elements - Zero, one or more <pc> elements - Zero, one or more <sc> elements - Zero, one or more <ec> elements - Zero, one or more <mrk> elements - Zero, one or more <sm> elements - Zero, one or more <em> elements Text and inline elements may appear in any order. Attributes: - xml:lang , OPTIONAL - xml:space , OPTIONAL - dir , OPTIONAL - order , OPTIONAL Constraints When a <target> element is a child of <segment> or <ignorable> and the OPTIONAL xml:lang attribute is present, its value MUST be equal to the value of the trgLang attribute of the enclosing <xliff> element. When a <target> child is added to a <segment> element, the value of its xml:space attribute MUST be set to preserve if the xml:space attribute of the sibling <source> element is set to preserve . 4.2.3 Inline Elements The inline elements at the <source> or <target> level are: <cp> , <ph> , <pc> , <sc> , <ec> , <mrk> , <sm> and <em> . The elements at the <unit> level directly related to inline elements are: <originalData> and <data> . 4.2.3.1 cp Represents a Unicode character that is invalid in XML. Contains: This element is always empty. Parents: <data> , <mrk> , <source> , <target> and <pc> Attributes: - hex , REQUIRED Example: <unit id= 1 > <segment> <source>Ctrl+C=<cp hex= 0003 /></source> </segment> </unit> The example above shows a character U+0003 (Control C) as it has to be represented in XLIFF. Processing Requirements Writers MUST encode all invalid XML characters of the content using <cp> . Writers MUST NOT encode valid XML characters of the content using <cp> . 4.2.3.2 ph Represents a standalone code of the original format. Contains: This element is always empty. Parents: <source> , <target> , <pc> and <mrk> Attributes: - canCopy , OPTIONAL - canDelete , OPTIONAL - canReorder , OPTIONAL - copyOf , OPTIONAL - disp , OPTIONAL - equiv , OPTIONAL - id , REQUIRED. - dataRef , OPTIONAL - subFlows , OPTIONAL - subType , OPTIONAL - type , OPTIONAL - attributes from other namespaces, OPTIONAL Example: <unit id= 1 > <segment> <source>Number of entries: <ph id= 1 dataRef= d1 /> <ph id= 2 dataRef= d2 />(These entries are only the ones matching the current filter settings)</source> </segment> <originalData> <data id= d1 >%d</data> <data id= d2 ><br/></data> </originalData> </unit> Constraints The following XLIFF Module attributes are explicitly allowed by the wildcard other : - fs:fs , OPTIONAL - fs:subFs , OPTIONAL - slr:equivStorage , OPTIONAL - slr:sizeInfo , OPTIONAL - slr:sizeInfoRef , OPTIONAL No other attributes MUST be used. 4.2.3.3 pc Represents a well-formed spanning original code. Contains: - Text - Zero, one or more <cp> elements - Zero, one or more <ph> elements - Zero, one or more <pc> elements - Zero, one or more <sc> elements - Zero, one or more <ec> elements - Zero, one or more <mrk> elements - Zero, one or more <sm> elements - Zero, one or more <em> elements Text and inline elements may appear in any order. Parents: <source> , <target> , <pc> and <mrk> Attributes: - canCopy , OPTIONAL - canDelete , OPTIONAL - canOverlap , OPTIONAL - canReorder , OPTIONAL - copyOf , OPTIONAL - dispEnd , OPTIONAL - dispStart , OPTIONAL - equivEnd , OPTIONAL - equivStart , OPTIONAL - id , REQUIRED - dataRefEnd , OPTIONAL - dataRefStart , OPTIONAL - subFlowsEnd , OPTIONAL - subFlowsStart , OPTIONAL - subType , OPTIONAL - type , OPTIONAL - dir , OPTIONAL - attributes from other namespaces, OPTIONAL Example: <unit id= 1 > <segment><pc id= 1 dataRefStart= 1 dataRefEnd= 2 >Important</pc> text</source> </segment> <originalData> <data><B></data> <data></B></data> </originalData> </unit> Constraints The following XLIFF Module attributes are explicitly allowed by the wildcard other : - fs:fs , OPTIONAL - fs:subFs , OPTIONAL - slr:storageRestriction , OPTIONAL - slr:sizeRestriction , OPTIONAL - slr:equivStorage , OPTIONAL - slr:sizeInfo , OPTIONAL - slr:sizeInfoRef , OPTIONAL No other attributes MUST be used. Processing Requirements Extractors MUST NOT use the <pc> element to represent standalone codes. Rationale: Using a spanning code for a standalone code can easily result in having text inside a span where the original format does not allow it. 4.2.3.4 sc Start of a spanning original code. Contains: This element is always empty. Parents : <source> , <target> , <pc> and <mrk> Attributes: - canCopy , OPTIONAL - canDelete , OPTIONAL - canOverlap , OPTIONAL - canReorder , OPTIONAL - copyOf , OPTIONAL - disp , OPTIONAL - equiv , OPTIONAL - id , REQUIRED - isolated , OPTIONAL - dataRef , OPTIONAL - subFlows , OPTIONAL - subType , OPTIONAL - type , OPTIONAL - dir , OPTIONAL - attributes from other namespaces, OPTIONAL Example: <unit id= 1 > <segment> <source><sc id= 1 type= fmt subType= xlf:b />First sentence. </source> </segment> <segment> <source>Second sentence.<ec startRef= 1 type= fmt subType= xlf:b /></source> </segment> </unit> Constraints The following XLIFF Module attributes are explicitly allowed by the wildcard other : - fs:fs , OPTIONAL - fs:subFs , OPTIONAL - slr:storageRestriction , OPTIONAL - slr:sizeRestriction , OPTIONAL - slr:equivStorage , OPTIONAL - slr:sizeInfo , OPTIONAL - slr:sizeInfoRef , OPTIONAL No other attributes MUST be used. The values of the attributes canCopy , canDelete , canReorder and canOverlap MUST be the same as the values the ones in the <ec> element corresponding to this start code. The attribute isolated MUST be set to yes if and only if the <ec> element corresponding to this start marker is not in the same <unit> , and set to no otherwise. Processing Requirements Extractors MUST NOT use the <sc> / <ec> pair to represent standalone codes. Rationale: Using a spanning code for a standalone code can easily result in having text inside a span where the original format does not allow it. 4.2.3.5 ec End of a spanning original code. Contains: This element is always empty. Parents: <source> , <target> , <pc> and <mrk> Attributes: - canCopy , OPTIONAL - canDelete , OPTIONAL - canOverlap , OPTIONAL - canReorder , OPTIONAL - copyOf , OPTIONAL - disp , OPTIONAL - equiv , OPTIONAL - id , OPTIONAL - isolated , OPTIONAL - dataRef , OPTIONAL - startRef , OPTIONAL - subFlows , OPTIONAL - subType , OPTIONAL - type , OPTIONAL - attributes from other namespaces, OPTIONAL Example: <unit id= 1 > <segment> <source>Text in <sc id= 1 dataRef= d1 />bold <sc id= 2 dataRef= d2 /> and<ec startRef= 1 dataRef= d3 /> italics<ec startRef= 2 dataRef= d4 />.</source> </segment> <originalData> <data id= d1 > </data> <data id= d2 >i </data> <data id= d3 >0 </data> <data id= d4 >i0 </data> </originalData> </unit> Constraints The following XLIFF Module attributes are explicitly allowed by the wildcard other : - fs:fs , OPTIONAL - fs:subFs , OPTIONAL - slr:equivStorage , OPTIONAL - slr:sizeInfo , OPTIONAL - slr:sizeInfoRef , OPTIONAL No other attributes MUST be used. The values of the attributes canCopy , canDelete and canOverlap MUST be the same as the values the ones in the <sc> element corresponding to this end code. The value of the attribute canReorder MUST be no if the value of canReorder is firstNo in the <sc> element corresponding to this end code. The attribute isolated MUST be set to yes if and only if the <sc> element corresponding to this end code is not in the same <unit> and set to no otherwise. If and only if the attribute isolated is set to yes , the attribute id MUST be used instead of the attribute startRef that MUST be used otherwise. Processing Requirements Extractors MUST NOT use the <sc> / <ec> pair to represent standalone codes. Rationale: Using a spanning code for a standalone code can easily result in having text inside a span where the original format does not allow it. 4.2.3.6 mrk Represents an annotation pertaining to the marked span. Contains: - Text - Zero, one or more <cp> elements - Zero, one or more <ph> elements - Zero, one or more <pc> elements - Zero, one or more <sc> elements - Zero, one or more <ec> elements - Zero, one or more <mrk> elements - Zero, one or more <sm> elements - Zero, one or more <em> elements Text and inline elements may appear in any order. Parents: <source> , <target> , <pc> and <mrk> Attributes: - id , REQUIRED - translate , OPTIONAL - type , OPTIONAL - ref , OPTIONAL - value , OPTIONAL - attributes from other namespaces, OPTIONAL Constraints The following XLIFF Module attributes are explicitly allowed by the wildcard other : - fs:fs , OPTIONAL - fs:subFs , OPTIONAL - slr:storageRestriction , OPTIONAL - slr:sizeRestriction , OPTIONAL See the Annotations section for more details and examples on how to use the <mrk> element. 4.2.3.7 sm Start marker of an annotation where the spanning marker cannot be used for wellformedness reasons. Contains: This element is always empty. Parents: <source> , <target> , <pc> and <mrk> Attributes: - id , REQUIRED - translate , OPTIONAL - type , OPTIONAL - ref , OPTIONAL - value , OPTIONAL - attributes from other namespaces, OPTIONAL Constraints The following XLIFF Module attributes are explicitly allowed by the wildcard other : - fs:fs , OPTIONAL - fs:subFs , OPTIONAL - slr:storageRestriction , OPTIONAL - slr:sizeRestriction , OPTIONAL See the Annotations section for more details and examples on how to use the <sm> element. 4.2.3.8 em End marker of an annotation where the spanning marker cannot be used for wellformedness reasons. Contains: This element is always empty. Parents: <source> , <target> , <pc> and <mrk> Attributes: - startRef , REQUIRED See the Annotations section for more details and examples on how to use the <em> element. 4.3 Attributes This section lists all the various attributes used in XLIFF core elements. 4.3.1 XLIFF Attributes The attributes defined in XLIFF 2.0 are: appliesTo , canCopy , canDelete , canOverlap , canReorder , canResegment , category , copyOf , dataRef , dataRefEnd , dataRefStart , dir , disp , dispEnd , dispStart , equiv , equivEnd , equivStart , hex , href , id , isolated , name , order , original , priority , ref , srcDir , srcLang , startRef , state , subFlows , subFlowsEnd , subFlowsStart , subState , subType , trgLang , translate , trgDir , type , value and version . 4.3.1.1 appliesTo Comment target - indicates the element to what the content of the note applies. Value description: source or target . Default value: undefined. Used in: <note> . 4.3.1.2 canCopy Replication editing hint - indicates whether or not the inline code can be copied. Value description: yes if the code can be copied, no if the code is not intended to be copied. Default value: yes . Used in: <pc> , <sc> , <ec> , <ph> . 4.3.1.3 canDelete Deletion editing hint - indicates whether or not the inline code can be deleted. Value description: yes if the code can be deleted, no if the code is not allowed to be deleted. Default value: yes . Used in: <pc> , <sc> , <ec> , <ph> . 4.3.1.4 canOverlap Code can overlap - indicates whether or not the spanning code where this attribute is used can enclose partial spanning codes (i.e. a start code without its corresponding end code, or an end code without its corresponding start code). Value description: yes or no . Default value: the default value for this attribute depends on the element in which it is used: When used in <pc> : no . When used in <sc> or <ec> : yes . Used in: <pc> , <sc> and <ec> Example: <unit id= 1 > <segment> <source><pc id= 1 dataRefStart= 3 dataRefEnd= 4 canOverlap= no />Bold, <sc id= 2 dataRef= 1 canOverlap= yes />both</pc>, italics<ec startRef= 2 dataRef= 2 /></source> </segment> <originalData> <data id= 1 >i1 </data> <data id= 2 >i0 </data> <data id= 3 >{ </data> <data id= 4 >}</data> </originalData> </unit> 4.3.1.5 canReorder Re-ordering editing hint - indicates whether or not the inline code can be re-ordered. See Editing Hints section for more details. Value description: yes in case the code can be re-ordered, firstNo when the code is the first element of a sequence that cannot be re-ordered, no when it is another element of such a sequence. Default value: yes . Used in: <pc> , <sc> , <ec> , <ph> . 4.3.1.6 canResegment Can resegment - indicates whether or not the source text in the scope of the given canResegment flag can be reorganized into a different structure of <segment> elements within the same parent <unit> . Value description: yes or no . Default value: default values for this attribute depend on the element in which it is used: When used in <file> : The value yes . When used in any other element: The value of the canResegment attribute of its parent element. Used in: <file> <group> <unit> , and <segment> . 4.3.1.7 category Category - provides a way to categorize notes. Value description: Text. Default value: undefined Used in: <note> . 4.3.1.8 copyOf Reference to base code - holds the id of the base code of a copied code. Value description: NMTOKEN. The id value of the base code of which this code is a copy. Default value: undefined Used in: <ph> , <pc> , <sc> , <ec> . Example: <unit id= 1 > <segment> <source>Äter <pc id= 1 >katter möss</pc>?</source> <target>Do <pc id= 1 >cats</pc> eat <pc id= 2 copyOf= 1 >mice</pc>?</target> </segment> </unit> 4.3.1.9 dataRef Original data reference - holds the identifier of the <data> element that contains the original data for a given inline code. Value description: An [XML Schema Datatypes] NMTOKEN that MUST be the value of the id attribute of one of the <data> element listed in the same <unit> element. Default value: undefined. Used in: <ph> , <sc> , <ec> . Example: <unit id= 1 > <segment> <source>Error in '<ph id= 1 dataRef= d1 />'.</source> <target>Erreur dans '<ph id= 1 dataRef= d1 />'.</target> </segment> <originalData> <data id= d1 >{0}</data> </originalData> </unit> The example above shows a <ph> element that has its original data stored outside the content, in a <data> element. 4.3.1.10 dataRefEnd Original data reference - holds the identifier of the <data> element that contains the original data for the end marker of a given inline code. Value description: An [XML Schema Datatypes] NMTOKEN that MUST be the value of the id attribute of one of the <data> element listed in the same <unit> element. Default value: undefined. Used in: <pc> . Example: <unit id= 1 > <segment> <source><pc id= 1 dataRefStart= d1 dataRefEnd= d2 >Efficiency<pc> is the operative word here.</source> <target><pc id= 1 dataRefStart= d1 dataRefEnd= d2 >Efficacité<pc> est le mot clé ici.</target> </segment> <originalData> <data id= d1 ><EM></data> <data id= d2 ></EM></data> </originalData> </unit> The example above shows two <pc> elements with their original data stored outside the content, in two <data> elements. 4.3.1.11 dataRefStart Original data reference - holds the identifier of the <data> element that contains the original data for the start marker of a given inline code. Value description: An [XML Schema Datatypes] NMTOKEN that MUST be the value of the id attribute of one of the <data> element listed in the same <unit> element. Default value: undefined. Used in: <pc> . Example: <unit id= 1 > <segment> <source><pc id= 1 dataRefStart= d1 dataRefEnd= d2 >Efficiency</pc> is the operative word here.</source> <target><pc id= 1 dataRefStart= d1 dataRefEnd= d2 >Efficacité</pc> est le mot clé ici.</target> </segment> <originalData> <data id= d1 ><EM></data> <data id= d2 ></EM></data> </originalData> </unit> The example above shows two <pc> elements with their original data stored outside the content, in two <data> elements. 4.3.1.12 dir Directionality - indicates the directionality of content. Value description: ltr (Left-To-Right) or rtl (Right-To-Left) Default value: default values for this attribute depend on the element in which it is used: When used in <source> : The value of the srcDir attribute of the <unit> element in which the unit is located. When used in <target> : The value of the trgDir attribute of the <unit> element in which the unit is located. When used in <