XLIFF Version 2.0

Committee Specification Draft 02 /
Public Review Draft 02

3 September 2013

Specification URIs
This 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
Previous version:
http://docs.oasis-open.org/xliff/xliff-core/v2.0/csprd01/xliff-core-v2.0-csprd01.html
http://docs.oasis-open.org/xliff/xliff-core/v2.0/csprd01/xliff-core-v2.0-csprd01.pdf
http://docs.oasis-open.org/xliff/xliff-core/v2.0/csprd01/xliff-core-v2.0-csprd01.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:

Related Work:

This specification replaces or supersedes:

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. 3 September 2013. OASIS Committee Specification Draft 02 / Public Review Draft 02. http://docs.oasis-open.org/xliff/xliff-core/v2.0/csprd02/csprd02/xliff-core-v2.0-csprd02.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 Detailed Specifications
2.1 General Processing Requirements
2.2 Elements
2.2.1 Tree Structure
2.2.2 Structural Elements
2.2.3 Inline Elements
2.3 Attributes
2.3.1 XLIFF Attributes
2.3.2 XML namespace
2.4 CDATA sections
2.5 XML Comments
2.6 XML Processing Instructions
2.7 Inline Content
2.7.1 Text
2.7.2 Inline Codes
2.7.3 Annotations
2.7.4 Sub-Flows
2.7.5 White Spaces
2.7.6 Bidirectional Text
2.7.7 Target Content Modification
2.7.8 Content Comparison
2.8 Extension Mechanisms
2.8.1 Extension Points
2.8.2 Processing Requirements
2.9 Segmentation
2.9.1 Segments Representation
2.9.2 Segments Order
2.9.3 Segmentation Modification - Resegmentation
3 Conformance

Appendixes

A XML Schemas and Catalog
A.1 XML Schemas Tree
A.2 XML Catalog
A.3 Core XML Schema
B Translation Candidates Module
B.1 Module Specification
B.1.1 Module Namespace
B.1.2 Module Elements
B.1.2.1 Tree Structure
B.1.2.2 matches
B.1.2.3 match
B.1.3 Module Attributes
B.1.3.1 id
B.1.3.2 similarity
B.1.3.3 matchQuality
B.1.3.4 matchSuitability
B.1.3.5 origin
B.1.3.6 type
B.1.3.7 subType
B.1.3.8 reference
B.1.4 Example:
B.1.5 XML Schema
C Glossary Module
C.1 Module Specification
C.1.1 Module Namespace
C.1.2 Module Elements
C.1.2.1 Tree Structure
C.1.2.2 glossary
C.1.2.3 glossentry
C.1.2.4 term
C.1.2.5 translation
C.1.2.6 definition
C.1.3 Module Attributes
C.1.3.1 id
C.1.3.2 source
C.1.4 Example:
C.1.5 XML Schema
D Format Style Module
D.1 Module Specification
D.1.1 Module Namespace
D.1.2 Module Attributes
D.1.2.1 fs
D.1.2.2 subFs
E Metadata Module
E.1 Module Specification
E.1.1 Module Namespace
E.1.2 Module Elements
E.1.2.1 Tree Structure
E.1.2.2 metadata
E.1.2.3 metagroup
E.1.2.4 meta
E.1.3 Module Attributes
E.1.3.1 category
E.1.3.2 type
E.1.3.3 appliesTo
E.1.4 Example:
E.1.5 XML Schema
F Resource Data Module
F.1 Module Specification
F.1.1 Module Namespace
F.1.2 Module Elements
F.1.2.1 Tree Structure
F.1.2.2 resourceData
F.1.2.3 resourceItemRef
F.1.2.4 resourceItem
F.1.2.5 source
F.1.2.6 target
F.1.2.7 reference
F.1.3 Module Attributes
F.1.3.1 id
F.1.3.2 xml:lang
F.1.3.3 mimeType
F.1.3.4 context
F.1.3.5 href
F.1.3.6 ref
F.1.4 Examples:
F.1.5 XML Schema
G Change Tracking Module
G.1 Module Specification
G.1.1 Module Namespace
G.1.2 Module Elements
G.1.2.1 Tree Structure
G.1.2.2 changeTrack
G.1.2.3 revisions
G.1.2.4 revision
G.1.2.5 item
G.1.3 Module Attributes
G.1.3.1 appliesTo
G.1.3.2 author
G.1.3.3 currentVersion
G.1.3.4 datetime
G.1.3.5 ref
G.1.3.6 property
G.1.3.7 version
G.1.4 Example:
G.1.5 XML Schema
H Size Restriction Module
H.1 Module Specification
H.1.1 Introduction
H.1.2 Module Namespace
H.1.3 Module Elements
H.1.3.1 Tree Structure
H.1.3.2 profiles
H.1.3.3 normalization
H.1.3.4 data
H.1.4 Module Attributes
H.1.4.1 storageProfile
H.1.4.2 generalProfile
H.1.4.3 storage
H.1.4.4 general
H.1.4.5 profile
H.1.4.6 storageRestriction
H.1.4.7 sizeRestriction
H.1.4.8 equivStorage
H.1.4.9 sizeInfo
H.1.4.10 sizeInfoRef
H.1.5 Standard profiles
H.1.5.1 General restriction profile ”xliff:codepoints”
H.1.5.2 Storage restriction profiles ”xliff:utf8”, ”xliff:utf16” and ”xliff:utf32”
H.1.6 Third party profiles
H.1.7 Conformance
H.1.8 Example
H.1.9 XML Schema
I Validation Module
I.1 Module Specification
I.1.1 Module Namespace
I.1.2 Module Elements
I.1.2.1 Tree Structure
I.1.2.2 validation
I.1.2.3 rule
I.1.3 Module Attributes
I.1.3.1 isPresent
I.1.3.2 occurs
I.1.3.3 isNotPresent
I.1.3.4 startsWith
I.1.3.5 endsWith
I.1.3.6 existsInSource
I.1.3.7 mustLoc
I.1.3.8 noLoc
I.1.3.9 caseSensitive
I.1.3.10 normalization
I.1.3.11 disabled
I.1.4 Example:
I.1.5 XML Schema
J Specification Change Tracking (Non-Normative)
J.1 Tracking of changes made in response to Public Reviews
J.1.1 Tracking of changes in response to the 1st Public Review
K 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.

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 processinmg 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.

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.

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 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 Detailed Specifications

XLIFF is a bilingual document format designed for containing text that needs translation, its corresponding translation and auxiliary data that makes the translation proccess possible.

At creation time, an XLIFF file MAY contain only text in source language. Translations expressed in 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.

2.1 General Processing Requirements

  • An Agent processing a valid XLIFF Document that contains XLIFF-defined elements that it cannot handle MUST preserve those elements.

  • An Agent processing a valid XLIFF Document that contains custom elements that it cannot handle SHOULD preserve those elements.

2.2 Elements

This section contains a description of all elements used in XLIFF 2.0.

2.2.1 Tree Structure

Legend:

1 = one
+ = one or more
? = zero or one
* = zero, one or more
<xliff>
|
+---<file> +
  |
  +---<skeleton> ?
  | |
  | +---<any> *
  |
  +---<notes> ?
  | |
  | +---<note> +
  |
  +---<mda:metadata> ?
  |
  +---<res:resourceData> *
  |
  +---<slr:profiles> ?
  |
  +---<slr:data> ?
  |
  +---<val:validation> ?
  |
  +---At least one of (<unit> or <group>)
  |
  +---<unit> 
  | |
  | +---At least one of (<segment> or <ignorable>)
  | |
  | +---<segment> 
  | | |
  | | +---<source> 1
  | | |
  | | +---<target> ?
  | |
  | +---<ignorable> 
  | | |
  | | +---<source> 1
  | | |
  | | +---<target> ?
  | |
  | +---<notes> ?
  | | |
  | | +---<note> +
  | |
  | +---<originalData> ?
  | | |
  | | +---<data> +
  | |   |
  | |   +---<cp> *
  | |
  | +---<mtc:matches> ?
  | |
  | +---<gls:glossary> ?
  | |
  | +---<mda:metadata> ?
  | |
  | +---<res:resourceData> *
  | |
  | +---<slr:data> ?
  | |
  | +---<val:validation> ?
  | |
  | +---<any> *
  |
  +---<group> 
  | |
  | +---At least one of (<unit> or <group>)
  | |
  | +---<unit> 
  | | |
  | | +---At least one of (<segment> or <ignorable>)
  | | |
  | | +---<segment> 
  | | | |
  | | | +---<source> 1
  | | | |
  | | | +---<target> ?
  | | |
  | | +---<ignorable> 
  | | | |
  | | | +---<source> 1
  | | | |
  | | | +---<target> ?
  | | |
  | | +---<notes> ?
  | | | |
  | | | +---<note> +
  | | |
  | | +---<originalData> ?
  | | | |
  | | | +---<data> +
  | | |   |
  | | |   +---<cp> *
  | | |
  | | +---<mtc:matches> ?
  | | |
  | | +---<gls:glossary> ?
  | | |
  | | +---<mda:metadata> ?
  | | |
  | | +---<res:resourceData> *
  | | |
  | | +---<slr:data> ?
  | | |
  | | +---<val:validation> ?
  | | |
  | | +---<any> *
  | |
  | +---<notes> ?
  | | |
  | | +---<note> +
  | |
  | +---<mda:metadata> ?
  | |
  | +---<slr:data> ?
  | |
  | +---<val:validation> ?
  | |
  | +---<any> *
  |
  +---<any> *

  

2.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>.

2.2.2.1 xliff

Root element for XLIFF documents.

Contains:

- One or more <file> elements

Attributes:

- version, REQUIRED
- srcLang, REQUIRED
- trgLang, OPTIONAL
- attributes from any namespace, OPTIONAL

Constraints

2.2.2.2 file

Container for localization material extracted from an entire single document, or another high level self cotained logical node in a conetnt structure that cannot be described in the terms of 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 or one <notes> element followed by
- Zero or one <mda:metadata> elements followed by
- Zero, one or more <res:resourceData> elements followed by
- Zero or one <slr:profiles> elements followed by
- Zero or one <slr:data> elements followed by
- Zero or one <val:validation> elements followed by
- One or more <unit> or <group> elements in any order followed by
- Zero, one or more elements from any namespace.

Attributes:

- id, OPTIONAL
- canResegment, OPTIONAL
- original, OPTIONAL
- translate, OPTIONAL
- srcDir, OPTIONAL
- trgDir, OPTIONAL
- fs:fs, OPTIONAL
- fs:subFs, OPTIONAL
- slr:storageRestriction, OPTIONAL
- slr:sizeRestriction, OPTIONAL
- slr:sizeInfo, OPTIONAL
- slr:sizeInfoRef, OPTIONAL
- attributes from any namespace, OPTIONAL

Constraints

  • The value of the OPTIONAL id attribute MUST be unique among all <file> children of the enclosing <xliff> element.

2.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 procesing an XLIFF Document that contains <skeleton> elements MUST NOT change those elements.

  • Extractors creating an XLIFF Document with <skeleton> elements MUST leave the <skeleton> element empty if and only if they specify the attribute href.

2.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:

- One or more <unit> or <group> elements in any order followed by
- Zero or one <notes> element followed by
- Zero or one <mda:metadata> elements followed by
- Zero or one <slr:data> elements followed by
- Zero or one <val:validation> elements followed by
- Zero, one or more elements from any namespace.

Attributes:

- id, OPTIONAL
- name, OPTIONAL
- canResegment, OPTIONAL
- translate, OPTIONAL
- srcDir, OPTIONAL
- trgDir, OPTIONAL
- fs:fs, OPTIONAL
- fs:subFs, OPTIONAL
- slr:storageRestriction, OPTIONAL
- slr:sizeRestriction, OPTIONAL
- slr:sizeInfo, OPTIONAL
- slr:sizeInfoRef, OPTIONAL
- attributes from any namespace, OPTIONAL
2.2.2.5 unit

Extracted translatable text.

Contains:

- One or more <segment> or <ignorable> elements in any order followed by
- Zero or one <notes> element followed by
- Zero or one <originalData> element followed by
- Zero or one <mtc:matches> element followed by
- Zero or one <gls:glossary> element followed by
- Zero or one <mda:metadata> elements followed by
- Zero, one or more <res:resourceData> elements followed by
- Zero or one <slr:data> elements followed by
- Zero or one <val:validation> elements followed by
- Zero, one or more elements from any namespace.

Attributes:

- id, REQUIRED
- name, OPTIONAL
- canResegment, OPTIONAL
- translate, OPTIONAL
- srcDir, OPTIONAL
- trgDir, OPTIONAL
- fs:fs, OPTIONAL
- fs:subFs, OPTIONAL
- slr:storageRestriction, OPTIONAL
- slr:sizeRestriction, OPTIONAL
- slr:sizeInfo, OPTIONAL
- slr:sizeInfoRef, OPTIONAL
- attributes from any namespace, OPTIONAL

Constraints

  • A <unit> MUST contain at least one <segment> element.

  • The value of the id attribute MUST be unique among all <unit> children of the enclosing <file> element.

2.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
- translate, OPTIONAL
- state, OPTIONAL
- subState, OPTIONAL

Constraints

2.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

Constraints

2.2.2.8 notes

Collection of comments.

Contains:

- One or more <note> elements

Attributes:

- fs:fs, OPTIONAL
- fs:subFs, OPTIONAL
2.2.2.9 note

A comment that contains information about <source>, <target>, <segment> or <unit> elements.

Contains:

- Text

Attributes:

- id, OPTIONAL
- appliestTo, OPTIONAL
- category, OPTIONAL
- priority, OPTIONAL
- attributes from any namespace, OPTIONAL
- fs:fs, OPTIONAL
- fs:subFs, OPTIONAL
2.2.2.10 originalData

Unit-level collection of original data for the inline codes.

Contains:

- One or more <data> elements

Attributes:

- fs:fs, OPTIONAL
- fs:subFs, OPTIONAL
2.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
- fs:fs, OPTIONAL
- fs:subFs, OPTIONAL

Constraints

  • The value of the id attribute MUST be unique among all <data> children of the enclosing <originalData> element.

2.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

2.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

2.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>.

2.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
- fs:fs, OPTIONAL
- fs:subFs, OPTIONAL

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>.

2.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
- fs:fs, OPTIONAL
- fs:subFs, OPTIONAL
- slr:equivStorage, OPTIONAL
- slr:sizeInfo, OPTIONAL
- slr:sizeInfoRef, 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">&lt;br/></data>
 </originalData>
</unit>
2.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
- fs:fs, OPTIONAL
- fs:subFs, OPTIONAL
- slr:storageRestriction, OPTIONAL
- slr:sizeRestriction, OPTIONAL
- slr:equivStorage, OPTIONAL
- slr:sizeInfo, OPTIONAL
- slr:sizeInfoRef, OPTIONAL

Example:

<unit id="1">
 <segment><pc id="1" dataRefStart="1" dataRefEnd="2">Important</pc> 
text</source>
 </segment>
 <originalData>
  <data>&lt;B&gt;</data>
  <data>&lt;/B&gt;</data>
 </originalData>
</unit>

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.

2.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
- fs:fs, OPTIONAL
- fs:subFs, OPTIONAL
- slr:storageRestriction, OPTIONAL
- slr:sizeRestriction, OPTIONAL
- slr:equivStorage, OPTIONAL
- slr:sizeInfo, OPTIONAL
- slr:sizeInfoRef, 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 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 when 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.

2.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
- fs:fs, OPTIONAL
- fs:subFs, OPTIONAL
- slr:equivStorage, OPTIONAL
- slr:sizeInfo, OPTIONAL
- slr:sizeInfoRef, 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">\b </data>
  <data id="d2">\i </data>
  <data id="d3">\b0 </data>
  <data id="d4">\i0 </data>
 </originalData>
</unit>

Constraints

  • The values of the attributes canCopy, canDelete, canReorder and canOverlap MUST be the same as the values the ones in the <sc> element corresponding to this end code.

  • The attribute isolated MUST be set to yes when the <sc> element corresponding to this end code is not in the same <unit> and set to no otherwise.

  • When the attribute isolated is set to yes, the attribute id MUST be used instead of the attribute startRef.

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.

2.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
- fs:fs, OPTIONAL
- fs:subFs, OPTIONAL
- slr:storageRestriction, OPTIONAL
- slr:sizeRestriction, OPTIONAL
- attributes from any namespace, OPTIONAL

See the Annotations section for more details and examples on how to use the <mrk> element.

2.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
- fs:fs, OPTIONAL
- fs:subFs, OPTIONAL
- slr:storageRestriction, OPTIONAL
- slr:sizeRestriction, OPTIONAL
- attributes from any namespace, OPTIONAL

See the Annotations section for more details and examples on how to use the <sm> element.

2.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.

2.3 Attributes

This section lists all the various attributes used in XLIFF core elements.

2.3.1 XLIFF Attributes

The attributes defined in XLIFF 2.0 are: appliesTo, canCopy, canDelete, canOverlap, canReorder, canResegment, category, copyOf, name, dataRef, dataRefEnd, dataRefStart, dir, disp, dispEnd, dispStart, equiv, equivEnd, equivStart, hex, href, id, isolated, original, order, original, priority, ref, startRef, srcDir, srcLang, subFlows, subFlowsEnd, subFlowsStart, subType, subState, state, trgLang, translate, trgDir, type, value and version.

2.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>.

2.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>.

2.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>.

2.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:

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">{\b </data>
  <data id="4">}</data>
 </originalData>
</unit>
2.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, no in case the code cannot be re-ordered.

Default value: yes.

Used in: <pc>, <sc>, <ec>, <ph>.

2.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>.

2.3.1.7 category

Category - provides a way to categorize notes.

Value description: Text.

Default value: undefined

Used in: <note>.

2.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>
2.3.1.9 dir

Deirectionality - 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 <pc>, or <sc>:

    The value of the dir attribute of the lowermost <source> , <target>, or <pc> element, in which the element in question is located.

  • When used in <data>:

    The value ltr.

Used in: <source>, <target>, <data>, <pc> and <sc>.

2.3.1.10 disp

Display text - holds an alternative user-friendly display representation of the original data of the inline code.

Value description: Text

Default value: undefined

Used in: <ph>, <sc>, <ec>.

Example:

<unit id="1">
 <segment>
  <source>Welcome back <ph id="1" disp="[UserName]" dataRef="d1"/>!</source>
 </segment>
 <originalData>
  <data id="d1">{1}</data>
 </originalData>
</unit>

Note

To provide a plain text equivalent of the code, use the equiv attribute.

2.3.1.11 dispEnd

Display text - holds an alternative user-friendly display representation of the original data of the end marker of an inline code.

Value description: Text

Default value: undefined

Used in: <pc>.

Example:

<unit id="1">
 <segment>
  <source>Example of <pc id="1" dataRefStart="d1" dataRefEnd="d2"
dispStart="&lt;span>" dispEnd="&lt;/span>">formatted
text</pc>.</source>
 </segment>
 <originalData>
  <data id="d1">\cf1\ul\b\f1\fs24 </data>
  <data id="d2">\cf0\ulnone\b0\f0\fs22 </data>
 </originalData>
</unit>

In the example above, the dispStart and dispEnd attributes provide a more user-friendly representation of the original formatting codes.

Note

To provide a plain text equivalent of the code, use the equivEnd attribute.

2.3.1.12 dispStart

Display text - holds an alternative user-friendly display representation of the original data of the start marker of an inline code.

Value description: Text

Default value: undefined

Used in: <pc>.

Example:

<unit id="1">
 <segment>
  <source>Example of <pc id="1" dataRefStart="d1" dataRefEnd="d2"
dispStart="&lt;span>" dispEnd="&lt;/span>">formatted
text</pc>.</source>
 </segment>
 <originalData>
  <data id="d1">\cf1\ul\b\f1\fs24 </data>
  <data id="d2">\cf0\ulnone\b0\f0\fs22 </data>
 </originalData>
</unit>

In the example above, the dispStart and dispEnd attributes provide a more user-friendly representation of the original formatting codes.

Note

To provide a plain text equivalent of the code, use the equivStart attribute.

2.3.1.13 equiv

Equivalent text - holds a plain text representation of the original data of the inline code that can be used when generating a plain text representation of the content.

Value description: Text

Default value: an empty string.

Used in: <ph>, <sc>, <ec>.

Example:

<unit id="1">
 <segment>
  <source>Open <ph id="1" equiv="" dataRef="d1"/>File</source>
 </segment>
 <originalData>
  <data id="d1">&amp;</data>
 </originalData>
</unit>

In this example the equiv attribute of the <ph> element is used to indicate that the original data of the code can be ignored in the text representation of the string. This could, for instance, help a spell-checker tool to process the content as "Open File".

Note

To provide a user-friendly representation, use the disp attribute.

2.3.1.14 equivEnd

Equivalent text - holds a plain text representation of the original data of the end marker of an inline code that can be used when generating a plain text representation of the content.

Value description: Text

Default value: an empty string

Used in: <pc>.

Example:

<unit id="1">
 <segment>
  <source>The jam made of <pc id="1" dataRefStart="d1" equivStart=""
dataRefEnd="d2" equivEnd="">lingonberries</pc> is quite tasty.</source>
 </segment>
 <originalData>
  <data id="d1">&lt;span class="link" onclick="linkTo('dbId5345')"></data>
  <data id="d2">&lt;/span></data>
 </originalData>
</unit>

Note

To provide a user-friendly representation, use the dispEnd attribute.

2.3.1.15 equivStart

Equivalent text - holds a plain text representation of the original data of the start marker of an inline code that can be used when generating a plain text representation of the content.

Value description: Text

Default value: an empty string

Used in: <pc>.

Example:

<unit id="1">
 <segment>
  <source>The jam made of <pc id="1" dataRefStart="d1" equivStart=""
dataRefEnd="d2" equivEnd="">lingonberries</pc> is quite tasty.</source>
 </segment>
 <originalData>
  <data id="d1">&lt;span class="link" onclick="linkTo('dbId5345')"></data>
  <data id="d2">&lt;/span></data>
 </originalData>
</unit>

Note

To provide a user-friendly representation, use the dispStart attribute.

2.3.1.16 hex

Hexadecimal code point - holds the value of a Unicode code point that is invalid in XML.

Value description: A canonical representation of the hexBinary [XML Schema Datatypes] data type: Two hexadecimal digits to represent each octet of the Unicode code point. The allowed values are any of the values representing code points invalid in XML, between hexadecimal 0000 and 10FFFF (both included).

Default value: undefined

Used in: <cp>.

Example:

<cp hex="001A"/><cp hex="0003"/>

The example above shows a character U+001A and a character U+0003 as they have to be represented in XLIFF.

2.3.1.17 href

href - a pointer to the location of an external skeleton file pertaining to the enclosing <file> element..

Value description: IRI.

Default value: undefined

Used in: <skeleton>.

2.3.1.18 id

Identifier - a character string used to identify an element.

Value description: NMTOKEN. The scope of the values for this attribute depend on the element, in which it is used

Default value: undefined

Used in: <file>, <unit>, <segment>, <ignorable>, <match>, <data>, <sc>, <ec>, <ph>, <pc>, <mrk> and <sm>.

2.3.1.19 isolated

Orphan code flag - indicates if the start or end marker of a spanning inline code is not in the same <unit> as its corresponding end or start code.

Value description: yes if this start or end code is not in the same <unit> as its corresponding end or start code, no if both codes are in the same <unit>.

Default value: no

Used in: <sc>, <ec>.

Example:

<unit id="1">
 <segment>
  <source><pc id="1">Warning: File not found.</pc></source>
 </segment>
 <mtc:matches>
  <mtc:match>
    <source><sc id="1" isolated="yes"/>Warning:</source>
    <target><sc id="1" isolated="yes"/>Attention :</target>
  </mtc:match>
 </match>
</unit>

In the example above the <sc> elements have their isolated attribute set to yes because they do not have their corresponding <ec> elements.

2.3.1.20 name

Resource name - the original identifier of the resource corresponding to the Extracted <unit> or <group>.

For example: the key in the key/value pair in a Java properties file, the ID of a string in a Windows string table, the index value of an entry in a database table, etc.

Value description: Text string.

Default value: undefined.

Used in: <unit> and <group>.

2.3.1.21 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.

2.3.1.22 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">&lt;EM></data>
  <data id="d2">&lt;/EM></data>
 </originalData>
</unit>

The example above shows two <pc> elements with their original data stored outside the content, in two <data> elements.

2.3.1.23 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">&lt;EM></data>
  <data id="d2">&lt;/EM></data>
 </originalData>
</unit>

The example above shows two <pc> elements with their original data stored outside the content, in two <data> elements.

2.3.1.24 order

target order - indicates the order, in which to compose the target content parts.

Value description: A positive integer.

Default value: undefined

Used in: <target>.

Constraints

  • The value of the order attribute MUST be unique within the enclosing <unit> element.

See the Segments Order section for the normative usage description.

2.3.1.25 original

Original file - a pointer to the location of the original document from which the content of the enclosing <file> element is extracted.

Value description: IRI.

Default value: undefined

Used in: <file>.

2.3.1.26 priority

Priority - provides a way to prioritize notes.

Value description: Integer 1-10.

Default value: 1

Used in: <note>.

Note

Please note that 1 is the highest priority that can be interpreted as an alert, e.g. an [ITS] Localization Note of the type alert. The best practice is to use only one alert per an annotated element, and the full scale of 2-10 can be used for prioritizing notes of lesser importance than the alert.

2.3.1.27 ref

Reference - holds a reference for the associated annotation.

Value description: A value of the [XML Schema Datatypes] type anyURI. The semantics of the value depends on the type of annotation:

Default value: undefined

Used in: <mrk> or <sm>.

Example:

<unit id="1">
 <segment>
  <source>The <pc id="1">ref</pc> attribute of a term 
annotation holds a <mrk id="m1" type="term" 
ref="http://dbpedia.org/page/Uniform_Resource_Identifier">URI</mrk>
pointing to more information about the given term.</source>
 </segment>
</unit>

Constraints

  • The value of the ref attribute SHOULD point to an element that is a child of the <unit> element where the parent of the attribute is located.

    Rationale: Pointing to an element located elsewhere is likley to prevent proper execution of Processing Requirements.

2.3.1.28 startRef

Start code or marker reference - The id of the <sc> element or the <sm> element a given <ec> element or <em> element corresponds.

Value description: NMTOKEN.

Default value: undefined

Used in: <ec>, <em>.

Example:

<unit id="1">
 <segment>
  <source><sc id="1"/>Bold, <sc id="2"/>both<ec startRef="1"/>,
italics<ec startRef="2"/></source>
 </segment>
</unit>
2.3.1.29 srcDir

Source directionality - indicates the directionality of the source 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 <file>:

    The value ltr.

  • When used in any other elements:

    The value of the srcDir attribute of its parent element.

Used in: <file>, <group>, and <unit>.

2.3.1.30 srcLang

Source language - the code of the language, in which the text to be Translated is expressed.

Value description: A language code as described in [BCP 47].

Default value: undefined

Used in: <xliff>.

2.3.1.31 subFlows

Sub-flows list - holds a list of id attributes corresponding to the <unit> elements that contain the sub-flows for a given inline code.

Value description: A list of NMTOKEN values separated by spaces. Each value corresponds to the id attribute of a <unit> element.

Default value: undefined

Used in: <ph>, <sc>, <ec>.

Example:

See the example in the Sub-Flows section.

2.3.1.32 subFlowsEnd

Sub-flows list - holds a list of id attributes corresponding to the <unit> elements that contain the sub-flows for the end marker of a given inline code.

Value description: A list of NMTOKEN values separated by spaces. Each value corresponds to the id attribute of a <unit> element.

Default value: undefined

Used in: <pc>.

Example:

See the example in the Sub-Flows section.

2.3.1.33 subFlowsStart

Sub-flows list - holds a list of id attributes corresponding to the <unit> elements that contain the sub-flows for the start marker of a given inline code.

Value description: A list of NMTOKEN values separated by spaces. Each value corresponds to the id attribute of a <unit> element.

Default value: undefined

Used in: <pc>.

Example:

See the example in the Sub-Flows section.

2.3.1.34 subType

subType - indicates the secondary level type of an inline code.

Value description:

The value is composed of a prefix and a sub-value separated by a character : (U+003A).

The prefix is a string uniquely identifying a collection of values for a specific authority. The sub-value is any string value defined by the authority.

The prefix xlf is reserved for this specification, and the following sub-values are defined:

xlf:lb - Line break
xlf:pb - Page break
xlf:b - Bold
xlf:i - Italics
xlf:u - Underlined
xlf:var - Variable

Other prefixes and sub-values MAY be defined by the users.

Default value: undefined

Used in: <pc>, <sc>, <ec> and <ph>

Constraints

  • If the attribute subType is used, the attribute type MUST be specified as well.

Processing Requirements

  • Writers updating the attribute type MUST also update or delete subType.

2.3.1.35 subState

subState - indicates a user-defined status for the <segment> element.

Value description:

The value is composed of a prefix and a sub-value separated by a character : (U+003A).

The prefix is a string uniquely identifying a collection of values for a specific authority. The sub-value is any string value defined by an authority.

The prefix xlf is reserved for this specification.

Other prefixes and sub-values MAY be defined by the users.

Default value: undefined

Used in: <segment>

Constraints

  • If the attribute subState is used, the attribute state MUST be specified as well.

Processing Requirements

  • Writers updating the attribute state MUST also update or delete subState.

2.3.1.36 state

Type - indicates the state of the translation of a segment.

Value description: The value MUST be set to one of the following values:

initial - indicates the segment is in its initial state.
translated - indicates the segment has been translated.
reviewed - indicates the segment has been reviewed.
final - indicates the segment is finalized and ready to be used.

One can further specify the state of the Translation using the subState attribute.

Default value: initial

Used in: <segment>

Processing Requirements

  • Writers updating the attribute state MUST also update or delete subState.

2.3.1.37 trgLang

Target language - the code of the language, in which the Translated text is expressed.

Value description: A language code as described in [BCP 47].

Default value: undefined

Used in: <xliff>.

2.3.1.38 translate

Translate - indicates whether or not the source text in the scope of the given translate flag is intended for Translation.

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 admissible structural element:

    The value of the translate attribute of its parent element.

  • When used in annotations markers <mrk> or <sm>:

    The value of the translate attribute of the lowermost <mrk> or <segment> elment, in which the marker in question is located.

Used in: <file> <group> <unit>, <segment>, and <mrk> and <sm>.

2.3.1.39 trgDir

Target directionality - indicates the directionality of the target 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 <file>:

    The value ltr.

  • When used in any other elements:

    The value of the trgDir attribute of its parent element.

Used in: <file>, <group>, and <unit>.

2.3.1.40 type

Type - indicates the type of an element.

Value description: allowed values for this attribute depend on the element, in which it is used.

  • When used in <pc>, <sc>, <ec> or <ph>:

    The value MUST be set to one of the following values:

    fmt - Formatting (e.g. a <b> element in HTML)
    ui - User interface element
    quot - Inline quotation
    link - Link (e.g. an <a> element in HTML)
    image - Image or graphic
    other - Type of element not covered by any of the other top-level types.

    One can further specify the type of a code using the subType attribute.

    Default value: Undefined

  • When used in <mrk> or <sm>:

    One of the following values: generic, comment, term, match, or a user-defined value that is composed of a prefix and a value separated by a character : (U+003A).

    Default value: generic

Used in: <pc>, <sc>, <ec>, <mrk> and <ph>

Processing Requirements

  • Writers updating the attribute type MUST also update or delete subType.

2.3.1.41 value

Value - holds a value for the associated annotation.

Value description: Text.

Default value: undefined

Used in: <mrk> and <sm>.

2.3.1.42 version

XLIFF Version - is used to specify the Version of the XLIFF Document. This corresponds to the Version number of the XLIFF specification that the XLIFF Document adhers to.

Value description: Text.

Default value: 2.0

Used in: <xliff>.

2.3.2 XML namespace

The attributes from XML namespace used in XLIFF 2.0 are xml:lang and xml:space.

2.3.2.1 xml:lang

Language - the xml:lang attribute specifies the language variant of the text of a given element. For example: xml:lang="fr-FR" indicates the French language as spoken in France.

Value description: A language code as described in [BCP 47].

Default value: undefined

Used in: <source>, <target>.

2.3.2.2 xml:space

White spaces - the xml:space attribute specifies how white spaces (ASCII spaces, tabs and line-breaks) are ti be treated.

Value description: default or preserve. The value default signals that an application's default white-space processing modes are acceptable for this element; the value preserve indicates the intent that applications preserve all the white space. This declared intent is considered to apply to all elements within the content of the element where it is specified, unless overridden with another instance of the xml:space attribute. For more information see the section on xml:space in the XML specification.

Default value: default

Used in: <source>, <target>.

2.4 CDATA sections

CDATA sections (<![CDATA[...]]>) are allowed in XLIFF content, but on output they MAY be changed into normal escaped content.

Note that avoiding CDATA sections is considered a best practice from the internationalization viewpoint [XML I18N BP].

Processing Requirements

  • Agents MUST process CDATA sections.

  • Writers MAY preserve the original CDATA sections.

2.5 XML Comments

XML comments (<!--...--!>) are allowed in XLIFF content, but they are ignored in the parsed content.

For example:

<source>Text content <!--IMPORTANT-->that is important</source>

and

<source>Text content that is important</source>

are identical after parsing and correspond to the same following parsed content:

Text content that is important

To annotate a section of the content with a comment that is recognized and preserved by XLIFF user agents, use the <note> element, or the <mrk> element.

Processing Requirements

  • Agents MUST ignore XML comments. That is the XLIFF parsed content is the same whether or not there is an XML comment in the document.

  • Writers MAY preserve XML comments on output.

2.6 XML Processing Instructions

XML Processing Instructions [XML] (see specifically http://www.w3.org/TR/REC-xml/#sec-pi) are an XML mechanism to "allow documents to contain instructions for applications." XML Processing Instructions are allowed in XLIFF content but they are ignored in the parsed content in the same sense as XML Comments.

Processing Requirements

  • Agents MUST NOT use Processing Instructions as a means to implement a feature already specified in XLIFF core or modules.

  • Writers SHOULD preserve XML Processing Instructions in an XLIFF Document.

Warning

Please note that Agents using Processing Instruction to implenmet XLIFF Core or Module fetaures are not compliant XLIFF applications disregaring wheteher they are otherwise conformant.

Warning

Although this specification encourages XLIFF Agents to preserve XML Processing Instructions, it is not and cannot be, for valid processing reasons, an absolute protection and it is for instance highly unlikely that Processing Instructions could survive an XLIFF roundtrip at the <segment> level or lower. Hence implementers are dsicouraged from using XML Processing Instructions at the <segment> and lower levels.

2.7 Inline Content

The XLIFF inline content defines how to encode the content Extracted from the original source. The content includes the following types of data:

  • Text -- Textual content.

  • Inline codes -- Sequences of content that are not linguistic text, such as formatting codes, variable placeholders, etc.

    For example: the element <b> in HTML, or the placeholder {0} in a Java string.

  • Annotations -- Markers that delimit a span of the content and carry or point to information about the specified content.

    For example: a flag indicating that a given section of text is not intended for translation, or an element indicating that a given expression in the text is a term associated with a definition.

There are two elements that contain inline markup in XLIFF: <source> and <target>.

In some cases, data directly associated with inline elements MAY also be stored at the <unit> level in an <originalData> element.

2.7.1 Text

The XLIFF inline markup does not prescribe how to represent normal text, besides that it MUST be valid XML.

2.7.1.1 Characters invalid in XML

Because the content represented in XLIFF can be extracted from anywhere, including software resources and other material that can contain control characters, XLIFF needs to be able to represent all Unicode code points [Unicode].

However, XML does not have the capability to represent all Unicode code points [Unicode], and does not provide any official mechanism to escape the forbidden code points.

To remedy this, the inline markup provides the <cp> element.

The syntax and semantic of <cp> in XLIFF are similar to the ones of <cp> in the Unicode Locale Data Markup Language [LDML].

2.7.2 Inline Codes

The specification takes into account two types of codes:

Original code

An original code is a code that exists in the original document being extracted into XLIFF.

Added code

An added code is a code that does not exist in the original document, but has been added to the content at some point after extraction.

Any code (original or added) belongs to one of the two following categories:

Standalone

A standalone code is a code that corresponds to a single position in the content. An example of such code is the <br/> element in HTML.

Spanning

A spanning code is a code that encloses a section of the content using a start and an end marker. There are two kinds of spanning codes:

  • Codes that can overlap, that is: they can enclose a non-closing or a non-opening spanning code. Such codes do not have an XML-like behavior. For example the RTF code \b1...\b0 is a spanning code that is allowed to overlap.

  • Codes that MUST NOT overlap, that is: they cannot enclose a partial spanning code and have an XML-like behavior at the same time. An example of such code is the <emphasis>...</emphasis> element in DocBook.

When the opening or closing marker of a spanning code does not have its corresponding closing or opening marker in the same unit, it is an orphan code.

2.7.2.1 Representation of the codes

Spanning codes present a set of challenges in XLIFF:

First, because the code format of the original data extracted to XLIFF does not need to be XML, spanning codes can overlap.

For example, in the following RTF content, the format markers are in a sequence: start bold, start italics, end bold, end italics. This does not translate into a well-formed mapping.

Text in \b bold \i and\b0  italics\i0

Another challenge is the possible effect of segmentation: A spanning code can start in one segment and end in another.

For example, in the following HTML content, the segmentation splits the text independently of the codes so the starting and ending tags of the <B>...</B> element end up in different parts of the <unit> element:

[Sentence <B>one. ][Sentence two.][ ][Sentence</B> three.]

Finally, a third potential cause of complication is that the start or the end markers of a spanning code can become orphans if their segment is used outside of its original <unit>.

For example, an entry with bold text can be broken down into two segments:

Segment 1 = "<b>Warning found: "
Segment 2 = "The file is read-only</b>"

And later, one of the segments can be re-used outside its original <unit>, for instance as a translation candidate:

New segment = "<b>Warning found - see log</b>"
Fuzzy match = "<b>Warning found: "

Because of these use cases, the representation of a spanning code cannot always be mapped to a similar spanning element in XLIFF.

When taking into account these issues, the possible use cases and their corresponding XLIFF representations are as follow:

Table 1. Inline code use cases

Use CaseExample of Representation
Standalone code<ph id='1'/>
Well-formed spanning code<pc id='1'>text</pc>
Start marker of spanning code<sc id='1'/>
End marker of spanning code<ec startRef='1'/>
Orphan start marker of spanning code<sc id='1' isolated='yes'/>
Orphan end marker of spanning code<ec id='1' isolated='yes'/>
2.7.2.2 Usage of <pc> and <sc>/<ec>

A spanning code MUST be represented using a <sc> element and a <ec> element if the code is not well-formed or orphan.

For example, the following RTF content has two spans of formatting:

Text in \b bold \i and\b0  italics\i0

They can only be represented using two pairs of <sc> and <ec> elements:

Text in <sc id="1">\b </sc>bold
 <sc id="2">\i </sc>and<ec startRef="1">\b0 </ec> italics<ec startRef="2">\i0</ec>

If the spanning code is well-formed it MAY be represented using either a single <pc> element or using a pair of <sc> and a <ec> elements.

For example, the following RTF content has a single span of formatting:

Text in \b bold\b0 .

It can be represented using either notations:

Text in <pc id="1" canOverlap="yes" dataRefStart="c1" dataRefEnd="c2">bold</pc>.
Text in <sc id="1" dataRef="c1"/>bold<ec startRef="1" dataRef="c2"/>.

Processing Requirements

  • When both the <pc> and the <sc>/<ec> representations are possible, Extractors and Modifiers MAY use either one as long as all the information of the inline code (e.g. original data, sub-flow indicators, etc.) are preserved.

  • When converting representation between a pair of <sc> and <ec> elements and a <pc> element or vice-versa, Modifiers MUST map their attributes as shown in the following table:

    Table 2. Mapping between attributes

    <pc> attributes<sc> attributes<ec> attributes
    ididstartRef / id
    typetypetype
    dispStartdisp 
    dispEnd disp
    equivStartequiv 
    equivEnd equiv
    subFlowsStartsubFlows 
    subFlowsEnd subFlows
    dataRefStartdataRef 
    dataRefEnd dataRef
     isolatedisolated
    canCopycanCopycanCopy
    canDeletecanDeletecanDelete
    canReordercanReordercanReorder
    copyOfcopyOfcopyOf
    canOverlapcanOverlapcanOverlap
    dirdir 
  • Agents MUST be able to handle any of the above two types of inline code representation.

2.7.2.3 Storage of the original data

Most of the time, inline codes correspond to an original construct in the format from which the content was extracted. This is the original data.

XLIFF tries to abstract and normalize as much as possible the extracted content because this allows a better re-use of the material across projects. Some tools require access to the original data in order to create the translated document back into its original format. Others do not.

2.7.2.3.1 No storage of the original data

In this option, the original data of the inline code is not preserved inside the XLIFF document.

The tool that created the initial XLIFF document is responsible for providing a way to re-create the original format properly when merging back the content.

For example, for the following HTML content:

This <B>naked mole rat</B> is <B>pretty ugly</B>.

one possible XLIFF representation is the following:

<unit id="1">
 <segment>
  <source>This <pc id="1">naked mole rat</pc>
is <pc id="2">pretty ugly</pc>.</source>
  <target>Cet <pc id="1">hétérocéphale</pc>
est <pc id="2">plutôt laid</pc>.</target>
 </segment>
</unit>
2.7.2.3.2 Storage of the original data

In this option, the original data of the inline code is stored in a structure that resides outside the content (i.e. outside <source> or <target>) but still inside the <unit> element.

The structure is an element <originalData> that contains a list of <data> entries uniquely identified within the <unit> by an id attribute. In the content, each inline code using this mechanism includes a dataRef attribute that points to a <data> element where its corresponding original data is stored.

For example, for the following HTML content:

This <B>naked mole rat</B> is <B>pretty ugly</B>.

The following XLIFF representation stores the original data:

<unit id="1">
 <segment>
  <source>This <pc id="1" dataRefStart="d1" dataRefEnd="d2">naked mole rat</pc>
is <pc id="2" dataRefStart="d1" dataRefEnd="d2">pretty ugly</pc>.</source>
  <target>Cet <pc id="1" dataRefStart="d1" dataRefEnd="d2">hétérocéphale</pc>
est <pc id="2" dataRefStart="d1" dataRefEnd="d2">plutôt laid</pc>.</target>
 </segment>
 <originalData>
  <data id="d1">&lt;B></data>
  <data id="d2">&lt;/B></data>
 </originalData>
</unit>

Note

This mechanism allows to re-use identical original data by pointing to the same <data> element.

2.7.2.4 Adding Codes

When processing a content, there are possible cases when new inline codes need to be added.

For example, in the following HTML help content, the text has the name of a button in bold:

Press the <b>Emergency Stop</b> button
to interrupt the count-down sequence.

In the translated version, the original label needs to remain in English because the user interface, unlike the help, is not translated. However, for convenience, a translation is also provided and emphasized using another style. That new formatting needs to be added:

Appuyez sur le bouton <b>Emergency Stop</b> (<i>Arrêt d'urgence</i>)
pour interrompre le compte à rebours.

Having to split a single formatted span of text into several separate parts during translation, can serve as another example. For instance, the following sentence in Swedish uses bold on the names of two animals:

Äter <b>katter möss</b>?

But the English translation separates the two names and therefore needs to duplicate the bold codes.

Do <b>cats</b> eat <b>mice</b>?

Processing Requirements

  • Modifiers MAY add inline codes.

  • The id value of the added code MUST be different from all id values in both source and target content of the unit where the new code is added.

  • Mergers MAY ignore added inline codes when Merging the Translated content back into the original format.

There are several ways to add codes:

2.7.2.4.1 Duplicating an existing code

One way to create a new code is to duplicate an existing one (called the base code).

If the base code is associated with some original data: the new code simply use these data.

For example, the translation in the following unit, the second inline code is a duplicate of the first one:

<unit id="1">
 <segment>
  <source>Äter <pc id="1" dataRefStart="d1" dataRefEnd="d2">katter
möss</pc>?</source>
  <target>Do <pc id="1" dataRefStart="d1" dataRefEnd="d2">cats</pc>
eat <pc id="2" dataRefStart="d1" dataRefEnd="d2">mice</pc>?</target>
 </segment>
 <originalData>
  <data id="d1">&lt;b></data>
  <data id="d2">&lt;/b></data>
 </originalData>
</unit>

If the base code has no associated data, the new code MUST use the copyOf attribute to indicate the id of the base code. This allows the merging tool to know what original data to re-use.

For example, the translation in the following unit, the second inline code is a duplicate of the first one:

<unit id="1">
 <segment>
  <source>Esznek <pc id="1">a magyarok svéd húsgombócot</pc>?</source>
  <target>Do <pc id="1">Hungarians</pc> eat 
<pc id="2" copyOf="1">Swedish meatballs</pc>?</target>
 </segment>
</unit>

Processing Requirements

  • Modifiers MUST NOT clone a code that has its canCopy attribute is set to no.

  • The copyOf attribute MUST be used when, and only when, the base code has no associated original data.

2.7.2.4.2 Creating a brand-new code

Another way to add a code is to create it from scratch. For example, this can happen when the translated text requires additional formating.

For example, in the following unit, the UI text needs to stay in English, and is also translated into French as a hint for the French user. The French translation for the UI text is formatted in italics:

<unit id="1">
 <segment>
  <source>Press the <pc id="1" dataRefStart="d1" dataRefEnd="d2">Emergency Stop</pc>
button to interrupt the count-down sequence.</source>
  <target>Appuyez sur le bouton
<pc id="1" dataRefStart="d1" dataRefEnd="d2">Emergency Stop</pc>
(<pc id="2" dataRefStart="n2" dataRefEnd="n2">Arrêt d'urgence</pc>) pour interrompre
le compte à rebours.</target>
 </segment>
 <originalData>
  <data id="d1">&lt;b></data>
  <data id="d2">&lt;/b></data>
  <data id="n1">&lt;i></data>
  <data id="n2">&lt;/i></data>
 </originalData>
</unit>
2.7.2.4.3 Converting text into a code

Another way to add a code is to convert part of the extracted text into code. In some cases the inline code can be created after extraction, using part of the text content. This can be done, for instance, to get better matches from an existing TM, or better candidates from an MT system.

For example, it can happen that a tool extracting a Java properties file to XLIFF is not sophisticated enough to treat HTML or XML snippets inside the extracted text as inline code:

# text property for the widget 'next'
nextText: Click <ui>Next</ui>

Resulting XLIFF content:

<unit id="1">
 <segment>
  <source>Click &lt;ui>Next&lt;/ui></source>
 </segment>
</unit>

But another tool, later in the process, can be used to process the initial XLIFF document and detect additional inline codes. For instance here the XML elements such as <ui>.

The original data of the new code is the part of the text content that is converted as inline code.

<unit id="1">
 <segment>
  <source>Click <pc id="1" dataRefStart="d1" dataRefEnd="d2">Next</pc></source>
 </segment>
 <originalData>
  <data id="d1">&lt;ui></data>
  <data id="d2">&lt;/ui></data>
 </originalData>
</unit>

Warning

Converting XLIFF text content into original data for inline code might need a tool-specific process as the tool which did the initial extraction could have applied some conversion to the original content to create the XLIFF content (e.g. un-escape special characters).

2.7.2.5 Removing Codes

When processing a content, there are some possible cases when existing inline codes need to be removed.

For an example the translation of a sentence can result in grouping of several formatted parts into a single one. For instance, the following sentence in English uses bold on the names of two animals:

Do <b>cats</b> eat <b>mice</b>?

But the Swedish translation group the two names and therefore needs only a single bolded part.

Äter <b>katter möss</b>?

Processing Requirements

  • User agents MAY remove a given inline code only if its canDelete attribute is set to yes.

  • When removing a given inline code, the user agents MUST remove its associated original data, except if the original data is shared with another inline code that remains in the unit.

    Note that having to delete the original data is unlikely because such original data is likely to be associated to an inline code in the source content.

There are several ways to remove codes:

2.7.2.5.1 Deleting a code

One way to remove a code is to delete it from the extracted content. For example, in the following unit, the translated text does not use the italics formatting. It is removed from the target content, but the original data are preserved because they are still used in the source content.

<unit id="1">
 <segment>
  <source>I read <pc id="1" dataRefStart="d1" dataRefEnd="d2">Little
House on the Prairie</pc> to my children.</source>
  <target>子供に「大草原の小さな家」を読みました。</target>
 </segment>
 <originalData>
  <data id="d1">&lt;i></data>
  <data id="d2">&lt;/i></data>
 </originalData>
</unit>
2.7.2.5.2 Converting a code into text

Another way to remove an inline code is to convert it into text content. This is likely to be a rare use case. It is equivalant to deleting the code, with the addition to place the original data for the given code into the content, as text. This can be done, for example, to get better matches from an existing TM, or better candidates from an MT system.

For instance, the following unit has an inline code corresponding to a variable place-holder. A tool can temporarily treat this variable as text to get better matches from an existing TM.

<unit id="1">
 <segment>
  <source>Cannot find '<ph id="1" dataRef="d1"/>'.</source>
 </segment>
 <originalData>
  <data id="d1">%s</data>
 </originalData>
</unit>

The modified unit would end up like as shown below. Note that because the original data was not associated with other inline code it has been removed from the unit:

<unit id="1">
 <segment>
  <source>Cannot find '%s'.</source>
 </segment>
</unit>

Warning

Converting the original data of an inline code into text content might need a tool-specific process as the tool which did the initial extraction could have applied some conversion to the original content.

2.7.2.6 Editing Hints

XLIFF provides some information about what editing operations are applicable to inline codes:

  • A code can be deleted: That is, the code element as well as its original data (if any are attached) are removed from the document. This hint is represented with the canDelete attribute. The default value is yes: deletion is allowed.

    For example, the following extracted C string has the code <ph id='1'/> set to be not deletable because removing the original data (the variable placeholder %s) from the string would result in an error when running the application:

  • A code can be copied: That is, the code is used as a base code for adding another inline code. See Section 2.7.2.4.1, “Duplicating an existing code” for more details. This hint is represented with the canCopy attribute. The default value is yes: copy is allowed.

  • A code can be re-ordered: That is, a given code can be moved before or after another inline code. This hint is represented with the canReorder attribute. The default value is yes: re-ordering is allowed.

Note

Please note that often those properties are related and appear together. For example, the code in the first unit shown below is a variable placeholder that has to be preserved and cannot be duplicated, and when several of such variables are present, as in the second unit, they cannot be re-ordered:

<unit id="1">
 <segment>
  <source>Can't open '<ph id="1" dataRef="d1" canCopy="no" canDelete="no"/>'.</source>
 </segment>
 <originalData>
  <data id="d1">%s</data>
 </originalData>
</unit>
<unit id="2">
 <segment>
  <source>Number of <ph id="1" dataRef="d1" canCopy="no" canDelete="no" canReorder="no"/>: 
<ph id="2" dataRef="d2" canCopy="no" canDelete="no" canReorder="no"/>.</source>
 </segment>
 <originalData>
  <data id="d1">%s</data>
  <data id="d2">%d</data>
 </originalData>
</unit>

See the Target Content Modification section for additional details on editing.

Constraints

Processing Requirements

  • Extractors SHOULD set the canDelete, canCopy and canReorder attributes for the codes that need to be treated differently than with the default settings.

  • Modifiers MUST NOT delete inline codes that have their attribute canDelete set to no.

  • Modifiers SHOULD NOT replicate inline codes that have their attribute canCopy set to no.

2.7.3 Annotations

An annotation is an element that associates a section of the content with some metadata information.

Annotations MAY be created by an Extractor that generated the initial XLIFF Document, or by any other Modifier or Enricher later in the process. For example, after an Extractor creates the document, an Enricher can annotate the source content with terminological information.

Annotations are represented using either the <mrk> element, or the pair of <sm> and <em> elements.

Processing Requirements

  • When a Modifier removes an <mrk> element or a pair of <sm> / <em> elements and the ref attribute is present, it MUST check whether or not the URI referenced by the ref attribute is within the same <unit> as the removed element. If it is and no other element has a reference to the referenced element, the Modifier MUST remove the referenced element.

2.7.3.1 Type of Annotations

There are several pre-defined types of annotation and definition of custom types is also allowed.

2.7.3.1.1 Translate Annotation

This annotation is used to indicate whether a span of content is translatable or not.

Usage:

  • The id attribute is REQUIRED

  • The translate attribute is REQUIRED and set to yes or no

  • The type attribute is OPTIONAL and set to generic (this is the default value)

For example:

He saw his <mrk id="m1" translate="no">doppelgänger</mrk>.

Note

This annotation overrides the translate attribute set at the <segment> level.

Note

The translate attribute can also be used at the same time as another type of annotation. For example:

He saw his <mrk id="m1" translate="no" type="term">doppelgänger</mrk>.
2.7.3.1.2 Term Annotation

This annotation is used to mark up a term in the content, and possibly associate information to it.

Usage:

  • The id attribute is REQUIRED

  • The type attribute is REQUIRED and set to term

  • The value attribute is OPTIONAL and contains a short definition of the term

  • The ref attribute is OPTIONAL and contains a URI pointing to information on the term

  • The translate attribute is OPTIONAL and set to yes or no

For example:

<unit id="1">
  <segment>
    <source>He is my <mrk id="m1" type="term" ref="#g1">doppelgänger</mrk>.</source>
    <target>Il est mon <mrk id="m1" type="term" ref="#g1">alter ego</mrk>.</target>
  </segment>
  <gls:glossary>
    <gls:glossentry id="g1">
      <gls:term>doppelgänger</gls:term>
      <gls:definition source="dictionary.com">A ghostly double or counterpart of a living person.</gls:definition>
    </gls:glossentry>
  </gls:glossary>
</unit>        
        
2.7.3.1.3 Translation Candidate Annotation

This annotation is used to mark up the scope of a translation candidate within the content of a unit and reference a match specified for instance using the Translation Candidates module.

Usage:

  • The id attribute is REQUIRED

  • The type attribute is REQUIRED and set to match

  • The ref attribute is REQUIRED and contains a URI pointing to the translation candidate

  • The translate attribute is OPTIONAL and set to yes or no

For example:

<unit id="1">
  <segment>
    <source><mrk id="m1" type="match" ref="#tc1">He is my friend.</mrk></source>
  </segment>
  <segment>
    <source>Yet, I barely see him.</source>
  </segment>
  <mtc:matches>
      <mtc:match id="tc1">
      <source>He is my friend.</source>
      <target>Il est mon ami.</target>
    </mtc:match>
  </mtc:matches>
</unit>        
        
2.7.3.1.4 Comment Annotation

This annotation is used to associate a span of content with a comment.

Usage:

  • The id attribute is REQUIRED

  • The type attribute is REQUIRED and set to comment

  • If the value attribute is present it contains the text of the comment, otherwise the ref attribute MUST be present and contains the id value (in URI format) of a <note> element that holds the comment.

  • The translate attribute is OPTIONAL and set to yes or no

For example, here with the value attribute:

The <mrk id="m1" type="comment"
 value="Possible values: Printer or Stacker"><ph id="1" dataRef="d1"/></mrk>
has been enabled.

And here using the ref attribute:

<unit id="1">
 <segment>
  <source>You use your own namespace.</source>
  <target>Vous pouvez utiliser votre propre <mrk id="m1"
type="comment" ref="#n1">namespace</mrk>.</target>
  <notes>
   <note id="n1" appliesTo="target">Please check the 
translation for 'namespace'. On also can use 'espace de nom',
but I think most technical manuals use the English
term.</note>
  </notes>
 </segment>
</unit>
2.7.3.1.5 Custom Annotation

The <mrk> element can be used to implement custom annotations.

A custom annotation MUST NOT provide the same functionality as a pre-defined annotation.

Usage:

  • The id attribute is REQUIRED

  • The type attribute is REQUIRED and set to a unique user-defined value.

  • The translate attribute is OPTIONAL and set to yes or no

  • The use and semantics of the value and ref attributes are user-defined.

For example:

One of the earliest surviving works of literature is
<mrk id="m1" type="myCorp:isbn" value="978-0-14-44919-8">The 
Epic of Gilgamesh</mrk>.
2.7.3.2 Splitting Annotations

Annotations can overlap spanning inline codes or other annotations. They also can be split by segmentation. Because of this, a single annotation span can be represented using a pair of <sm> and <em> elements instead of a single <mrk> element.

For example, one can have the following content:

<unit id="1">
 <segment>
  <source>Sentence A. <mrk id="m1" type="comment" 
value="Comment for B and C">Sentence B. Sentence C.</mrk></source>
 </segment>
</unit>

After a user agent performs segmentation, the annotation element <mrk> is changed to a pair of <sm> and <em> elements:

<unit id="1">
 <segment>
  <source>Sentence A. </source>
 </segment>
 <segment>
  <source><sm id="m1" type="comment" 
value="Comment for B and C"/>Sentence B. </source>
 </segment>
 <segment>
  <source>Sentence C.<em startRef="m1"/></source>
 </segment>
</unit>

2.7.4 Sub-Flows

A sub-flow is a section of text embedded inside an inline code, or inside another section of text.

For example, the following HTML content includes two sub-flows: The first one is the value of the title attribute ("Start button"), and the second one is the value of the alt attribute ("Click here to start!"):

Click to start: <img title="Start button"
 src="btnStart.png" alt="Click here to start!"/>

Another example is the following DITA content where the footnote "A Palouse horse is the same as an Appaloosa." is defined at the middle of a sentence:

Palouse horses<fn>A Palouse horse is the same as
 an Appaloosa.</fn> have spotted coats.

In XLIFF, each sub-flow is stored in its own <unit> element, and the subFlows attribute is used to indicate the location of the embedded content.

Therefore the HTML content of the example above can be represented like below:

<unit id="1">
 <segment>
  <source>Start button</source>
 </segment>
</unit>
<unit id="2">
 <segment>
  <source>Click here to start!</source>
 </segment>
</unit>
<unit id="3">
 <segment>
  <source>Click to start: <ph id="1" subFlows="1 2"/></source>
 </segment>
</unit>

Processing Requirements

  • The extraction tool SHOULD store each sub-flow in its own <unit> element.

  • An inline code containing or delimiting one or more sub-flows MUST have an attribute subFlows that holds a list of the identifiers of the <unit> elements where the sub-flows are stored.

  • The extraction tool MAY order the <unit> elements of the sub-flows and the <unit> element of their parent in any order it sees fit. User agents coming later in the process MUST keep the <unit> elements in their initial order.

2.7.5 White Spaces

While white spaces can be significant or insignificant in the original format, they are always treated as significant when stored as original data in XLIFF.

Processing Requirements

  • For the elements <sc>, <ec>, <ph> and <data>: The white spaces of their content MUST be preserved in all cases, even if the value for xml:space is set or inherited as default.

  • For the inline content and all other inline elements: The white spaces MUST be preserved if the value for xml:space is set to preserve, and they MAY be preserved if the value is set to default.

2.7.6 Bidirectional Text

Text directionality in XLIFF content is defined by inheritance. Source and target content can have different directionality.

The initial directionality for both the source and the target content is defined in the <file> element, using the OPTIONAL attributes srcDir for the source and trgDir for the target. The default value for both attributes is ltr.

The <group> and <unit> elements also have the two OPTIONAL attributes srcDir and trgDir. Their values MUST be either ltr or rtl. The default value of the srcDir is inherited from the value of the srcDir attribute of the respective parent element. The default value of the trgDir attribute is inherited from the value of the trgDir attribute of the respective parent element.

The <source> element has an OPTIONAL attribute dir with a value ltr or rtl. The default value is the same as the value of the of the srcDir attribute on the <unit> element, in which the element is located.

The <target> element has an OPTIONAL attribute dir with a value ltr or rtl. The default value is the same as the value of the trgDir attribute of the <unit>, in which the element is located.

The <pc> and <sc> elements have an OPTIONAL attribute dir with a value ltr or rtl. The default value is inherited from the parent <source>, <target>, or <pc> element, in which the respective element is located.

Adding bidirectional information in the text content is done using the Unicode bidirectional control characters [UAX #9].

In addition, the <data> element has an OPTIONAL attribute dir with a value ltr or rtl that is not inherited. The default value is ltr.

2.7.7 Target Content Modification

This section defines the rules Writers need to follow when working with the target content of a given segment in order to provide interoperability throughout the whole process.

The Extractor MAY create the initial target content as it sees fit.

The Merger is assumed to have the same level of processing and native format knowledge as the Extractor. Providing an interoperable way to convert native documents into XLIFF with one tool and back to the native format with another tool without the same level of knowledge is outside the scope of this specification.

The Writers Modifying the target content of an XLIFF Document between the Extractor and the Merger ensure interoperability by applying specific rules. These rules are separated into two cases: When there is an existing target and when there is no existing target.

2.7.7.1 Without an Existing Target

When there is no existing target, the processing requirements for a given segment are the following:

Processing Requirements

  • Writers MAY leave the segment without a target.

  • Modifiers MAY create a new target as follows:

    • Modifiers MAY add translatable text.

    • Modifiers MUST put all non-removable inline codes in the target.

    • Modifiers MUST preserve the order of all the non-reorderable inline codes.

    • Modifiers MAY put any removable inline code in the target.

    • Modifiers MAY add inline codes.

    • Modifiers MAY add or remove annotations.

    • Modifiers MAY convert any <pc> element into a pair of <sc> and <ec> elements.

    • Modifiers MAY convert, if it is possible, any pair of <sc> and <ec> elements into a <pc> element.

2.7.7.2 With an Existing Target

When working with a segment with content already in the target, Writers MUST choose one of the three behaviors described below:

Processing Requirements

  • Writers MAY leave the existing target unchanged.

  • Modifiers MAY modify the existing target as follow:

    • Modifiers MAY add or Modify translatable text.

    • Writers MUST preserve all non-removable inline codes, regardless whether or not they exist in the source.

    • Writers MUST preserve any non-reorderable inline codes in the existing target.

    • Writers MUST NOT add any non-reorderable inline codes to the target.

    • Modifiers MAY remove any removable inline codes in the target.

    • Modifiers MAY add inline codes (including copying any cloneable inline codes of the existing target).

    • Modifiers MAY add or remove annotations.

    • Modifiers MAY convert any <pc> element into a pair of <sc> and <ec> elements.

    • Modifiers MAY convert, if it is possible, any pair of <sc> and <ec> elements into a <pc> element.

  • Modifiers MAY delete the existing target and start over as if working without an existing target.

2.7.8 Content Comparison

This specification defines two types of content equality:

  • Equality type A: Two contents are equal if their normalized forms are equal.

  • Equality type B: Two contents are equal if, in their normalized forms and with all inline code markers replaced by the value of their equiv attributes, the resulting strings are equal.

A content is normalized when:

  • The text nodes are in Unicode Normalized Form C defined in the Unicode Annex #15: Unicode Normalization Forms [UAX #15].

  • All annotation markers are removed.

  • All pairs of <sc> and <ec> elements that can be converted into a <pc> element, are converted.

  • All adjacent text nodes are merged into a single text node.

  • For all the text nodes with the white space property set to default, all adjacent white spaces are collapsed into a single space.

2.8 Extension Mechanisms

XLIFF 2.0 offers two mechanisms for storing custom data in an XLIFF document:

  1. Using the Metadata module for storing custom data in elements defined by the official XLIFF specification.

  2. Using the standard XML namespace mechanism for storing data in elements or attributes defined in a custom XML Schema.

Both mechanisms can be used simultaneously.

2.8.1 Extension Points

The following XLIFF Core elements allow storing custom data in <mda:metadata> elements or in elements from a custom XML namespace:

- <file>
- <group>
- <unit>

XLIFF Modules extensibility by the Metadata module or custom namespace elements is specified in those modules.

The following XLIFF Core elements accept custom attributes:

- <file>
- <group>
- <unit>
- <mrk>
- <sm>

XLIFF Modules extensibility by custom namespace attributes is specified in those modules.

2.8.2 Processing Requirements

  • A user extension, whether implemented using <mda:metadata> or using a custom namespace, MUST NOT provide the same functionality as an existing XLIFF core or module feature, however it MAY complement an extensible XLIFF core feature or module feature or provide a new funtionality at the provided extensin points.

  • Mergers MUST NOT rely on custom namespace extensions, other than the ones possibly defined in <skeleton>, to create the Translated version of the original document.

  • Writers that do not support a given custom namespace based user extension SHOULD preserve that extension without Modification.

2.9 Segmentation

In the context of XLIFF, a segment is a content which is either a unit of extracted text, or has been created from a unit of extracted text by means of a segmentation mechanism such as sentence boundary detection. For example, a segment can be a title, the text of a menu item, a paragraph or a sentence in a paragraph.

In the context of XLIFF, other types representations sometimes called "segmentation" can be represented using annotations. For example: the terms in a segment can be identified and marked up using the term annotation.

XLIFF does not specify how segmentation is carried out, only how to represent its result. Material provisions regarding segmentation can be found for instance in the Segmentation Rules eXchange standard [SRX] or [UAX #29].

2.9.1 Segments Representation

In XLIFF each segment of processed content is represented by a <segment> element.

A <unit> can comprise a single <segment>.

Each <segment> element has one <source> element that contains the source content and one OPTIONAL <target> element that can be empty or contain the translation of the source content at a given state.

Content parts between segments are represented with the <ignorable> element, which has the same content model as <segment>.

For example:

<unit id="1">
 <segment>
  <source>First sentence.</source>
  <target>Première phrase.</target>
 </segment>
 <ignorable>
  <source> </source>
 </ignorable>
 <segment>
  <source>Second sentence.</source>
 </segment>
</unit>

2.9.2 Segments Order

Some Agents (e.g. aligner tools) can segment content, so that the target segments are not in the same order as the source segments.

To be able to map order differences, the <target> element has an OPTIONAL order attribute that indicates its position in the sequence of segments (and inter-segments). Its value is an integer from 1 to N, where N is the sum of the numbers of the <segment> and <ignorable> elements within the given enclosing <unit> element.

For example, the following HTML documents have the same paragraph with three sentences in different order:

<p lang='en'>Sentence A. Sentence B. Sentence C.</p>
<p lang='fr'>Phrase B. Phrase C. Phrase A.</p>

The XLIFF representation of the content, after segmentation and alignment, would be:

<unit id="1">
 <segment id="1">
  <source>Sentence A.</source>
  <target order="5">Phrase A.</target>
 </segment>
 <ignorable>
  <source> </source>
 </ignorable>
 <segment id="2">
  <source>Sentence B.</source>
  <target order="1">Phrase B.</target>
 </segment>
 <ignorable>
  <source> </source>
 </ignorable>
 <segment id="3">
  <source>Sentence C.</source>
  <target order="3">Phrase C.</target>
 </segment>
</unit>

2.9.3 Segmentation Modification - Resegmentation

When Modifying segmentation, or performing Resegmentation, Modifiers MUST meet the following high level Constrainst and follow the below detailed Processing Requirements:

Constraints

  • Intergrity of the inline codes - see the section on Inline Codes for detailed requirements - and the inline annotations - see the section on Annotations for detailed requirements - MUST be prerserved.

  • Integrity of XLIFF Core attributes on the <segment>, <ignorable>, <source>, and <target> elements MUST be prerserved.

    For example, the uniqueness of id attribute values of those elements within a unit has to be preserved.

  • The entire source content of any one <unit> element MUST remain logically unchanged; <segment> elements or their data MUST NOT be moved or joined across units.

Warning

Modifiers changing segmentation have to preserve integrity of the relations between segments and the associated data.

Warning

Note that when splitting or joining segments that have both source and target content it is advisable to keep the resulting segments linguistically aligned, which is likely to require human lingusistic expertise and hence manual resgmentation. If the lingusitically correct alignmnet cannot be guaranteed, discarding the target content and retranslating the resulting source segments is worth considering.

Processing Requirements

  • When the value of the canResegment flag is no on all <segment> elements within a <unit>:

    • Modifiers MUST NOT split or join either the <segment>, or the <ignorable> elements within that <unit>.

    • Modifiers MAY still reorder the <target> elements within that <unit> using the OPTIONAL order attributes as needed.

  • When the value of the canResegment flag is no on some <segment> elements and yes on some other <segment> elements within a <unit>:

  • When the value of the canResegment flag is yes on all <segment> elements within a <unit>:

    • Modifiers MAY split or join all <segment> or <ignorable> elements within the same <unit> as needed.

    • Modifiers splitting or joining <segment> or <ignorable> elements MUST update, add or remove the order attributes of the <target> elements as needed to preserve the existing logical order of the target content.

    • Modifiers MAY reorder all <target> elements within that <unit> using the OPTIONAL order attributes as needed.

  • Handling of content, elements, and attributes in the <segment>, <ignorable>, <source>, and <target> elements when splitting <segment> elements:

    • Modifiers MAY split the source and target content as they see fit between the split instances, except that the eventually resulting <ignorable> element MUST NOT hold translatable content.

    • Modifiers MUST copy all attributes including values, except for the id and order attributes, from their original instances on or within the original <segment> element onto both instances on and within the resulting two <segment> or <ignorable> elements, except for attributes that do not have valid instances on the eventually resulting <ignorable> element.

      • New unique id values MUST be created and assigned as needed to fullfill uniqueness constraints within the enclosing <unit> element.

      • The order attributes MUST be reassigned as needed within the enclosing <unit> element to ensure the desired target text flow.

    • Modifiers MUST transform spanning inline codes that start and end in different new segments into the non spanning versions according to the rules for usage and conversion between the different inline code representations.

  • Handling of content, elements and attributes in the <segment>, <ignorable>, <source>, and <target> elements when joining segment or <ignorable> elements:

    • Modifiers MUST join the content of the original <segment> and <ignorable> elements in the same order as it apeared, taking the order attribute into account. Non consecutive <segment> or <ignorable> elements MUST NOT be joined, again taking the order attribute into account.

    • Modifiers MUST put all attributes that are the same on and within all joined <segment> elements on their valid instances on and within the resulting <segment> element.

    • The order attributes MUST be reassigned or removed as needed within the enclosing <unit> element to ensure the desired target text flow.

    • If attributes differ in values on the joined <segment> elements or their children elements, Modifiers MUST perform the following trasformations, according to which attributes actually differ.

      • If the xml:space attributes differ in values, the resulting value MUST be preserve.

      • If the translate attributes differ the resulting <segment> element MUST have it set to yes

      • If the state attributes differ in values, the resulting <segment> element MUST have it set to the "earliest" value set on any of the joined segments.

        "Earliest" in the above refers to the process state of the segment, the leftmost in the sequence initial, translated, reviewed, final is considered the "earliest".

      • If the directionality attributes, srcDir, trgDir, or dir differ the Modifier MUST insert Unicode bidirectional control characters [UAX #9] to secure proper directionality in the <segment> and its children.

    • Modifiers MAY transform non spanning inline codes that started and ended in different segments but now start and end in the same segment into the spanning version according to the rules for usage and conversion between the different inline code representations.

3 Conformance

  1. Document Conformance

    1. XLIFF is an XML vocabulary, therefore conformant XLIFF Documents MUST be well formed and valid [XML] documents.

    2. Conformant XLIFF Documents MUST be valid instances of the official Core XML Schema that is part of this XLIFF specification.

    3. 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.

    4. XLIFF Documents MAY contain custom extensions, as defined in the Extension Mechanisms section.

  2. Application Conformance

    1. XLIFF Writers MUST create conformant XLIFF Documents to be considered XLIFF compliant.

    2. 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.

    3. All Agents MUST comply with Processing Requirements for otherwise unspecified Agents or without a specifically set target Agent.

    4. 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 3. above.

    5. 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:

      1. The processed files are conformant XLIFF Documents,

      2. in a state compliant with all relevant Processing Requirements.

  3. Backwards Compatibility

    1. Conformant applications are NOT REQUIRED to support XLIFF 1.2 or previous Versions.

Appendix A XML Schemas and Catalog

The grammar of XLIFF 2.0 is defined using eight (7) XML Schemas and one (1) XML catalog. The module schemas are referenced from their respective modules.

A.2 XML Catalog

The catalog listed below for reading convenience is accessible at http://docs.oasis-open.org/xliff/xliff-core/v2.0/csprd02/schemas/catalog.xml.

<?xml version="1.0" encoding="UTF-8"?>
<catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog">
    <uri name="urn:oasis:names:tc:xliff:document:2.0" uri="xliff_core_2.0.xsd"/>
    <uri name="urn:oasis:names:tc:xliff:changetracking:2.0" uri="modules/change_tracking.xsd"/>
    <uri name="urn:oasis:names:tc:xliff:glossary:2.0" uri="modules/glossary.xsd"/>
    <uri name="urn:oasis:names:tc:xliff:matches:2.0" uri="modules/matches.xsd"/>
    <uri name="urn:oasis:names:tc:xliff:metadata:2.0" uri="modules/metadata.xsd"/>
    <uri name="urn:oasis:names:tc:xliff:resourcedata:2.0" uri="modules/resource_data.xsd"/>
    <uri name="urn:oasis:names:tc:xliff:sizerestriction:2.0" uri="modules/size_restriction.xsd"/>
    <uri name="urn:oasis:names:tc:xliff:validation:2.0" uri="modules/validation.xsd"/>
</catalog>

A.3 Core XML Schema

The schema listed below for reading convenience is accessible at http://docs.oasis-open.org/xliff/xliff-core/v2.0/csprd02/schemas/xliff_core_2.0.xsd.

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" 
  elementFormDefault="qualified"
  xmlns:xlf="urn:oasis:names:tc:xliff:document:2.0"
  xmlns:ctr="urn:oasis:names:tc:xliff:changetracking:2.0"
  xmlns:fs="urn:oasis:names:tc:xliff:fs:2.0"
  xmlns:gls="urn:oasis:names:tc:xliff:glossary:2.0"
  xmlns:mtc="urn:oasis:names:tc:xliff:matches:2.0"
  xmlns:mda="urn:oasis:names:tc:xliff:metadata:2.0"
  xmlns:res="urn:oasis:names:tc:xliff:resourcedata:2.0"
  xmlns:slr="urn:oasis:names:tc:xliff:sizerestriction:2.0"  
  xmlns:val="urn:oasis:names:tc:xliff:validation:2.0"
  targetNamespace="urn:oasis:names:tc:xliff:document:2.0">

  <xs:import namespace="http://www.w3.org/XML/1998/namespace"
    schemaLocation="http://www.w3.org/2001/xml.xsd"/>
  <xs:import namespace="urn:oasis:names:tc:xliff:changetracking:2.0"
    schemaLocation="modules/change_tracking.xsd"/>
  <xs:import namespace="urn:oasis:names:tc:xliff:glossary:2.0"
    schemaLocation="modules/glossary.xsd"/>
  <xs:import namespace="urn:oasis:names:tc:xliff:matches:2.0"
    schemaLocation="modules/matches.xsd"/>
  <xs:import namespace="urn:oasis:names:tc:xliff:metadata:2.0"
    schemaLocation="modules/metadata.xsd"/>
  <xs:import namespace="urn:oasis:names:tc:xliff:resourcedata:2.0"
    schemaLocation="modules/resource_data.xsd"/>
  <xs:import namespace="urn:oasis:names:tc:xliff:sizerestriction:2.0"
    schemaLocation="modules/size_restriction.xsd"/>
  <xs:import namespace="urn:oasis:names:tc:xliff:validation:2.0"
    schemaLocation="modules/validation.xsd"/>
  
  <!-- Attribute definitions -->
  
  <xs:simpleType name="yesNo">
    <xs:restriction base="xs:string">
      <xs:enumeration value="yes"/>
      <xs:enumeration value="no"/>
    </xs:restriction>
  </xs:simpleType>

  <xs:simpleType name="dirValue">
    <xs:restriction base="xs:string">
      <xs:enumeration value="ltr"/>
      <xs:enumeration value="rtl"/>
    </xs:restriction>
  </xs:simpleType>
  
  <xs:simpleType name="appliesTo">
    <xs:restriction base="xs:string">
      <xs:enumeration value="source"/>
      <xs:enumeration value="target"/>
    </xs:restriction>
  </xs:simpleType>
  
  <xs:simpleType name="userDefinedValue">
    <xs:restriction base="xs:string">
      <xs:pattern value="[^\s:]+:[^\s:]+"/>
    </xs:restriction>
  </xs:simpleType>
  
  <xs:simpleType name="attrType_type">
    <xs:restriction base="xs:string">
      <xs:pattern value="(fmt|quot|link|image|other)"/>
    </xs:restriction>
  </xs:simpleType>
  
  <xs:simpleType name="typeForMrkValues">
    <xs:restriction base="xs:NMTOKEN">
      <xs:enumeration value="generic"/>
      <xs:enumeration value="comment"/>
      <xs:enumeration value="term"/>
    </xs:restriction>
  </xs:simpleType>  

  <xs:simpleType name="attrType_typeForMrk">
    <xs:union memberTypes="xlf:typeForMrkValues xlf:userDefinedValue"/>
  </xs:simpleType>
  
  <!-- Structural elements -->
  
  <xs:element name="xliff">
    <xs:complexType>
      <xs:sequence>
        <xs:element minOccurs="1" maxOccurs="unbounded" ref="xlf:file"/>
      </xs:sequence>
      <xs:attribute name="version" fixed="2.0" use="required"/>
      <xs:attribute name="srcLang" use="required"/>
      <xs:attribute name="trgLang" use="optional"/>
      <xs:anyAttribute namespace="##any" processContents="skip"/>
    </xs:complexType>
  </xs:element>

  <xs:element name="file">
    <xs:complexType>
      <xs:sequence>
        <xs:element minOccurs="0" maxOccurs="1" ref="xlf:skeleton"/>
        <xs:element minOccurs="0" maxOccurs="1" ref="xlf:notes"/>
        <xs:element minOccurs="0" maxOccurs="1" ref="mda:metadata"/>
        <xs:element minOccurs="0" maxOccurs="unbounded" ref="res:resourceData"/>
        <xs:element minOccurs="0" maxOccurs="1" ref="slr:profiles"/>
        <xs:element minOccurs="0" maxOccurs="1" ref="slr:data"/>
        <xs:element minOccurs="0" maxOccurs="1" ref="val:validation"/>
        <xs:choice minOccurs="1" maxOccurs="unbounded">
          <xs:element ref="xlf:unit"/>
          <xs:element ref="xlf:group"/>
        </xs:choice>
        <xs:any maxOccurs="unbounded" minOccurs="0" namespace="##other" 
          processContents="skip"/>
      </xs:sequence>
      <xs:attribute name="id" use="optional" type="xs:NMTOKEN"/>
      <xs:attribute name="canResegment" use="optional"/>
      <xs:attribute name="original" use="optional"/>
      <xs:attribute name="translate" use="optional" type="xlf:yesNo" default="yes"/>
      <xs:attribute name="approved" type="xlf:yesNo" default="no"/>
      <xs:attribute name="srcDir" use="optional" type="xlf:dirValue"/>
      <xs:attribute name="trgDir" use="optional" type="xlf:dirValue"/>
      <xs:attribute ref="fs:fs" use="optional"/>
      <xs:attribute ref="fs:subFs" use="optional"/>
      <xs:attribute ref="slr:storageRestriction" use="optional"/>
      <xs:attribute ref="slr:sizeRestriction" use="optional"/>
      <xs:attribute ref="slr:sizeInfo" use="optional"/>
      <xs:attribute ref="slr:sizeInfoRef" use="optional"/>
      <xs:anyAttribute namespace="##any" processContents="skip"/>
    </xs:complexType>
  </xs:element>

  <xs:element name="skeleton">
    <xs:complexType mixed="true">
      <xs:sequence>
        <xs:any maxOccurs="unbounded" minOccurs="0" namespace="##other" 
          processContents="skip"/>
      </xs:sequence>
      <xs:attribute name="href" use="optional"/>
    </xs:complexType>
  </xs:element>

  <xs:element name="group">
    <xs:complexType>
      <xs:sequence>
        <xs:choice minOccurs="1" maxOccurs="unbounded">
          <xs:element ref="xlf:unit"/>
          <xs:element ref="xlf:group"/>
        </xs:choice>
        <xs:element minOccurs="0" maxOccurs="1" ref="xlf:notes"/>
        <xs:element minOccurs="0" maxOccurs="1" ref="mda:metadata"/>
        <xs:element minOccurs="0" maxOccurs="1" ref="slr:data"/>
        <xs:element minOccurs="0" maxOccurs="1" ref="val:validation"/>
        <xs:any maxOccurs="unbounded" minOccurs="0" namespace="##other" 
          processContents="skip"/>
      </xs:sequence>
      <xs:attribute name="id" use="optional" type="xs:NMTOKEN"/>
      <xs:attribute name="name" use="optional"/>
      <xs:attribute name="canResegment" use="optional"/>
      <xs:attribute name="translate" use="optional" type="xlf:yesNo" default="yes"/>
      <xs:attribute name="approved" type="xlf:yesNo" default="no"/>
      <xs:attribute name="srcDir" use="optional" type="xlf:dirValue"/>
      <xs:attribute name="trgDir" use="optional" type="xlf:dirValue"/>
      <xs:attribute ref="fs:fs" use="optional"/>
      <xs:attribute ref="fs:subFs" use="optional"/>
      <xs:attribute ref="slr:storageRestriction" use="optional"/>
      <xs:attribute ref="slr:sizeRestriction" use="optional"/>
      <xs:attribute ref="slr:sizeInfo" use="optional"/>
      <xs:attribute ref="slr:sizeInfoRef" use="optional"/>
      <xs:anyAttribute namespace="##any" processContents="skip"/>
    </xs:complexType>
  </xs:element>

  <xs:element name="unit">
    <xs:complexType>
      <xs:sequence>
        <xs:choice minOccurs="1" maxOccurs="unbounded">
          <xs:element ref="xlf:segment"/>
          <xs:element ref="xlf:ignorable"/>
        </xs:choice>
        <xs:element minOccurs="0" maxOccurs="1" ref="xlf:notes"/>
        <xs:element minOccurs="0" maxOccurs="1" ref="xlf:originalData"/>
        <xs:element minOccurs="0" maxOccurs="1" ref="mtc:matches"/>
        <xs:element minOccurs="0" maxOccurs="1" ref="gls:glossary"/>
        <xs:element minOccurs="0" maxOccurs="1" ref="mda:metadata"/>
        <xs:element minOccurs="0" maxOccurs="1" ref="slr:data"/>
        <xs:element minOccurs="0" maxOccurs="1" ref="val:validation"/>
        <xs:any maxOccurs="unbounded" minOccurs="0" namespace="##other" 
          processContents="skip"/>
      </xs:sequence>
      <xs:attribute name="id" use="required" type="xs:NMTOKEN"/>
      <xs:attribute name="name" use="optional" />
      <xs:attribute name="canResegment" use="optional"/>
      <xs:attribute name="translate" use="optional" type="xlf:yesNo" default="yes"/>
      <xs:attribute name="approved" type="xlf:yesNo" default="no"/>
      <xs:attribute name="srcDir" use="optional" type="xlf:dirValue"/>
      <xs:attribute name="trgDir" use="optional" type="xlf:dirValue"/>
      <xs:attribute ref="fs:fs" use="optional"/>
      <xs:attribute ref="fs:subFs" use="optional"/>
      <xs:attribute ref="slr:storageRestriction" use="optional"/>
      <xs:attribute ref="slr:sizeRestriction" use="optional"/>
      <xs:attribute ref="slr:sizeInfo" use="optional"/>
      <xs:attribute ref="slr:sizeInfoRef" use="optional"/>
      <xs:anyAttribute namespace="##any" processContents="skip"/>
    </xs:complexType>
  </xs:element>

  <xs:element name="segment">
    <xs:complexType>
      <xs:sequence>
        <xs:element minOccurs="1" maxOccurs="1" ref="xlf:source"/>
        <xs:element minOccurs="0" maxOccurs="1" ref="xlf:target"/>
      </xs:sequence>
      <xs:attribute name="id" use="optional" type="xs:NMTOKEN"/>
      <xs:attribute name="canResegment" use="optional"/>
      <xs:attribute name="translate" use="optional" type="xlf:yesNo" default="yes"/>
      <xs:attribute name="state" use="optional" default="initial"/>
      <xs:attribute name="subState" use="optional"/>
    </xs:complexType>
  </xs:element>

  <xs:element name="ignorable">
    <xs:complexType>
      <xs:sequence>
        <xs:element minOccurs="1" maxOccurs="1" ref="xlf:source"/>
        <xs:element minOccurs="0" maxOccurs="1" ref="xlf:target"/>
      </xs:sequence>
      <xs:attribute name="id" use="optional" type="xs:NMTOKEN"/>
    </xs:complexType>
  </xs:element>

  <xs:element name="originalData">
    <xs:complexType>
      <xs:sequence>
        <xs:element minOccurs="1" maxOccurs="unbounded" ref="xlf:data"/>
      </xs:sequence>
      <xs:attribute ref="fs:fs" use="optional"/>
      <xs:attribute ref="fs:subFs" use="optional"/>
    </xs:complexType>
  </xs:element>

  <xs:element name="data">
    <xs:complexType mixed="true">
      <xs:sequence>
        <xs:element minOccurs="0" maxOccurs="unbounded" ref="xlf:cp"/>
      </xs:sequence>
      <xs:attribute name="id" use="required" type="xs:NMTOKEN"/>
      <xs:attribute name="dir" use="optional" type="xlf:dirValue"/>
      <xs:attribute ref="fs:fs" use="optional"/>
      <xs:attribute ref="fs:subFs" use="optional"/>
    </xs:complexType>
  </xs:element>

  <xs:element name="notes">
    <xs:complexType>
      <xs:sequence>
        <xs:element minOccurs="1" maxOccurs="unbounded" ref="xlf:note"/>
      </xs:sequence>
      <xs:attribute ref="fs:fs" use="optional"/>
      <xs:attribute ref="fs:subFs" use="optional"/>
    </xs:complexType>
  </xs:element>

  <xs:element name="note">
    <xs:complexType mixed="true">
      <xs:attribute name="id" use="optional" type="xs:NMTOKEN"/>
      <xs:attribute name="appliesTo" use="optional" type="xlf:appliesTo"/>
      <xs:attribute name="category" use="optional"/>
      <xs:attribute name="priority" use="optional"/>
      <xs:anyAttribute namespace="##any" processContents="skip"/>
      <xs:attribute ref="fs:fs" use="optional"/>
      <xs:attribute ref="fs:subFs" use="optional"/>
    </xs:complexType>
  </xs:element>

  <xs:element name="source">
    <xs:complexType mixed="true">
      <xs:group ref="xlf:inline" minOccurs="0" maxOccurs="unbounded"/>
      <xs:attribute ref="xml:lang" use="optional"/>
      <xs:attribute ref="xml:space" use="optional"/>
      <xs:attribute name="dir" use="optional" type="xlf:dirValue"/>
    </xs:complexType>
  </xs:element>

  <xs:element name="target">
    <xs:complexType mixed="true">
      <xs:group ref="xlf:inline" minOccurs="0" maxOccurs="unbounded"/>
      <xs:attribute ref="xml:lang" use="optional"/>
      <xs:attribute ref="xml:space" use="optional"/>
      <xs:attribute name="dir" use="optional" type="xlf:dirValue"/>
      <xs:attribute name="order" use="optional"/>
    </xs:complexType>
  </xs:element>

  <!-- Inline elements -->

  <xs:group name="inline">
    <xs:choice>
      <xs:element minOccurs="0" maxOccurs="unbounded" ref="xlf:sc"/>
      <xs:element minOccurs="0" maxOccurs="unbounded" ref="xlf:ec"/>        
      <xs:element minOccurs="0" maxOccurs="unbounded" ref="xlf:ph"/>
      <xs:element minOccurs="0" maxOccurs="unbounded" ref="xlf:pc"/>
      <xs:element minOccurs="0" maxOccurs="unbounded" ref="xlf:cp"/>
      <xs:element minOccurs="0" maxOccurs="unbounded" ref="xlf:mrk"/>
      <xs:element minOccurs="0" maxOccurs="unbounded" ref="xlf:sm"/>
      <xs:element minOccurs="0" maxOccurs="unbounded" ref="xlf:em"/>
    </xs:choice>    
  </xs:group>
  
  <xs:element name="sc">
    <!-- Start Code -->
    <xs:complexType mixed="false">
      <xs:attribute name="canCopy" use="optional" type="xlf:yesNo" default="yes"/>
      <xs:attribute name="canDelete" use="optional" type="xlf:yesNo" default="yes"/>
      <xs:attribute name="canOverlap" use="optional" type="xlf:yesNo"/>
      <xs:attribute name="canReorder" use="optional" type="xlf:yesNo" default="yes"/>
      <xs:attribute name="copyOf" use="optional" type="xs:NMTOKEN"/>
      <xs:attribute name="disp" use="optional"/>
      <xs:attribute name="equiv" use="optional"/>
      <xs:attribute name="id" use="required" type="xs:NMTOKEN"/>
      <xs:attribute name="isolated" use="optional" type="xlf:yesNo" default="no"/>
      <xs:attribute name="dataRef" use="optional"/>
      <xs:attribute name="subFlows" use="optional" type="xs:NMTOKENS"/>
      <xs:attribute name="subType" use="optional" type="xlf:userDefinedValue"/>
      <xs:attribute name="type" use="optional" type="xlf:attrType_type"/>
      <xs:attribute name="dir" use="optional" type="xlf:dirValue"/>
      <xs:attribute ref="fs:fs" use="optional"/>
      <xs:attribute ref="fs:subFs" use="optional"/>
      <xs:attribute ref="slr:storageRestriction" use="optional"/>
      <xs:attribute ref="slr:sizeRestriction" use="optional"/>
      <xs:attribute ref="slr:equivStorage" use="optional"/>
      <xs:attribute ref="slr:sizeInfo" use="optional"/>
      <xs:attribute ref="slr:sizeInfoRef" use="optional"/>
    </xs:complexType>  
  </xs:element>
  
  <xs:element name="ec">
    <!-- End Code -->
    <xs:complexType mixed="false">
      <xs:attribute name="canCopy" use="optional" type="xlf:yesNo" default="yes"/>
      <xs:attribute name="canDelete" use="optional" type="xlf:yesNo" default="yes"/>
      <xs:attribute name="canOverlap" use="optional" type="xlf:yesNo"/>
      <xs:attribute name="canReorder" use="optional" type="xlf:yesNo" default="yes"/>
      <xs:attribute name="copyOf" use="optional" type="xs:NMTOKEN"/>
      <xs:attribute name="disp" use="optional"/>
      <xs:attribute name="equiv" use="optional"/>
      <xs:attribute name="id" use="optional" type="xs:NMTOKEN"/>
      <xs:attribute name="isolated" use="optional" type="xlf:yesNo" default="no"/>
      <xs:attribute name="dataRef" use="optional"/>
      <xs:attribute name="startRef" use="optional"/>
      <xs:attribute name="subFlows" use="optional" type="xs:NMTOKENS"/>
      <xs:attribute name="subType" use="optional" type="xlf:userDefinedValue"/>
      <xs:attribute name="type" use="optional" type="xlf:attrType_type"/>
      <xs:attribute ref="fs:fs" use="optional"/>
      <xs:attribute ref="fs:subFs" use="optional"/>
      <xs:attribute ref="slr:equivStorage" use="optional"/>
      <xs:attribute ref="slr:sizeInfo" use="optional"/>
      <xs:attribute ref="slr:sizeInfoRef" use="optional"/>
    </xs:complexType>  
  </xs:element>
  
  <xs:element name="ph">
    <!-- Placeholder -->
    <xs:complexType mixed="false">
      <xs:attribute name="canCopy" use="optional" type="xlf:yesNo" default="yes"/>
      <xs:attribute name="canDelete" use="optional" type="xlf:yesNo" default="yes"/>
      <xs:attribute name="canReorder" use="optional" type="xlf:yesNo" default="yes"/>
      <xs:attribute name="copyOf" use="optional" type="xs:NMTOKEN"/>
      <xs:attribute name="disp" use="optional"/>
      <xs:attribute name="equiv" use="optional"/>
      <xs:attribute name="id" use="required" type="xs:NMTOKEN"/>
      <xs:attribute name="dataRef" use="optional"/>
      <xs:attribute name="subFlows" use="optional" type="xs:NMTOKENS"/>
      <xs:attribute name="subType" use="optional" type="xlf:userDefinedValue"/>
      <xs:attribute name="type" use="optional" type="xlf:attrType_type"/>
      <xs:attribute ref="fs:fs" use="optional"/>
      <xs:attribute ref="fs:subFs" use="optional"/>
      <xs:attribute ref="slr:equivStorage" use="optional"/>
      <xs:attribute ref="slr:sizeInfo" use="optional"/>
      <xs:attribute ref="slr:sizeInfoRef" use="optional"/>
    </xs:complexType>  
  </xs:element>
  
  <xs:element name="pc">
    <!-- Paired Code -->
    <xs:complexType mixed="true">
      <xs:group ref="xlf:inline" minOccurs="0" maxOccurs="unbounded"/>
      <xs:attribute name="canCopy" use="optional" type="xlf:yesNo" default="yes"/>
      <xs:attribute name="canDelete" use="optional" type="xlf:yesNo" default="yes"/>
      <xs:attribute name="canOverlap" use="optional" type="xlf:yesNo"/>
      <xs:attribute name="canReorder" use="optional" type="xlf:yesNo" default="yes"/>
      <xs:attribute name="copyOf" use="optional" type="xs:NMTOKEN"/>
      <xs:attribute name="dispEnd" use="optional"/>
      <xs:attribute name="dispStart" use="optional"/>
      <xs:attribute name="equivEnd" use="optional"/>
      <xs:attribute name="equivStart" use="optional"/>
      <xs:attribute name="id" use="required" type="xs:NMTOKEN"/>
      <xs:attribute name="dataRefEnd" use="optional"/>
      <xs:attribute name="dataRefStart" use="optional"/>
      <xs:attribute name="subFlowsEnd" use="optional" type="xs:NMTOKENS"/>
      <xs:attribute name="subFlowsStart" use="optional" type="xs:NMTOKENS"/>
      <xs:attribute name="subType" use="optional" type="xlf:userDefinedValue"/>
      <xs:attribute name="type" use="optional" type="xlf:attrType_type"/>
      <xs:attribute name="dir" use="optional" type="xlf:dirValue"/>
      <xs:attribute ref="fs:fs" use="optional"/>
      <xs:attribute ref="fs:subFs" use="optional"/>
      <xs:attribute ref="slr:storageRestriction" use="optional"/>
      <xs:attribute ref="slr:sizeRestriction" use="optional"/>
      <xs:attribute ref="slr:equivStorage" use="optional"/>
      <xs:attribute ref="slr:sizeInfo" use="optional"/>
      <xs:attribute ref="slr:sizeInfoRef" use="optional"/>
    </xs:complexType>  
  </xs:element>
  
  <xs:element name="cp">
    <!-- Code Point -->
    <xs:complexType mixed="false">
      <xs:attribute name="hex" use="required"/>
      <xs:attribute ref="fs:fs" use="optional"/>
      <xs:attribute ref="fs:subFs" use="optional"/>
    </xs:complexType>    
  </xs:element>
  
  <xs:element name="mrk">
    <!-- Annotation Marker -->
    <xs:complexType mixed="true">
      <xs:group ref="xlf:inline" minOccurs="0" maxOccurs="unbounded"/>
      <xs:attribute name="id" use="required" type="xs:NMTOKEN"/>
      <xs:attribute name="translate" use="optional" type="xlf:yesNo" default="yes"/>
      <xs:attribute name="type" use="optional" type="xlf:attrType_type"/>
      <xs:attribute name="ref" use="optional" type="xs:anyURI"/>
      <xs:attribute name="value" use="optional"/>
      <xs:attribute ref="fs:fs" use="optional"/>
      <xs:attribute ref="fs:subFs" use="optional"/>
      <xs:attribute ref="slr:storageRestriction" use="optional"/>
      <xs:attribute ref="slr:sizeRestriction" use="optional"/>
      <xs:anyAttribute namespace="##any" processContents="skip"/>
    </xs:complexType>  
  </xs:element>

  <xs:element name="sm">
    <!-- Start Annotation Marker -->
    <xs:complexType mixed="false">
      <xs:attribute name="id" use="required" type="xs:NMTOKEN"/>
      <xs:attribute name="translate" use="optional" type="xlf:yesNo" default="yes"/>
      <xs:attribute name="type" use="optional" type="xlf:attrType_type"/>
      <xs:attribute name="ref" use="optional" type="xs:anyURI"/>
      <xs:attribute name="value" use="optional"/>
      <xs:attribute ref="fs:fs" use="optional"/>
      <xs:attribute ref="fs:subFs" use="optional"/>
      <xs:attribute ref="slr:storageRestriction" use="optional"/>
      <xs:attribute ref="slr:sizeRestriction" use="optional"/>
      <xs:anyAttribute namespace="##any" processContents="skip"/>
    </xs:complexType>  
  </xs:element>

  <xs:element name="em">
    <!-- End Annotation Marker -->
    <xs:complexType mixed="false">
      <xs:attribute name="startRef" use="required"/>
    </xs:complexType>  
  </xs:element>

</xs:schema>

Appendix B Translation Candidates Module

The source text of a document can be pre-processed against various translation resources (TM, MT, etc.) to provide translation candidates. This module provides an XLIFF capability to store lists of possible translations along with information about the similarity of the match, the quality of the translation, its provenance, etc.

B.1 Module Specification

B.1.1 Module Namespace

The namespace for the Translation Candidates module is: urn:oasis:names:tc:xliff:matches:2.0

B.1.2 Module Elements

The elements defined in the Translation Candidates module are: <matches> and <match>.

B.1.2.1 Tree Structure

Legend:

1 = one
+ = one or more
? = zero or one
* = zero, one or more
<matches>
|
+---<match> +
  |
  +---<xlf:source> 1
  |
  +---<xlf:target> 1
  |
  +---<xlf:originalData> ?
  |
  +---<mda:metadata> ?
  |
  +---<any> *

  
B.1.2.2 matches

Collection of matches retrieved from any leveraging system (MT, TM, etc.)

Contains:

- One or more <match> elements
B.1.2.3 match

A potential translation suggested for a part of the source content of the enclosing <unit> element.

Contains:

- One <source> element followed by
- One <target> element followed by
- Zero or one <originalData> element followed by
- Zero or one <mda:metadata> element.
- Zero, one or more elements from any namespace.

Attributes:

- id, REQUIRED
- origin, OPTIONAL
- similarity, OPTIONAL
- matchQuality, OPTIONAL
- matchSuitability, OPTIONAL
- type, OPTIONAL
- subTtype, OPTIONAL
- reference, OPTIONAL
- attributes from any namespace, OPTIONAL

Constraints

  • When a <target> element is a child of <match> and the reference attribute is set to yes, the OPTIONAL xml:lang attribute's value is not REQUIRED to be equal to the value of the trgLang attribute of the enclosing <xliff> element.

B.1.3 Module Attributes

The attributes defined in the Translation Candidates module are: id, similarity, matchQuality, matchSuitability, origin, type, subtype and reference.

B.1.3.1 id

Identifier - a character string used to identify a <match> element.

Value description: NMTOKEN.

Default value: undefined

Used in: <match>.

Constraints

  • The id value MUST be unique within the enclosing <matches> element.

B.1.3.2 similarity

Similarity - indicates the similarity level between the content of the <source> child of a <match> element and the translatable text being matched.

Value description: a decimal number between 0.0 and 100.0.

Default value: undefined

Used in: <match>.

B.1.3.3 matchQuality

Match quality - indicates the quality of the <target> child of a <match> element based on an external benchmark or metric.

Value description: a decimal number between 0.0 and 100.0.

Default value: undefined

Used in: <match>.

Note

This attribute can carry a human review based metrics score, a Machine Translation self-reported confidence score etc.

B.1.3.4 matchSuitability

Match suitability - indicates the general suitability and relevance of its <match> element based on various external benchmarks or metrics pertaining to both the <source> and the <target> children of the <match>.

This attribute is intended to carry a value that can be combined from values provided in similarity and matchQuality attributes based on an externally provided algorithm.

Value description: a decimal number between 0.0 and 100.0.

Default value: undefined

Used in: <match>.

Note

This attribute is also useful for mapping match-quality as specified in XLIFF 1.2 becuase 1.2 is not capable of discerning between the source similarity and the target quality.

Processing Requirements

  • Agents processing this module MUST make use of matchSuitability for match ordering purposes if the attribute is specified.

B.1.3.5 origin

Match origin - indicates the tool, system or repository that generated a <match> element. This is a free text short informative description. For example, 'Microsoft Translator Hub' or 'tm-client123-v456', or 'MSTH (52217d25-d9e7-54a2-af44-3d4e4341d112_healthc).'

Value description: Text.

Default value: undefined

Used in: <match>.

B.1.3.6 type

Type - indicates the type of a <match> element, it gives the value providing additional information on how the match was generated or qualifying further the relevance of the match. The list of pre-defined values is general and user-specific information can be added using the subtype attribute.

Value description:

Table B.1. Standard Values

ValueDescription
amAssembled Match: candidate generated by assembling parts of different translations. For example: constructing a candidate by using the known translations of various spans of content of the source.
mtMachine Translation: candidate generated by a machine translation system.
icmIn Context Match: candidate for which the content context of the translation was the same as the one of the current source. For example: the source text for both contents is also preceded and/or followed by an identical source segment, or both appear as e.g. level 2 headings.
idmIdentifier-based Match: candidate that has an identifier identical to the one of the source content. For example: the previous translation of a given UI component with the same ID. match that has an identifier identical to the source content.
tbTerm Base: candidate obtained from a terminological database, i.e. the whole source segment matches with a source term base entry.
tmTranslation Memory: candidate based on a simple match of the source content.
otherCandidate of a top level type not covered by any of the above definitions.
  • Default value: tm

Used in: <match>

Processing Requirements

  • Writers updating the attribute type MUST also update or delete subType .

B.1.3.7 subType

Sub-type - indicates the sub-type, i.e. a secondary level type, of a <match> element.

Value description:

The value is composed of a prefix and a sub-value separated by a character : (U+003A). The prefix is a string uniquely identifying a collection of values for a specific authority. The sub-value is any string value defined by an authority.

The prefix xlf is reserved for this specification, but no sub-values are defined for it at this time. Other prefixes and sub-values MAY be defined by the users.

  • Default value: undefined

Used in: <match>

Constraints

  • If the attribute subtype is used, the attribute type MUST be specified as well.

Processing Requirements

  • Writers updating the attribute type MUST also update or delete subType .

B.1.3.8 reference

Reference - indicates that the <target> child of the <match> element contains a Translation into a reference language rather than into the target langauge. For example, a German translation can be used as reference by a Luxembourgish translator.

Value description: Yes or No.

Default value: No.

Used in: <match>

B.1.4 Example:

<mtc:matches>
   <mtc:match id="[NMTOKEN]">
      <xlf:source>
         <!-- text data -->
      </xlf:source>
      <xlf:target>
         <!-- text data -->
      </xlf:target>
      <xlf:originalData>
         <xlf:data id="[NMTOKEN]">
            <xlf:cp hex="[required]">
               <!-- text data -->
            </xlf:cp>
         </xlf:data>
      </xlf:originalData>
      <mda:metadata>
         <mda:metagroup>
            <!-- One or more of mda:metagroup or mda:meta -->
         </mda:metagroup>
      </mda:metadata>
      <!-- Zero, one or more elements from any namespace -->
   </mtc:match>
</mtc:matches>
      

B.1.5 XML Schema

The schema listed below for reading convenience is accessible at http://docs.oasis-open.org/xliff/xliff-core/v2.0/csprd02/schemas/modules/matches.xsd.

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" 
    elementFormDefault="qualified"
    xmlns:mtc="urn:oasis:names:tc:xliff:matches:2.0"
    xmlns:mda="urn:oasis:names:tc:xliff:metadata:2.0"
    xmlns:xlf="urn:oasis:names:tc:xliff:document:2.0"
    targetNamespace="urn:oasis:names:tc:xliff:matches:2.0">
    
    <xs:import namespace="urn:oasis:names:tc:xliff:document:2.0"
        schemaLocation="../xliff_core_2.0.xsd"/>
    <xs:import namespace="urn:oasis:names:tc:xliff:metadata:2.0"
        schemaLocation="metadata.xsd"/>

    <xs:simpleType name="similarity">
        <xs:restriction base="xs:decimal">
            <xs:minInclusive value="0.0"/>
            <xs:maxInclusive value="100.0"/>
        </xs:restriction>
    </xs:simpleType>
    
    <xs:simpleType name="typeValues">
        <xs:restriction base="xs:string">
            <xs:enumeration value="am"/>
            <xs:enumeration value="ebm"/>
            <xs:enumeration value="idm"/>
            <xs:enumeration value="ice"/>
            <xs:enumeration value="mt"/>
            <xs:enumeration value="tm"/>
        </xs:restriction>
    </xs:simpleType>
    
    <!-- Elements for holding translaton candidates -->
    
    <xs:element name="matches">
        <xs:complexType>
            <xs:sequence>
                <xs:element minOccurs="1" maxOccurs="unbounded" 
                    ref="mtc:match"/>
            </xs:sequence>
        </xs:complexType>
    </xs:element>
    
    <xs:element name="match">
        <xs:complexType>
            <xs:sequence>
                <xs:element minOccurs="1" maxOccurs="1" ref="xlf:source"/>
                <xs:element minOccurs="1" maxOccurs="1" ref="xlf:target"/>
                <xs:element minOccurs="0" maxOccurs="1" ref="xlf:originalData"/>
                <xs:element minOccurs="0" maxOccurs="1" ref="mda:metadata"/>
                <xs:any maxOccurs="unbounded" minOccurs="0" namespace="##other" processContents="skip"/>
            </xs:sequence>
            <xs:attribute name="id" use="required" type="xs:NMTOKEN"/>
            <xs:attribute name="origin" use="optional"/>
            <xs:attribute name="similarity" use="optional" type="mtc:similarity"/>
            <xs:attribute name="matchQuality" use="optional"/>
            <xs:attribute name="matchSuitability" use="optional"/>
            <xs:attribute name="type" use="optional" type="xlf:attrType_type"/>
            <xs:attribute name="subTtype" use="optional"/>
            <xs:attribute name="reference" use="optional"/>
            <xs:anyAttribute namespace="##any" processContents="skip"/>
        </xs:complexType>
    </xs:element>
    
</xs:schema>

Appendix C Glossary Module

Simple glossaries, consisting of a list of terms with a definition or translation, can be optionally embedded in an XLIFF document using the namespace mechanism to include elements from the Glossary module.

C.1 Module Specification

C.1.1 Module Namespace

The namespace for the Glossary module is: urn:oasis:names:tc:xliff:glossary:2.0

C.1.2 Module Elements

The elements defined in the Glossary module are: <glossary>, <glossentry>, <term>, <translation> and <definition>.

C.1.2.1 Tree Structure

Legend:

1 = one
+ = one or more
? = zero or one
* = zero, one or more
<glossary>
|
+---<glossentry> +
  |
  +---<term> 1
  |
  +---<translation> *
  |
  +---<definition> ?
  |
  +---<any> *

  
C.1.2.2 glossary

Container for a list of glossary terms.

Contains:

- One or more <glossentry> elements.
C.1.2.3 glossentry

Glossary entry.

Contains:

One <term> element followed by
Zero, one, or more <translation> elements followed by
Zero or one <definition> element followed by
Zero, one, or more elements from any namespace.

Attributes:

- id , OPTIONAL
- attributes from any namespace, OPTIONAL

Constraints

C.1.2.4 term

A term in the glossary, expressed in the source language of the enclosing <xliff> element.

Contains:

Plain text.

Attributes:

- source , OPTIONAL
- attributes from any namespace, OPTIONAL
C.1.2.5 translation

A translation of the sibling <term> element expressed in the target language of the enclosing <xliff> element. Multiple translations can be specified as synonyms.

Contains:

Plain text.

Attributes:

- id, OPTIONAL
- source, OPTIONAL
- attributes from any namespace, OPTIONAL
C.1.2.6 definition

Optional definition in plain text for the term stored in the sibling <term> element.

Contains:

- Plain text.

Attributes:

- source , OPTIONAL
- attributes from any namespace, OPTIONAL

C.1.3 Module Attributes

The attribues defined in the Glossary module are: id, and source

C.1.3.1 id

Identifier - a character string used to identify a <glossentry> or <translation> element.

Value description: NMTOKEN

Default value: undefined

Used in:<glossentry> and <translation>

C.1.3.2 source

Source - indicates the source of the content for the enclosing element.

Value description: Text.

Default value: undefined

Used in:<term>, <translation>, and <definition>.

C.1.4 Example:

<unit id="1">
  <segment>
    <source>Press the <mrk id="m1" type="term" ref="#g1">TAB key</mrk>.</source>
  </segment>
  <gls:glossary>
    <gls:glossentry id="g1">
      <gls:term source="publicTermbase">TAB key</gls:term>
      <gls:translation id="1" source="myTermbase">Tabstopptaste</gls:translation>
      <gls:translation id="2" source="myTermbase">TAB-TASTE</gls:translation>
      <gls:definition source="publicTermbase">A keyboard key that is traditionally used to insert tab characters into a document.</gls:definition>
    </gls:glossentry>
  </gls:glossary>  
</unit>

C.1.5 XML Schema

The schema listed below for reading convenience is accessible at http://docs.oasis-open.org/xliff/xliff-core/v2.0/csprd02/schemas/modules/glossary.xsd.

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"
    xmlns:gls="urn:oasis:names:tc:xliff:glossary:2.0"
    targetNamespace="urn:oasis:names:tc:xliff:glossary:2.0">

    <xs:import namespace="http://www.w3.org/XML/1998/namespace"
        schemaLocation="http://www.w3.org/2001/xml.xsd"/>

    <!-- Elements for holding simple glossary data -->

    <xs:element name="glossary">
        <xs:complexType mixed="false">
            <xs:sequence>
                <xs:element minOccurs="1" maxOccurs="unbounded" ref="gls:glossentry" />
            </xs:sequence>
        </xs:complexType>
    </xs:element>

    <xs:element name="glossentry">
        <xs:complexType>
            <xs:sequence>
                <xs:element minOccurs="1" maxOccurs="1" ref="gls:term"/>
                <xs:element minOccurs="0" maxOccurs="unbounded" ref="gls:translation" />
                <xs:element minOccurs="0" maxOccurs="1" ref="gls:definition" />
                <xs:any maxOccurs="unbounded" minOccurs="0" namespace="##other" processContents="skip"/>
            </xs:sequence>
            <xs:attribute name="id" use="optional" type="xs:NMTOKEN"/>
            <xs:anyAttribute namespace="##any" processContents="skip"/>
        </xs:complexType>
    </xs:element>

    <xs:element name="term">
        <xs:complexType mixed="true">
            <xs:attribute name="source" use="optional"/>
            <xs:anyAttribute namespace="##any" processContents="skip"/>
        </xs:complexType>
    </xs:element>

    <xs:element name="translation">
        <xs:complexType mixed="true">
            <xs:attribute name="id" use="optional" type="xs:NMTOKEN"/>
            <xs:attribute name="source" use="optional"/>
            <xs:anyAttribute namespace="##any" processContents="skip"/>
        </xs:complexType>
    </xs:element>

    <xs:element name="definition">
        <xs:complexType mixed="true">
            <xs:attribute name="source" use="optional"/>
            <xs:anyAttribute namespace="##any" processContents="skip"/>
        </xs:complexType>
    </xs:element>

</xs:schema>

Appendix D Format Style Module

This is intended as a namespace mechanism to carry inside an XLIFF document information needed for generating a quick at a glance html preview of XLIFF content using a predefined set of simple html formatting elements.

D.1 Module Specification

Format Style module consists of just two attributes: fs and subFs. It does not specify any elements.

Format Style allows most structural and inline XLIFF core elements to convey basic formatting information using a predefined subset of HTML formatting elements. It primarily enables the generation of HTML pages or snippets for preview and review purposes. It MUST NOT be used to prescibe a roundtrip to a source document format.

The fs attribute holds the name of an HTML formatting element. If additional style information is needed, the OPTIONAL subFs attribute is provided.

Constraints

  • The Format Style attributes MUST be configured in such a way that the HTML [HTML5] snippet resulting at the <file> level is valid.

Processing Requiremenets

Note

The above constraint and validation method will make sure that the snippets are renderable by standard HTML browsers.

D.1.1 Module Namespace

The namespace for the Format style module is: urn:oasis:names:tc:xliff:fs:2.0

D.1.2 Module Attributes

The attributes defined in the Format Style module are: fs, subFs.

D.1.2.1 fs

Format style attribute, fs - allows most structural and inline XLIFF core elements to convey basic formatting information using a predefined subset of HTML formatting elements (for example, HTML elements names like <script> are not included). It enables the generation of HTML pages or snippets for preview and review purposes. If additional style information is needed, the OPTIONAL subFs attribute is provided.

Value description:

Table D.1. fs attribute values

aanchor
b bold text style
bdo I18N BiDi over-ride
big large text style
blockquote long quotation
body document body
br forced line break
button push button
caption table caption
center shorthand for DIV align=center
cite citation
code computer code fragment
col table column
colgroup table column group
dd definition description
del deleted text
div generic language/style container
dl definition list
dt definition term
em emphasis
h1 heading
h2 heading
h3 heading
h4 heading
h5 heading
h6 heading
head document head
hr horizontal rule
html document root element
i italic text style
imgimage
label form field label text
legend fieldset legend
li list item
ol ordered list
p paragraph
pre preformatted text
q short inline quotation
s strike-through text style
samp sample program output, scripts, etc.
select option selector
small small text style
span generic language/style container
strike strike-through text
strong strong emphasis
sub subscript
sup superscript
table
tbody table body
td table data cell
tfoot table footer
th table header cell
thead table header
title document title
tr table row
tt teletype or monospaced text style
u underlined text style
ul unordered list

Default value: undefined.

Used in: <file>, <unit>, <ignorable>, <notes>, <note>, <originalData>, <data>, <cp>, <sc>, <ec>, <ph>, <pc>, <mrk>, <sm> and <em>.

Warning

The fs attribute is not intended to facilitate Merging back into the original format.

Processing Requirements

  • Writers updating the attribute fs MUST also update or delete subFs.

Example:To facilitate HTML preview, fs can be applied to XLIFF like this like:

<xliff>
 <file fs:fs="html"> 
  <unit id="1" fs:fs="p">
   <segment>
    <source>Mick Jones renewed his interest in the Vintage  <pc id="1" fs:fs="strong">'72 Telecaster Thinline </pc> guitar. <x fs:fs="br" />He says <pc fs:fs="q">I love 'em</pc> <x fs:fs="img" fs:subFs="src,smileface.png" /></source>
  </segment>
  </unit>
 </file>
</xliff>

With an XSL stylesheet like this:

<xsl:template match="*" priority="2">
 <xsl:choose>
  <xsl:when test="@fs:fs">
   <xsl:element name="{@fs:fs}">
    <xsl:if test="@fs:subFs">
	 <xsl:variable name="att_name" select="substring-before(@fs:subFs,',')" />
	 <xsl:variable name="att_val" select="substring-after(@fs:subFs,',')" />
	 <xsl:attribute name="{$att_name}">
	  <xsl:value-of select="$att_val" />
	 </xsl:attribute>
	</xsl:if>
    <xsl:apply-templates />
   </xsl:element>
  </xsl:when>
  <xsl:otherwise>
   <xsl:apply-templates />  
  </xsl:otherwise> 
 </xsl:choose>
</xsl:template>

You can generate a an HTML page like this:

<html>
   <p>Mick Jones renewed his interest in the Vintage  <strong>'72 Telecaster Thinline </strong> guitar. <br/>He says <q>I love 'em</q>
      <img src="smileface.png"/>
   </p>
</html>
D.1.2.2 subFs

Sub-format style, subFs - allows extra metadata, like URL for example, to be added in concert with the fs attribute.

Value description: The subFs MUST only be used to carry attribute name/value comma-delimited pairs for attributes that are valid for the HTML element identified by the accompanied fs attribute.

Example: fs:fs="img" fs:subFs="src,smileface.png".

Default value: undefined.

Used in: <file>, <unit>, <segment>, <ignorable>, <notes>, <note>, <originalData>, <data>, <source>, <target>, <cp>, <sc>, <ec>, <ph>, <pc>, <mrk>, <sm> and <em>.

Warning

The subFs attribute is not intended to facilitate Merging back into the original format.

Constraints

  • Commas (,) and backslashes (\) in the value parts of the subFs MUST be escaped with a backslash (\).

  • If the attribute subFs is used, the attribute fs MUST be specified as well.

Processing Requirements

  • Writers updating the attribute fs MUST also update or delete subFs.

Appendix E Metadata Module

The Metadata module provides a mechanism for storing custom metadata using elements that are part of the official XLIFF specification.

E.1 Module Specification

E.1.1 Module Namespace

The namespace for the Metadata module is: urn:oasis:names:tc:xliff:metadata:2.0

E.1.2 Module Elements

The elements defined in the Metadata module are: <metadata>, <metagroup>, and <meta>.

E.1.2.1 Tree Structure

Legend:

+ = one or more
<_metadata>
|
+---<metagroup> +
  |
  +---At least one of (<metagroup> or <meta>)
  |
  +---<meta> 

  
E.1.2.2 metadata

Container for metadata associated with the enclosing element.

Contains:

- One or more <metagroup> elements

Example: Metadata can be used to store XML attribute names and values for XLIFF Documents that do not use a skeleton. The following XML sample contains attributes on the <document> and <row> elements.

<document version="3" phase="draft">
   <table>
    <row style="head"><cell>Name</cell><cell>Position</cell></row>
	<row><cell>Patrick K.</cell><cell>Right Wing</cell></row>
	<row><cell>Bryan B.</cell><cell>Left Wing</cell></row>
   </table>
</document>

The Metadata module can be used to preserve these attributes for a round trip without using a skeleton:

<?xml version="1.0" encoding="utf-8"?>
<xliff xmlns:fs="urn:oasis:names:tc:xliff:fs:2.0"
       xmlns:mda="urn:oasis:names:tc:xliff:metadata:2.0"
       version="2.0"
       srcLang="en">
   <file>
      <group name="document">
         <group name="table">
            <group name="row">
               <unit id="u1" name="cell">
                  <segment>
                     <source>Name</source>
                  </segment>
               </unit>
               <unit id="u2" name="cell">
                  <segment>
                     <source>Position</source>
                  </segment>
               </unit>
               <mda:metadata>
                  <mda:metagroup category="row_xml_attribute">
                     <mda:meta type="style">head</mda:meta>
                  </mda:metagroup>
               </mda:metadata>
            </group>
            <group name="row">
               <unit id="u3" name="cell">
                  <segment>
                     <source>Patrick K.</source>
                  </segment>
               </unit>
               <unit id="u4" name="cell">
                  <segment>
                     <source>Right Wing</source>
                  </segment>
               </unit>
            </group>
            <group name="row">
               <unit id="u5" name="cell">
                  <segment>
                     <source>Bryan B.</source>
                  </segment>
               </unit>
               <unit id="u6" name="cell">
                  <segment>
                     <source>Left Wing</source>
                  </segment>
               </unit>
            </group>
         </group>
         <mda:metadata>
            <mda:metagroup category="document_xml_attribute">
               <mda:meta type="version">3</mda:meta>
               <mda:meta type="phase">draft</mda:meta>
            </mda:metagroup>
         </mda:metadata>
      </group>
   </file>
</xliff>
E.1.2.3 metagroup

Provides a way to organize metadata into a structured hierarchy.

Contains:

- One or more <metagroup> or <meta> elements in any order.

Attributes

- category, OPTIONAL
- appliesTo, OPTIONAL
E.1.2.4 meta

Contains:

- Untranslatable text

Attributes

- type, REQUIRED

E.1.3 Module Attributes

The attribues defined in the Metadata module are: category, type, and appliesTo.

E.1.3.1 category

category - indicates a category for metadata contained in the enclosing <metagroup> element.

Default value: undefined

Used in: <metagroup>.

E.1.3.2 type

type - indicates the type of metadata contained by the enclosing element.

Default value: undefined

Used in: <meta>.

E.1.3.3 appliesTo

Indicates the element to whom the content of the matagroup applies.

Value description: source, target, or ignorable.

Default value: undefined.

Used in: <metagroup>.

E.1.4 Example:

<mda:metadata>
   <mda:metagroup>
      <!-- One or more of mda:metagroup or mda:meta -->
   </mda:metagroup>
</mda:metadata>
      

E.1.5 XML Schema

The schema listed below for reading convenience is accessible at http://docs.oasis-open.org/xliff/xliff-core/v2.0/csprd02/schemas/modules/metadata.xsd.

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"
        xmlns:mda="urn:oasis:names:tc:xliff:metadata:2.0"
        targetNamespace="urn:oasis:names:tc:xliff:metadata:2.0">
        
    <xs:import namespace="http://www.w3.org/XML/1998/namespace"
            schemaLocation="http://www.w3.org/2001/xml.xsd"/>
        
        
    <!-- Elements for holding custom metadata -->

    <xs:element name="metadata">
        <xs:complexType mixed="false">
            <xs:sequence>
                <xs:element minOccurs="1" maxOccurs="unbounded" ref="mda:metagroup" />
            </xs:sequence>
        </xs:complexType>
    </xs:element>
    
    <xs:element name="metagroup">
        <xs:complexType>
            <xs:sequence>
              <xs:choice minOccurs="1" maxOccurs="unbounded">
                <xs:element ref="mda:metagroup"/>
                <xs:element ref="mda:meta"/>
              </xs:choice>
            </xs:sequence>
            <xs:attribute name="category" use="optional"/>
            <xs:attribute name="appliesTo" use="optional" type="xlf:appliesTo"/>
        </xs:complexType>
    </xs:element>
    
    <xs:element name="meta">
        <xs:complexType mixed="true">
            <xs:attribute name="type" use="required" type="xlf:attrType_type"/>
        </xs:complexType>
    </xs:element>
    
</xs:schema>

Appendix F Resource Data Module

The Resource Data module provides a mechanism for referencing external resource data that MAY need to be modified or used as contextual reference during translation.

F.1 Module Specification

F.1.1 Module Namespace

The namespace for the Resource Data module is: urn:oasis:names:tc:xliff:resourceData:2.0

F.1.2 Module Elements

The elements defined in the Resource Data module are: <resourceData>, <resourceItemRef>, <resourceItem>, <source>, <target>, and <reference>.

F.1.2.1 Tree Structure

Legend:

? = zero or one
* = zero, one or more
<resourceData>
|
+---<resourceItemRef> *
|
+---<resourceItem> *
  |
  +---<source> ?
  | |
  | +---<any> *
  |
  +---<target> ?
  | |
  | +---<any> *
  |
  +---<reference> *

  
F.1.2.2 resourceData

Parent container for resource data associated with the enclosing element.

Contains:

At least one of the following

- Zero, one or more <resourceItemRef> elements.
- Zero, one or more <resourceItem> elements.
F.1.2.3 resourceItemRef

Specifies a reference to an associated <resourceItem> element located at the <file> level.

Contains:

This element is always empty.

Attributes:

- id, OPTIONAL
- ref, REQUIRED
- attributes from any namespace, OPTIONAL

Constraints

  • The value of the OPTIONAL id attribute MUST be unique among all <resourceItemRef> children of the enclosing element.

Processing Requirements

F.1.2.4 resourceItem

Container for specific resource data that is either intended for Modification, or to be used as contextual reference during Translation.

Contains:

At least one of the following

- Zero or One <source> element followed by
- Zero or One <target> element followed by
- Zero, one, or more <reference> elements

Attributes:

- mimeType, OPTIONAL
- id, OPTIONAL
- context, OPTIONAL
- attributes from any namespace, OPTIONAL

Constraints

  • The mimeType attribute is REQUIRED if <target> and <source> child elements are empty, otherwise it is OPTIONAL.

  • The value of the OPTIONAL id attribute MUST be unique among all <resourceItem> children of the enclosing element.

Processing Requirements

F.1.2.5 source

References the actual resource data that is either intended for Modification, or to be used as contextual reference during Translation.

Contains:

Either

- XML elements from any namespace

or

- is empty.

Attributes:

- href, OPTIONAL
- xml:lang, OPTIONAL
- attributes from any namespace, OPTIONAL

Constraints

  • The attribute href is REQUIRED if and only if <source> is empty.

  • When the OPTIONAL xml:lang attribute is present, its value MUST be equal to the value of the srcLang attribute of the enclosing <xliff> element.

Processing Requirements

F.1.2.6 target

References the localized counterpart of the sibling <source> element.

Contains:

Either

- XML elements from any namespace

or

- is empty.

Attributes:

- href, OPTIONAL
- xml:lang, OPTIONAL
- attributes from any namespace, OPTIONAL

Constraints

  • The attribute href is REQUIRED if and only if <target> is empty.

  • When the OPTIONAL xml:lang attribute is present, its value MUST be equal to the value of the trgLang attribute of the enclosing <xliff> element.

Processing Requirements

F.1.2.7 reference

References contextual data relating to the sibling <source> and <target> elements, such as a German screenshot for a Luxembourgish translator.

Contains:

- This element is always empty.

Attributes:

- href, REQUIRED
- xml:lang, OPTIONAL
- attributes from any namespace, OPTIONAL

Constraints

  • When the OPTIONAL xml:lang attribute is present, its value does not need to be equal to the value of the srcLang or trgLang attribute of the enclosing <xliff> element.

Processing Requirements

F.1.3 Module Attributes

The attributes defined in the Resource Data module are: id, xml:lang, mimeType, context, href, and ref.

F.1.3.1 id

Identifier - A character string used to identify a <resourceData> element.

Value description: NMTOKEN

Default value: undefined

Used in:<resourceItem> and <resourceItemRef>

F.1.3.2 xml:lang

Language - The xml:lang attribute specifies the language variant of the text of a given element. For example: xml:lang="fr-FR" indicates the French language as spoken in France.

Value description: A language code as described in [BCP 47].

Default value: undefined

Used in: <source>, <target>, and <reference>.

F.1.3.3 mimeType

MIME type, mimeType - indicates the type of a resource object. This generally corresponds to the content type of [RFC 2045], the MIME specification; e.g. mimeType="text/xml" indicates the resource data is a text file of XML format.

Value description: A MIME type. An existing MIME type MUST be used from a list of standard values.

Default value: undefined

Used in:<resourceItem>

Note

If you cannot use any of the standard MIME type values as specified above, a new MIME type can be registered according to [RFC 2048].

F.1.3.4 context

Contextual Information - Indicates whether an external resource is to be used for context only and not modified.

Value description: yes or no

Default value: yes

Used in:<resourceItem>

F.1.3.5 href

Hypertext Reference, href - IRI referencing an external resource.

Value description: IRI.

Default value: undefined

Used in:<source>, <target>, and <reference>

F.1.3.6 ref

Resource Item Reference - holds a reference to an associated <resourceItem> element located at the <file> level.

Value description: An [XML Schema Datatypes] NMTOKEN

Default value: undefined

Used in:<resourceItemRef>

Constraints

  • The ref attribute value MUST be the value of the id attribute of the <resourceItem> element being referenced.

F.1.4 Examples:

In this example, the <resourceData> module at <file> level references external XML that contains resource data for a user interface control. The control is the container for the text “Load Registry Config” and needs to be resized to accommodate the increased length of the string due to translation. The <resourceItemRef> element contained in the <resourceData> module at <unit> level provides the reference between them. The name attribute of the <unit> element could serve as the key for an editor to associate <source> and <target> text with the resource data contained in the referenced XML and display it for modification.

<file>
  <res:resourceData>
    <res:resourceItem id="r1" mimeType="text/xml" context="no">
      <res:source href="resources\en\registryconfig.resources.xml" />
      <res:target href="resources\de\registryconfig.resources.xml" />
    </res:resourceItem>  
  </res:resourceData>
  <unit id="1" name="130;WIN_DLG_CTRL_">
    <segment id="1" state="translated">
      <source>Load Registry Config</source>
      <target>Registrierungskonfiguration laden</target>
    </segment>
    <res:resourceData>
      <res:resourceItemRef ref="r1" />
    </res:resourceData>    
  </unit>
</file>

In this example, the <resourceData> module at the <unit> level contains elements from another namespace (abc), which could be displayed for modification in an editor that understands how to process the namespace.

<file>
  <unit id="1">
    <segment id="1" state="translated">
      <source>Load Registry Config</source>
      <target>Registrierungskonfiguration laden</target>
    </segment>
    <res:resourceData>
      <res:resourceItem id="r1" context="no">
        <res:source>
          <abc:resourceType>button</abc:resourceType>
          <abc:resourceHeight>40</abc:resourceHeight>
          <abc:resourceWidth>75</abc:resourceWidth>
        </res:source>
        <res:target>
          <abc:resourceType>button</abc:resourceType>
          <abc:resourceHeight>40</abc:resourceHeight>
          <abc:resourceWidth>150</abc:resourceWidth>
        </res:target>
      </res:resourceItem>
    </res:resourceData>
  </unit>
</file>

In this example, the <resourceData> module references multiple static images that an editor can make use of as context while translating or reviewing.

     
<file>
  <res:resourceData>
    <res:resourceItem id="r1" mimeType="image/jpeg" context="yes">
      <res:source xml:lang="en-us" href="resources\en\registryconfig1.resources.jpg" />
      <res:target xml:lang="lb-lu" href="resources\lb\registryconfig1.resources.jpg" />
      <res:reference xml:lang="de-de" href="resources\de\registryconfig1.resources.jpg" />
    </res:resourceItem> 
    <res:resourceItem id="r2" mimeType="image/jpeg" context="yes">
      <res:source xml:lang="en-us" href="resources\en\registryconfig2.resources.jpg" />
      <res:target xml:lang="lb-lu" href="resources\lb\registryconfig2.resources.jpg" />
    </res:resourceItem> 
  </res:resourceData>
  <unit id="1">
    <segment id="1" state="translated">
      <source>Remove Registry Config</source>
      <target>Registrierungskonfiguration entfernen</target>
    </segment>
    <res:resourceData>
      <res:resourceItemRef ref="r1" />
      <res:resourceItemRef ref="r2" />
    </res:resourceData>  
  </unit>
</file>

F.1.5 XML Schema

The schema listed below for reading convenience is accessible at http://docs.oasis-open.org/xliff/xliff-core/v2.0/csprd02/schemas/modules/resource_data.xsd.

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"
    xmlns:res="urn:oasis:names:tc:xliff:resourcedata:2.0"
    targetNamespace="urn:oasis:names:tc:xliff:resourcedata:2.0">

    <xs:import namespace="http://www.w3.org/XML/1998/namespace"
        schemaLocation="http://www.w3.org/2001/xml.xsd"/>

    <xs:element name="resourceItemRef">
      <xs:complexType mixed="false">
        <xs:attribute name="id" use="optional" type="xs:NMTOKEN"/>
        <xs:attribute name="ref" use="required" type="xs:anyURI"/>
        <xs:anyAttribute namespace="##any" processContents="skip"/>
      </xs:complexType>
    </xs:element>

    <xs:element name="resourceData">
      <xs:complexType>
        <xs:sequence>
          <xs:element minOccurs="0" maxOccurs="1" ref="res:source"/>
          <xs:element minOccurs="0" maxOccurs="1" ref="res:target"/>
          <xs:element minOccurs="0" maxOccurs="unbounded" ref="res:reference"/>
        </xs:sequence>
        <xs:attribute name="id" use="optional" type="xs:NMTOKEN"/>
        <xs:attribute name="mimeType" use="required"/>
        <xs:attribute name="context" use="optional"/>
        <xs:anyAttribute namespace="##any" processContents="skip"/>
      </xs:complexType>
    </xs:element>

    <xs:element name="source">
      <xs:complexType mixed="false">
        <xs:sequence>
          <xs:any maxOccurs="unbounded" minOccurs="0" namespace="##other" processContents="skip"/>
        </xs:sequence>
        <xs:attribute name="href" use="optional"/>
        <xs:attribute ref="xml:lang" use="optional"/>
        <xs:anyAttribute namespace="##any" processContents="skip"/>
      </xs:complexType>
    </xs:element>

    <xs:element name="target">
      <xs:complexType mixed="false">
        <xs:sequence>
          <xs:any maxOccurs="unbounded" minOccurs="0" namespace="##other" processContents="skip"/>
        </xs:sequence>
        <xs:attribute name="href" use="optional"/>
        <xs:attribute ref="xml:lang" use="optional"/>
        <xs:anyAttribute namespace="##any" processContents="skip"/>
      </xs:complexType>
    </xs:element>

    <xs:element name="reference">
      <xs:complexType mixed="false">
        <xs:attribute name="href" use="required"/>
        <xs:attribute ref="xml:lang" use="optional"/>
        <xs:anyAttribute namespace="##any" processContents="skip"/>
      </xs:complexType>
    </xs:element>

</xs:schema>

Appendix G Change Tracking Module

The Change Tracking module is used to store revision information for XLIFF elements and attributes.

G.1 Module Specification

G.1.1 Module Namespace

The namespace for the Change Tracking module is: urn:oasis:names:tc:xliff:changeTracking:2.0

G.1.2 Module Elements

The elements defined in the Change Tracking module are: <changeTrack>, <revisions>, <revision>, and <item>.

G.1.2.1 Tree Structure

Legend:

+ = one or more
<changeTrack>
|
+---<revisions> +
  |
  +---<revision> +
    |
    +---<item> +

  
G.1.2.2 changeTrack

Parent container for change tracking information associated with a sibling element, or a child of a sibling element, to the change track module within the scope of the enclosing element.

Contains:

- One or more <revisions> elements.
G.1.2.3 revisions

Container for logical groups of revisions associated with a sibling element, or a child of a sibling element, to the change track module within the scope of the enclosing element.

Contains:

- One or more <revision> elements.

Attributes:

- appliesTo, REQUIRED
- ref, OPTIONAL
- currentVersion, OPTIONAL
- attributes from any namespace, OPTIONAL

Processing Requirements

  • Modifying agents MAY create <revisions> elements with attributes.

  • Modifying agents SHOULD NOT modify <revisions> and its attributes defined in this module, except in the case where the currentVersion attribute is used. This attribute SHOULD be updated when a new revision becomes the most current.

  • Modifying agents SHOULD NOT remove <revisions> and its attributes defined in this module.

  • When the appliesTo attribute refers to an element that is a multiple instance within the enclosing element, the ref attribute MUST be used to reference an individual instance if and only if the referenced instance has an id. Using <notes> as an example:

          <notes>
            <note id="n1">new note</note>
            <note id="n2">another note</note>  
          </notes>
          <ctr:changeTrack>
            <ctr:revisions appliesTo="note" ref="n1">
              <ctr:revision>
                <ctr:item property="content">old note</item>
              </ctr:revision>
            </ctr:revisions>
          </ctr:changeTrack>
          
G.1.2.4 revision

Container for specific revisions associated with a sibling element, or a child of a sibling element, to the change track module within the scope of the enclosing element.

Contains:

- One or more <item> elements.

Attributes:

- author, OPTIONAL
- datetime, OPTIONAL
- version, OPTIONAL
- attributes from any namespace, OPTIONAL

Processing Requirements

  • Modifying agents MAY create <revision> elements with attributes.

  • Modifying agents SHOULD NOT modify <revision> and its attributes defined in this module.

  • Modifying agents MAY remove <revision> and its attributes defined in this module if and only if there is more than one instance of <revision> present. For example, a user agent can decide to preserve only the most current revision.

G.1.2.5 item

Container for a specific revision associated with a sibling element, or a child of a sibling element, to the change track module within the scope of the enclosing element.

Contains:

- Text.

Attributes:

- property, REQUIRED
- attributes from any namespace, OPTIONAL

Processing Requirements

  • Modifying agents MAY create <item> elements with attributes.

  • Modifying agents SHOULD NOT modify <item> and its attribute defined in this module.

  • Modifying agents SHOULD NOT remove <item> and its attribute defined in this module, unless they are removed as part of a <revision> elemnent removed according to its own processing requirements.

G.1.3 Module Attributes

The attributes defined in the Change Tracking module are: appliesTo, author, currentVersion, datetime, ref, property, and version.

G.1.3.1 appliesTo

appliesTo – Indicates a specific XLIFF element which is a sibling, or a child of a sibling element, to the change track module within the scope of the enclosing element.

Value description: Any valid XLIFF element which is a sibling, or a child of a sibling element, to the change track module within the scope of the enclosing element.

Default value: undefined

Used in:<revisions>

G.1.3.2 author

author - Indicates the user or agent that created or modified the referenced element or its attributes.

Value description: Text.

Default value: undefined

Used in:<revision>.

G.1.3.3 currentVersion

currentVersion - holds a reference to the most current version of a revision.

Value description: An [XML Schema Datatypes] NMTOKEN

Default value: none

Used in:<revisions>.

Constraints

G.1.3.4 datetime

Date and Time, datetime - Indicates the date and time the referenced element or its attributes were created or modified.

Value description: Date in one of the formats defined in [NOTE-datetime].

Default value: undefined

Used in:<revision>.

G.1.3.5 ref

Reference - Holds a reference to a single instance of an element that has multiple instances within the enclosing element.

Value description: An [XML Schema Datatypes] NMTOKEN

Default value: undefined

Used in:<revisions>

Constraints

  • The value of the ref attribute MUST be the value of the id attribute of a single instance of an element that is a multiple instance within the enclosing element.

G.1.3.6 property

property – Indicates the type of revision data.

Value description: The value MUST be either content to signify the content of an element, or the name of the attribute relating to the revision data.

Default value: none

Used in:<item>.

G.1.3.7 version

version - Indicates the version of the referenced element or its attributes that were created or modified.

Value description: NMTOKEN.

Default value: undefined

Used in:<revision>.

G.1.4 Example:

The following example shows change tracking for <source>, <target>, and <notes>. Current and previous versions are both stored in the Change Tracking module.

 
<unit id="1">
    <segment>
      <source>Hello World</source>
      <target>Guten Tag Welt</target> 
    </segment>
    <notes>
      <note category="instruction" id="n1">The translation should be formal</note>
      <note category="comment" id="n2">Please Review my translation</note>
    </notes>
    <changeTrack>
      <revisions appliesTo="source" currentVersion="r1">
        <revision author="system" datetime="2013-07-15T10:00:00+8:00" version="r1">
          <item property="content">Hello World</item>>
        </revision>
        <revision author="system" datetime="2013-06-15T10:00:00+8:00" version="r2">
          <item property="content">Hello</item>>
        </revision>
        <revision author="system" datetime="2013-05-15T10:00:00+8:00" version="r3">
          <item property="content">Hi</item>
        </revision>
      </revisions>
      <revisions appliesTo="target" currentVersion="r1">
       <revision author="Frank" datetime="2013-07-17T11:00:00+8:00" version="r1">
          <item property="content">Guten Tag Welt</item>
        </revision>
        <revision author="Frank" datetime="2013-06-17T11:00:00+8:00" version="r2">
          <item property="content">Hallo</item>
        </revision>
        <revision author="Frank" datetime="2013-05-17T11:00:00+8:00" version="r3">
          <item property="content">Grüsse</item>
        </revision>
      </revisions>
      <revisions appliesTo="note" nid="n1" currentVersion="r1">
        <revision author="Bob" datetime="2013-07-16T10:30:00+8:00" version="r1">
          <item property="content">The translation should be formal</item>
          <item property="category">instruction</item>
        </revision>
        <revision author="Bob" datetime="2013-05-16T10:30:00+8:00" version="r2">
          <item property="content">The translation should be informal</item>
          <item property="category">comment</item>
        </revision>
      </revisions>
      <revisions appliesTo="note" nid="n2" currentVersion="r1">
        <revision author="Bob" datetime="2013-07-18T10:30:00+8:00" version="r1">
          <item property="content">Please Review my translation</item>
        </revision>
      </revisions>
    </changeTrack>
 </unit>

G.1.5 XML Schema

The schema listed below for reading convenience is accessible at http://docs.oasis-open.org/xliff/xliff-core/v2.0/csprd02/schemas/modules/change_tracking.xsd.

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"
    xmlns:ctr="urn:oasis:names:tc:xliff:changetracking:2.0"
    targetNamespace="urn:oasis:names:tc:xliff:changetracking:2.0">

    <xs:import namespace="http://www.w3.org/XML/1998/namespace"
        schemaLocation="http://www.w3.org/2001/xml.xsd"/>

    <xs:element name="changeTrack">
      <xs:complexType>
        <xs:sequence>
          <xs:element minOccurs="1" maxOccurs="unbounded" ref="ctr:revisions"/>
        </xs:sequence>
      </xs:complexType>
    </xs:element>

    <xs:element name="revisions">
      <xs:complexType>
        <xs:sequence>
          <xs:element minOccurs="1" maxOccurs="unbounded" ref="ctr:revision"/>
        </xs:sequence>
        <xs:attribute name="appliesTo" use="required" type="xlf:appliesTo"/>
        <xs:attribute name="ref" use="optional" type="xs:anyURI"/>
        <xs:attribute name="currentVersion" use="optional"/>
        <xs:anyAttribute namespace="##any" processContents="skip"/>
      </xs:complexType>
    </xs:element>

    <xs:element name="revision">
      <xs:complexType>
        <xs:sequence>
          <xs:element minOccurs="1" maxOccurs="unbounded" ref="ctr:item"/>
        </xs:sequence>
        <xs:attribute name="author" use="optional"/>
        <xs:attribute name="datetime" use="optional"/>
        <xs:attribute name="version" fixed="2.0" use="required"/>
        <xs:anyAttribute namespace="##any" processContents="skip"/>
      </xs:complexType>
    </xs:element>

    <xs:element name="item">
      <xs:complexType mixed="true">
        <xs:attribute name="property" use="required"/>
        <xs:anyAttribute namespace="##any" processContents="skip"/>
      </xs:complexType>
    </xs:element>

</xs:schema>

Appendix H Size Restriction Module

The Size Restriction module provides a mechanism to annotate the XLIFF content with information on storage and general size restrictions.

H.1 Module Specification

H.1.1 Introduction

The restriction framework has support for two distinct types of restrictions; storage size restrictions and general size restriction. The reason for this is that it is often common to have separate restrictions between storage and display / physical representation of data. Since it would be impossible to define all restrictions here a concept of restriction profile is introduced. The profiles for storage size and general size are independent. The information related to restriction profiles are stored in the processing invariant part of the XLIFF file like the <xlf:file>, <xlf:group> and <xlf:unit> elements and contained within elements defined in this module. The information regarding the specific restrictions are stored on the processing invariant parts and on the inline elements as attributes or attributes referencing data in the elements defined in this module. To avoid issues with segmentation no information regarding size restrictions is present on <xlf:segment>, <xlf:source> and <xlf:target> elements. The module defines a namespace for all the elements and attributes it introduces, in the rest of the module specification elements and atributes are in this namespace unless stated otherwise. In other parts of the XLIFF specification the prefix "slr" is used to refer to this module's namespace. For clarity the prefix "xlf" will be used for XLIFF Core elements and attributes. Profile names use the same namespace-like naming convention as user defined values in the XLIFF Core specification. The names SHOULD be composed of two components separated by a colon. <authority>:<name>. The authority "xliff" is reserved for profiles defined by the OASIS XLIFF Technical Committee.

H.1.2 Module Namespace

The namespace for the Size and Length restriction module is: urn:oasis:names:tc:xliff:sizerestriction:2.0

H.1.3 Module Elements

The elements defined in the Size and Length restriction module are: <profiles>, <normalization> and <data>.

H.1.3.1 Tree Structure

Legend:

? = zero or one
* = zero, one or more
<profiles>
|
+---<normalization> ?
|
+---<any> *

  
H.1.3.2 profiles

This element selects the restriction profiles to use in the document. If no storage or general profile is specified the default values (empty) of those elements will disable restriction checking in the file.

Contains:

- Zero or one <normalization> element followed by
- elements from any namespace, OPTIONAL

Attributes:

- generalProfile, OPTIONAL
- storageProfile, OPTIONAL

Processing Requirements

  • Any overall configuration or settings related to the selected profile MUST be placed in child elements of this element.

  • Data not related to the configuration of the selected profiles MUST NOT be placed in this element.

H.1.3.3 normalization

This element is used to hold the attributes specifying the normalization form to apply to storage and size restrictions defined in the standard profiles.

Contains:

- empty element

Attributes:

- general, OPTIONAL
- storage, OPTIONAL

Processing Requirements

  • If this element is not present no normalization SHOULD be performed for the standard profiles.

  • Other profiles MAY use this element in its specified form but MUST NOT add new extensions to it.

H.1.3.4 data

This elements act as a container for data needed by the specified profile to check the part of the XLIFF document that is a sibling or descendant of a sibling of this element. It is not used by the default profiles.

Contains:

- elements from any namespace, OPTIONAL

Attributes:

- profile, REQUIRED
- attributes from any namespace, OPTIONAL

Processing Requirements

  • Third party profiles MUST place all data in this element instead of using other extension points if the data serves no other purpose in the processing of the document.

  • Data not used by the specified profile MUST NOT be placed in this element.

H.1.4 Module Attributes

The attributes defined in the Size and Length restriction module are: storageProfile, generalProfile, storage, general, profile, storageRestriction, sizeRestriction, equivStorage , sizeInfo and sizeInfoRef.

H.1.4.1 storageProfile

This attribute specifies, which profile to use while checking storage size restrictions. Empty string means that no restrictions are applied.

Value description: Name of restriction profile to use for storage size restrictions.

Default value: empty string

Used in:<profiles>.

H.1.4.2 generalProfile

This attribute specifies, which profile to use while checking the general size restrictions. Empty string means that no restrictions apply.

Value description: Name of restriction profile to use for general size restrictions.

Default value: empty string

Used in:<profiles>.

H.1.4.3 storage

This attribute specifies the normalization form to apply for storage size restrictions. Only the normalization forms C and D as specified by the Unicode Consortium are supported, see Unicode Standard Annex #15.

Value description: normalization to apply.

Table H.1. Values

ValueDescription
noneNo additional normalization SHOULD be done, content SHOULD be used as represented in the document. It is possible that other Agents have already done some type of normalization when Modifying content. This means that this setting could give different results depending on what Agents are used to preform a specific action on the XLIFF Document.
nfcNormalization Form C MUST be used
nfdNormalization Form D MUST be used

Default value: "none"

Used in: <normalization>.

H.1.4.4 general

This attribute specifies the normalization to apply for general size restrictions. Only the normalization forms C and D as specified by the Unicode Consortium are supported, see Unicode Standard Annex #15.

Value description: normalization to apply.

Table H.2. Values

ValueDescription
noneNo additional normalization SHOULD be done, content SHOULD be used as represented in the document. It is possible that other Agents have already done some type of normalization when Modifying content. This means that this setting could give different results depending on what Agents are used to preform a specific action on the XLIFF Document.
nfcNormalization Form C MUST be used
nfdNormalization Form D MUST be used

Default value: "none"

Used in:<normalization>.

H.1.4.5 profile

This attribute is used on the <data> element to indicate what profile the contents of that element apply to.

Value description: Name of a restriction profile

Default value: undefined

Used in:<data>.

H.1.4.6 storageRestriction

This attribute specifies the storage restriction to apply to the collection descendants of the element it is defined on.

Value description: Interpretation of the value is dependent on selected storageProfile. It MUST represent the restriction to apply to the indicated sub part of the document.

Default value: undefined

Used in: <file>, <group>, <unit>, <mrk>, <sm>, <pc> and <sc>.

H.1.4.7 sizeRestriction

This attribute specifies the size restriction to apply to the collection descendants of the element it is defined on.

Value description: Interpretation of the value is dependent on selected generalProfile. It MUST represent the restriction to apply to the indicated sub part of the document.

Default value: undefined

Used in: <file>, <group>, <unit>, <mrk>, <sm>, <pc> and <sc>.

H.1.4.8 equivStorage

This attribute provide a means to specify how much storaqge space an inline element will use in the native format. This size contribution is then added to the size contributed by the textual parts. This attribute is only allowed on the <ec> element if that element has the isolated attribute set to yes. Otherwise the attribute on the paired <sc> element also cover its partner <ec> element.

Value description: Interpretation of the value is dependent on selected storageProfile. It MUST represent the equivalent storage size represented by the inline element.

Default value: undefined

Used in: <pc>, <sc>, <ec>, <ph> and

H.1.4.9 sizeInfo

This attribute is used to associate profile specific information to inline elements so that size information can be decoupled from the native format or represented when the native data is not available in the XLIFF document. It can be used on both inline elements and structural elements to provide information on things like GUI dialog or control sizes, expected padding or margins to consider for size, what font is used for contained text and so on. This attribute is only allowed on the <ec> element if that elemnt has the isolated attribute set to yes. Otherwise the attribute on the paired <sc> element also cover its partner <ec> element.

Value description: Interpretation of the value is dependent on selected generalProfile. It MUST represent information related to how the element it is attached to contributes to the size of the text or entity in which it occurs or represents.

Default value: undefined

Used in: <file>, <group>, <unit>, <pc>, <sc>, <ec>, and <ph>.

Constraints

  • This attribute MUST NOT be specified if and only if sizeInfoRef is used. They MUST NOT be specified at the same time.

H.1.4.10 sizeInfoRef

This attribute is used to point to data that provide the same function as the sizeInfo attribute does, but with the data stored outside the inline content of the XLIFF segment. This attribute is only allowed on the <ec> element if that elemnt has the isolated attribute set to yes. Otherwise the attribute on the paired <sc> element also cover its partner <ec> element.

Value description: a reference to data that provide the same information that could be otherwise put in a sizeInfo attribute. The reference MUST point to an element in a <data> element that is a sibling to the element this attribute is attached to or a sibling to one of its ancestors.

Default value: undefined

Used in: <file>, <group>, <unit>, <pc>, <sc>, <ec>, and <ph>,

Constraints

  • This attribute MUST NOT be specified if and only if sizeInfo is used. They MUST NOT be specified at the same time.

H.1.5 Standard profiles

H.1.5.1 General restriction profile ”xliff:codepoints”

This profile implements a simple string length restriction based on the number of Unicode code points. It is OPTIONAL to specify if normalization is to be applied using the <normalization> element and the general attribute. This profile makes use of the following attributes from this module:

H.1.5.1.1 sizeRestriction

The value of this attribute holds the ”maximum” or ”minimum and maximum” size of the string. Either size MUST be an integer. The maximum size MAY also be ’*’ to denote that there is no maximum restriction. If only a maximum is specified it is implied that the minimum is 0 (empty string). The format of the value is the OPTIONAL minimum size and a coma followed by a maximum size (”[minsize,]maxsize”). The default value is ’*’ which evaluates to a string with unbounded size.

H.1.5.1.2 sizeInfo

The value of this attribute is an integer representing how many code points the element it is set on is considered to contribute to the total size. If empty, the default for all elements is 0.

H.1.5.2 Storage restriction profiles ”xliff:utf8”, ”xliff:utf16” and ”xliff:utf32”

These three profiles define the standard size restriction profiles for the common Unicode character encoding schemes. It is OPTIONAL to specify if normalization is to be applied using the <normalization>element and the storage. All sizes are represented in 8bit bytes. The size of text for these profiles is the size of the text converted to the selected encoding without any byte order marks attached. The encodings are specified by the Unicode Consortium in chapter 2.5 of the Unicode Standard [Unicode].

Table H.3. Profiles

NameDescription
xliff:utf8The number of 8bit bytes needed to represent the string encoded as UTF-8 as specified by the Unicode consortium.
xliff:utf16The number of 8bit bytes needed to represent the string encoded as UTF-16 as specified by the Unicode consortium.
xliff:utf32The number of 8bit bytes needed to represent the string encoded as UTF-32 as specified by the Unicode consortium.

These profiles make use of the following attributes from this module:

H.1.5.2.1 storageRestriction

The value of this attribute holds the ”maximum” or ”minimum and maximum” size of the string. Either size MUST be an integer. The maximum size MAY also be ’*’ to denote that there is no maximum restriction. If only a maximum is specified it is implied that the minimum is 0 (empty string). The format of the value is the OPTIONAL minimum size and a coma followed by a maximum size (”[minsize,]maxsize”). The default value is ’*’ which evaluates to a string with unbounded size.

H.1.5.2.2 equivStorage

The value of this attribute is an integer representing how many bytes the element it is set on is considered to contribute to the total size. If empty the default is 0. The <cp> is always converted to its representation in the profiles encoding and the size of that representation is used as the size contributed by the <cp>.

H.1.6 Third party profiles

The general structure of this module together with the extensibility mechanisms provided has been designed with the goal to cater for all practically thinkable size restriction schemes. For example, to represent two dimensional data, a profile can adopt a coordinate style for the values of the general restriction attributes. For instance {x,y} to represent width and height, or {{x1,y1},{x2,y2}} to represent a bounding box. It is also possible to embed information necessary to drive for instance a display simulator and attach that data to text in order to be able to perform device specific checking. Providing font information and checking glyph based general size are other feasible options.

H.1.7 Conformance

To claim conformance to the XLIFF size and length restriction module an Agent MUST meet the following criteria:

  • MUST be compliant with the schema of the XLIFF Core specification and its extensions provided in this module.

  • MUST follow all processing requirements set forth in this module specification regarding the general use of elements and attributes.

  • MUST support all standard profiles with normalization set to none.

  • SHOULD support all standard profiles with all modes of normalization.

  • MAY support additional third party profiles for storage or general restrictions.

  • MUST provide at least one of the following:

    • add size and length restriction information to an XLIFF Document

    • if it supports the profile(s) specified in the XLIFF Document it MUST provide a way to check if the size and length restrictions in the document are met according to the profile(s) requirements.

H.1.8 Example

A short example on how this modulecan be used is provided here with inline XML comments explaining the usage of the module features.

	<xliff version="2.0" srcLang="en-us" xmlns="urn:oasis:names:tc:xliff:document:2.0" xmlns:slr="urn:oasis:names:tc:xliff:sizerestriction:2.0">
    <file id="f1">
        <slr:profiles generalProfile="xliff:codepoints" storageProfile="xliff:utf8">
            <!-- Select standard UTF-8 storage encoding and standard codepoint size restriction both with NFC normalization-->
            <slr:normalization general="nfc" storage="nfc" />
        </slr:profiles>
        <!-- The group should not require more than 255 bytes of storage
             And have at most 90 codepoints. Note that the sum of the unit sizes are larger than this
             the total content of the group must still be at most 90 codepoints. -->
        <group id="g1" slr:storageRestriction="255" slr:sizeRestriction="90">
            <!-- This unit must not contain more than 60 code points -->
            <unit id="u1" slr:sizeRestriction="60">
                <segment>
                    <!-- The spanning <pc> element require 7 bytes of storage in the native format.
                       It's content must not have more than 25 codepoints -->
                <source>This is a small <pc equivStorage="7" slr:sizeRestriction="25">size restriction</pc> example.</source>
                </segment>
            </unit>
            <!-- This unit must not have more than 35 codepoints -->
            <unit id="u2" slr:sizeRestriction="35">
                <segment>
                    <source>With a group structure.</source>
                </segment>
            </unit>
        </group>
    </file>
</xliff>
	

H.1.9 XML Schema

The schema listed below for reading convenience is accessible at http://docs.oasis-open.org/xliff/xliff-core/v2.0/csprd02/schemas/modules/size_restriction.xsd.

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"
        xmlns:slr="urn:oasis:names:tc:xliff:sizerestriction:2.0"
        targetNamespace="urn:oasis:names:tc:xliff:sizerestriction:2.0">
        
    <xs:import namespace="http://www.w3.org/XML/1998/namespace"
            schemaLocation="http://www.w3.org/2001/xml.xsd"/>
        
    <!-- Attributes for size and length restriction used on core elements--> 
    
    <xs:attribute name="equiv-storage" type="xs:string"/>
    <xs:attribute name="size-info" type="xs:string"/>
    <xs:attribute name="size-info-ref" type="xs:NMTOKEN"/>
    <xs:attribute name="size-restriction" type="xs:string"/>
    <xs:attribute name="storage-restriction" type="xs:string"/>
    
    <!-- Elements for size and length restriction -->

    <xs:element name="profiles">
        <xs:complexType mixed="false">
            <xs:sequence>
                <xs:element minOccurs="0" maxOccurs="1" ref="slr:normalization" />
                <xs:any maxOccurs="unbounded" minOccurs="0" namespace="##other" processContents="skip"/>
            </xs:sequence>
            <xs:attribute name="generalProfile" use="optional"/>
            <xs:attribute name="storageProfile" use="optional"/>
        </xs:complexType>
    </xs:element>
    
    <xs:element name="normalization">
        <xs:complexType mixed="false">
            <xs:attribute name="general" use="optional"/>
	  <xs:attribute name="storage" use="optional"/>
        </xs:complexType>
    </xs:element>
    
    <xs:element name="data">
        <xs:complexType mixed="false">
            <xs:sequence>
                <xs:any maxOccurs="unbounded" minOccurs="0" namespace="##other" processContents="skip"/>
            </xs:sequence>
            <xs:attribute name="profile" use="required"/>
            <xs:anyAttribute namespace="##any" processContents="skip"/>
        </xs:complexType>
    </xs:element>

</xs:schema>

Appendix I Validation Module

This module defines a specific set of validation rules that can be applied to target text both globally and locally. Further constraints can be defined that allow rules to be applied to target text based on conditions in the source text or disabled to override a global scope.

I.1 Module Specification

I.1.1 Module Namespace

The namespace for the Validation Module is: urn:oasis:names:tc:xliff:validation:2.0

I.1.2 Module Elements

The elements defined in the Validation module are: <validation> and <rule>.

I.1.2.1 Tree Structure

Legend:

+ = one or more
<validation>
|
+---<rule> +

  
I.1.2.2 validation

Parent container for a list of rules and constraints to apply to the target text of the enclosing element.

Contains:

- One or more <rule> elements.

Attributes:

- attributes from any namespace, OPTIONAL

Processing Requirements

I.1.2.3 rule

A specific rule and constraint to apply to the target text of the enclosing element.

Contains:

- This element is always empty.

Attributes:

- isPresent, OPTIONAL
- occurs, OPTIONAL
- isNotPresent, OPTIONAL
- startsWith, OPTIONAL
- endsWith, OPTIONAL
- existsInSource, OPTIONAL
- caseSensitive, OPTIONAL
- normalization, OPTIONAL
- disabled, OPTIONAL
- attributes from any namespace, OPTIONAL

Constraints

Processing Requirements

  • Writers MAY create and add new <rule> elements, provided that the new rules do not contradict rules already present.

  • Modifiers MUST NOT change attributes defined in this module that are already present in any <rule> element.

  • Modifiers MUST NOT remove either <rule> elements or their attributes defined in this module.

I.1.3 Module Attributes

The attributes defined in the Validation module are: isPresent, occurs, isNotPresent, startsWith, endsWith, existsInSource, mustLoc, noLoc, caseSensitive, normalization, and disabled.

I.1.3.1 isPresent

This rule attribute specifies that a string MUST be present in the target text at least once.

For example, the following is valid:

<unit id="1">
  <segment id="1">
    <source>Choose an option in the online store.</source>
    <target>Escolha uma opção na loja online.</target>
  </segment>
  <validation>
    <rule isPresent="online" />
  </validation>
</unit>
  

Whereas the following is invalid:

<unit id="1">
  <segment id="1">
    <source>Choose an option in the online store.</source>
    <target>Escolha uma opção na online store.</target>
  </segment>
  <validation>
    <rule isPresent="loja" />
  </validation>
</unit>

Other rule attributes can be combined with <isPresent> to produce the following results:

isPresent=”loja” - loja is found in the target text at least once.
isPresent=”loja” occurs=”1” - loja is found in the target text exactly once.
isPresent=”loja” existsInSource=”yes” - loja is found in both source and target text the same number of times.
isPresent=”loja” existsInSource=”yes” occurs=”1” - loja is found in both source and target text and occurs in target text exactly once.

Value description: Text

Default value: none

Used in:<rule>

I.1.3.2 occurs

This rule attribute is used with the <isPresent> rule attribute to specify the exact number of times a string MUST be present in the target text. When this rule attribute is not used, then the string MUST be present in the target text at least once.

For example, the following is valid:

<unit id="1">
  <segment id="1">
    <source>Choose a store option in the online store.</source>
    <target>Escolha uma opção de loja na loja online.</target>
  </segment>
  <validation>
    <rule isPresent="loja" occurs="2" />
  </validation>
</unit>

Whereas the following is invalid:

<unit id="1">
  <segment id="1">
    <source>Choose a store option in the online store.</source>
    <target>Escolha uma opção de loja na online store.</target>
  </segment>
  <validation>
    <rule isPresent="loja" occurs="2" />
  </validation>
</unit>

Value description: A number of 1 or greater.

Default value: none

Used in:<rule>

I.1.3.3 isNotPresent

This rule attribute specifies that a string MUST NOT be present in the target text.

For example, the following is valid:

<unit id="1">
  <segment id="1">
    <source>Choose an option in the online store.</source>
    <target>Escolha uma opção na loja online.</target>
  </segment>
  <validation>
    <rule isNotPresent="store" />
  </validation>
</unit>

Whereas the following is invalid:

  <unit id="1">
  <segment id="1">
    <source>Choose an option in the online store.</source>
    <target>Escolha uma opção na online store.</target>
  </segment>
  <validation>
    <rule isNotPresent="store" />
  </validation>
</unit>

Value description: Text.

Default value: none

Used in:<rule>

I.1.3.4 startsWith

This rule attribute specifies that a string MUST start with a specific value.

For example, the following is valid:

<unit id="1">
  <segment id="1">
    <source>*Choose an option in the online store.</source>
    <target>*Escolha uma opção na loja online.</target>
  </segment>
  <validation>
    <rule startsWith="*" />
  </validation>
</unit>
  

Whereas the following is invalid:

<unit id="1">
  <segment id="1">
    <source>*Choose an option in the online store.</source>
    <target>Escolha uma opção na loja online.</target>
  </segment>
  <validation>
    <rule startsWith="*" />
  </validation>
</unit>
  

Value description: Text.

Default value: none

Used in: <rule>

I.1.3.5 endsWith

This rule attribute specifies that a string MUST end with a specific value.

For example, the following is valid:

<unit id="1">
  <segment id="1">
    <source>Choose an option in the online store:</source>
    <target>Escolha uma opção na loja online:</target>
  </segment>
  <validation>
    <rule endsWith=":" />
  </validation>
</unit>
  

Whereas the following is invalid:

<unit id="1">
  <segment id="1">
    <source>Choose an option in the online store:</source>
    <target>Escolha uma opção na online store.</target>
  </segment>
  <validation>
    <rule endsWith=":" />
  </validation>
</unit>
  

Value description: Text

Default value: none

Used in:<rule>

I.1.3.6 existsInSource

When this rule attribute is used with another rule attribute and is set to yes, it specifies that for the rule to succeed, the condition MUST be satisfied in both source and target text. This rule attribute is valid only when used with one of the following rule attributes: isPresent, startsWith, or endsWith.

When existsInSource is set to no, it will have no impact on execution of rules, except for overriding rules where existsInSource is set to yes on a higher level.

For example, the following are valid:

<unit id="1">
  <segment id="1">
    <source>Choose an option in the online store:</source>
    <target>Escolha uma opção na loja online:</target>
  </segment>
  <validation>
    <rule endsWith=":" existsInSource="yes" />
  </validation>
</unit>

<unit id="1">
  <segment id="1">
    <source>Choose an option in the online store.</source>
    <target>Escolha uma opção na loja online:</target>
  </segment>
  <validation>
    <rule endsWith=":" existsInSource="no" />
  </validation>
</unit>

Whereas the following is invalid:

<unit id="1">
  <segment id="1">
    <source>Choose an option in the online store.</source>
    <target>Escolha uma opção na loja online:</target>
  </segment>
  <validation>
    <rule endsWith=":" existsInSource="yes" />
  </validation>
</unit>
  

Value description: yes or no

Default value: no

Used in:<rule>

Constraints

I.1.3.7 mustLoc

Must localize, mustLoc - is a test for the presence of a string (substring) in the source text and a verification that it does not exist in the target text. Alternatively it can be used to verify presence of a prescribed replacement string in the target text.

Value description: Text.

Characters left parenthesis ( (U+0028), right parenthesis ) (U+0029), and quotation mark " (U+0022) MUST be escaped by enclosing within a pair of quotation marks, " (U+0022). The value MUST follow one of two patterns: either mustLoc="string" or mustLoc="(string)(string)", where the prescribed replacement string is enclosed within the second pair of parentheses.

Default value: none

Used in:<rule>

Processing Requirements

  • When mustLoc contains only one string from the source text, for example: mustLoc="hello world"; the target text MUST NOT contain that string.

  • When mustLoc contains a string from the source text and a replacement string for the target text, for example: mustLoc="(Hello world)(Hallo Welt)"; the target text MUST contain that replacement string.

I.1.3.8 noLoc

Not to localize, noLoc - is a test for the presence of a string (substring) in the source text and verification that it exists also in the target text.

Value description: Text

Default value: none

Used in:<rule>

Processing Requirements

  • The target text MUST contain the string specified by the value of noLoc.

I.1.3.9 caseSensitive

This rule attribute specifies whether the test defined within that rule is case sensitive or not.

Value description: yes if the test is case sensitive, no if the test is case insensitive.

Default value: yes.

Used in:<rule>

I.1.3.10 normalization

This rule attribute specifies the normalization type to apply when validating a rule. Only the normalization forms C and D as specified in [UAX #15].

Value description: The allowed values are are listed in the table below along with their corresponding types of normalization to be applied.

Table I.1. Values

ValueDescription
noneNo normalization SHOULD be done.
nfcNormalization Form C MUST be used.
nfdNormalization Form D MUST be used.

Default value: nfc

Used in:<rule>

I.1.3.11 disabled

This rule attribute determines whether a rule MUST or MUST NOT be applied within the scope of its enclosing element. For example, a rule defined at the <file> level can be disabled at the <unit> level.

This attribute is provided to allow for overriding execution of rules set at higher levels, see <validation>.

In the following example, the isNotPresent rule is applied in its entirety to the first unit, but not to the second.

<file>
 <validation>
    <rule isPresent="store" />
 </validation>
 <unit id="1">
   <segment id="1">
     <source>Choose an option in the online store:</source>
     <target>Escolha uma opção na loja online:</target>
   </segment>
 </unit>
 <unit id="2">
    <segment id="1">
      <source>Choose an option in the application store:</source>
      <target>Escolha uma opção na application store:</target>
    </segment>
    <validation>
      <rule isPresent="store" disabled="yes" />
    </validation>
  </unit>
<file>

Value description: yes or no

Default value: no

Used in:<rule>

I.1.4 Example:

<val:validation>
   <val:rule>
      <!-- text data -->
   </val:rule>
</val:validation>
      

I.1.5 XML Schema

The schema listed below for reading convenience is accessible at http://docs.oasis-open.org/xliff/xliff-core/v2.0/csprd02/schemas/modules/validation.xsd.

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"
    xmlns:xlf="urn:oasis:names:tc:xliff:document:2.0"
    xmlns:val="urn:oasis:names:tc:xliff:validation:2.0"
    targetNamespace="urn:oasis:names:tc:xliff:validation:2.0">
    <xs:import namespace="urn:oasis:names:tc:xliff:document:2.0"
    schemaLocation="../xliff_core_2.0.xsd"/>
    <xs:import namespace="http://www.w3.org/XML/1998/namespace"
        schemaLocation="http://www.w3.org/2001/xml.xsd"/>

    <xs:element name="validation">
      <xs:complexType>
        <xs:sequence>
          <xs:element minOccurs="1" maxOccurs="unbounded" ref="val:rule"/>
        </xs:sequence>
        <xs:anyAttribute namespace="##any" processContents="skip"/>
      </xs:complexType>
    </xs:element>

    <xs:element name="rule">
        <xs:complexType mixed="false">
        <xs:attribute name="isPresent" use="optional"/>
        <xs:attribute name="occurs" use="optional"/>
        <xs:attribute name="isNotPresent" use="optional"/>
        <xs:attribute name="startsWith" use="optional"/>
        <xs:attribute name="endsWith" use="optional"/>
        <xs:attribute name="existsInSource" use="optional"/>
        <xs:attribute name="caseSensitive" use="optional" type="xlf:yesNo" default="yes"/>
        <xs:attribute name="normalization" use="optional"/>
        <xs:attribute name="disabled" use="optional" type="xlf:yesNo" default="no"/>  
        <xs:anyAttribute namespace="##any" processContents="skip"/>
      </xs:complexType>
    </xs:element>

</xs:schema>

Appendix J Specification Change Tracking (Non-Normative)

J.1 Tracking of changes made in response to Public Reviews

This is to facilitate human tracking of changes in the specification made since the first Public Review publication on 16th April 2013.

J.1.1 Tracking of changes in response to the 1st Public Review

This section tracks major changes made to this specification compared to the Committee Specification Drat 01 / Public Review Draft 01 http://docs.oasis-open.org/xliff/xliff-core/v2.0/csprd01/xliff-core-v2.0-csprd01.html. The initial Public Review took place from 29th April 2013 until 29th May 2013.

  1. This change tracking appendix has been added.

  2. In response to comments 007 and 008, the skeleton attribute has been removed from the <file> element and the whole specification. Pointing to an external skeleton is now solely through the href attribute on the <skeleton> element.

  3. In response to comment 005, front matter language about not uppercasing normative keywords has been removed and keywords uppercased via html and fo xsl stylesheets.

  4. In response to comments 001 and 025, fs now requires to form valid HTML5 snippets that can be rendered by a browser. Example how to use images through fs has been added.

  5. In response to comments 033 and 061, val module syntax has been symplified, no special escaping mechanism is needed, also a flag to indicate case insensitivity has been added.

  6. In response to comments 027, and 028, res module is now allowed on both <file> and <unit> levels, it now also has an internal option analogical to <skeleton>.

  7. In response to comments 024, 036, and 050, gls module has been enhanced by adding of an id and by allowing for extensibility.

  8. In response to comments 018, 024, and 028, markers of the type term, can now point to gls entries.

  9. In response to comment 006, required order of core, module, and custom elments has been harmonized on all structural levels.

  10. In response to comment 038, modules, <notes>, and extesnions have been prohibited on <segment> and lower structural levels. This also caused some changes in modules previously allowed on these levels, notably fs and mtc. Markres now allow pointing to <match> elements and the resegmentation flag canResegment has been introduced on all structural levels. Detailed processing requirements for resegmentation have been added. Extensibility section had to be updated due to removing many extension points, the extensibility section now lists only core extension points and refers to modules for modules' extensibility.

  11. In response to comments 012 and 020, the attribute prefixes "trg" and "tgt" have been harmonized to "trg".

  12. In response to comment 014, mda module can be now used for roundtripping purposes, provide that it does not compete with core or other modules features.

  13. In response to comment 002, normative refernces to the Unicode Standard (latest), to the Unicode Bidirectional Algorithm (latest), to the W3C datetime NOTE, to HTML5, XML Schema Datatypes, and to the XML Receommendation have been explicitly added. Also conformance clauses in the Conformance section have been numbered.

  14. In response to comment 002, the specifcation now clearly indicates that backwards compatibility with XLIFF 1.2 is not required.

  15. In response to comments 013 and 015, the specifcation now defines the use of XML Processing Instructions in XLIFF.

  16. In response to comments 021 and 053, Processing Requirements of sub* attributes were unified, all now require update or deletion upon update of their master attribute.

  17. In response to comments 011 and 041, the attribute approved has been removed from the specification including all related Constraints and Processing Requirements.

  18. In response to comment 009, fully recursive inheritance on structural elements and markers has been introduced for the following attributes translate, canResegment, srcDir, and trgDir.

  19. In response to comment 039, normative language throughout the spec and the conformance section has been reworked with the use of process and agent defintions. Many Processing Requirements have been also reclassified as Constraints that in fact target documents rather than applications.

  20. In response to comment 010, the primary description of the segment element has been clarified and a reference to the Segmentation section has been added.

  21. In response to comment 030, the primary descriptions of the file and group elements have been clarified.

  22. Examples of core and module features have been added in reponse to comments 026, 033, 048, 051, and 058.

Appendix K Acknowledgements (Non-Normative)

The following individuals have participated in the creation of this specification and are gratefully acknowledged:

  • Amaya, Victor - Oracle

  • Chapman, Helena - IBM

  • Coady, Shirley - MultiCorpora R&D Inc.

  • Comerford, Tom - Individual

  • Estreen, Fredrik - Lionbridge

  • Filip, David - Localisation Research Centre

  • King, Ryan - Microsoft

  • Lieske, Christian - SAP AG

  • Loomis, Steven - IBM

  • Michael, Alan - Microsoft

  • Morado Vazquez, Lucia - Localisation Research Centre

  • O'Donnell, Kevin - Microsoft

  • Ow, Michael - IBM

  • Prause, Ingo - SDL

  • Raya, Rodolfo - Maxprograms

  • Ryoo, Jung Woo - Oracle

  • Savourel, Yves - ENLASO Corporation

  • Schnabel, Bryan - Individual

  • Schurig, Joachim - Lionbridge

  • Stahlschmidt, Uwe - Microsoft

  • Waldhör, Klemens - TAUS

  • Walters, David - IBM

  • Wasala, Asanka - Localisation Research Centre

xliff-core-v2.0-csprd02
Standards Track Work Product

Copyright © OASIS 2013. All rights reserved.
3 September 2013