diff --git a/xliff-22/docbook/dbgenent.mod b/xliff-22/docbook/dbgenent.mod index 2834574..fe981cb 100644 --- a/xliff-22/docbook/dbgenent.mod +++ b/xliff-22/docbook/dbgenent.mod @@ -52,7 +52,7 @@ - + diff --git a/xliff-22/xliff-core-v2.2wd.html b/xliff-22/xliff-core-v2.2wd.html index b6504c1..f385d0d 100644 --- a/xliff-22/xliff-core-v2.2wd.html +++ b/xliff-22/xliff-core-v2.2wd.html @@ -1,6 +1,6 @@ - XLIFF Core Version 2.2

XLIFF Core Version 2.2

Specification Draft

21 February 2024

Specification URIs
This version:
https://docs.oasis-open.org/xliff/xliff-core/v2.2/wd/xliff-core-v2.2-wd.html @@ -27,7 +27,7 @@ Normative for this Work Product that is provided in separate plain text files, in the event of a discrepancy between any such plain text file and display content in the Work Product's prose narrative document(s), the content in the separate plain text file prevails.

Citation format:

When referencing this specification the following citation format should be used:

[XLIFF-2.2]

XLIFF Version 2.2. Edited by Rodolfo M. Raya. - 21 February 2024. Specification Draft. https://docs.oasis-open.org/xliff/xliff-core/v2.2/wd/xliff-core-wd.html. Latest version: https://docs.oasis-open.org/xliff/xliff-core/v2.2/xliff-core.html.

Notices

Copyright © OASIS Open 2024. All Rights Reserved.

All capitalized terms in the following text have the meanings assigned to them in the + 28 February 2024. Specification Draft. https://docs.oasis-open.org/xliff/xliff-core/v2.2/wd/xliff-core-wd.html. Latest version: https://docs.oasis-open.org/xliff/xliff-core/v2.2/xliff-core.html.

Notices

Copyright © OASIS Open 2024. 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 @@ -1998,7 +1998,8 @@ 2nd, 2022.

  • Renamed Appendix B to "XLIFF Grammar Files (Normative)". Change approved on January 3rd, 2023.

  • Clarified values for version attribute. Change approved on January 17th, 2023.

  • Added new Plural, Gender, and Select Module.

  • Updated Appendix A - with the official MIME type listed in IANA Media Type Registry

    • In spite of the above mentioned changes, fixes, clarifications, and additions, the + with the official MIME type listed in IANA Media Type Registry

  • Allowed an optional <notes> element in <res:resourceItem>. Change approved during the meeting held on + February 20th, 2024.

    • In spite of the above mentioned changes, fixes, clarifications, and additions, the practical workings of the XLIFF Core hasn't been affected and none of the changes have affected the core namespace "urn:oasis:names:tc:xliff:document:2.0" or the XLIFF @@ -2007,4 +2008,4 @@ grammar and structure. All valid XLIFF 2.0 and 2.1 files are valid XLIFF 2.2 files. The changes introduced in version 2.2 are designed to preserve compatibility with versions 2.0 and 2.1.

    NVDL and Schematron files used in previous versions of XLIFF are available at https://github.com/oasis-tcs/xliff-xliff-22/tree/master/xliff-21.

    Appendix D Acknowledgements (Informative)

    The following individuals have participated in the creation of this specification and are - gratefully acknowledged:

    • Filip, David - Huawei Technologies Co., Ltd.

    • Morado Vázquez, Lucía - University of Geneva

    • Nita, Mihai - Google Inc.

    • Raya, Rodolfo M. - Individual

    • Schnabel, Bryan - Individual

    • Souto Pico, Manuel - cApStAn SA

    • Umaoka, Yoshito - IBM

    xliff-core-wd
    Standards Track Work Product
    Copyright © OASIS Open 2024. All rights reserved.    		21 February 2024
    \ No newline at end of file + gratefully acknowledged:

    xliff-core-wd
    Standards Track Work Product
    Copyright © OASIS Open 2024. All rights reserved.    		28 February 2024
    \ No newline at end of file diff --git a/xliff-22/xliff-core-v2.2wd.pdf b/xliff-22/xliff-core-v2.2wd.pdf index 558382c..0742b59 100644 Binary files a/xliff-22/xliff-core-v2.2wd.pdf and b/xliff-22/xliff-core-v2.2wd.pdf differ diff --git a/xliff-22/xliff-core-v2.2wd.xml b/xliff-22/xliff-core-v2.2wd.xml index 8d50111..53e7678 100644 --- a/xliff-22/xliff-core-v2.2wd.xml +++ b/xliff-22/xliff-core-v2.2wd.xml @@ -58,7 +58,7 @@ - 21 February 2024 + 28 February 2024 2024 @@ -181,7 +181,7 @@ XLIFF-2.2 XLIFF Version 2.2. Edited by Rodolfo M. Raya. - 21 February 2024. Specification Draft. https://docs.oasis-open.org/xliff/xliff-core/v2.2/wd/xliff-core-wd.html. Latest version: https://docs.oasis-open.org/xliff/xliff-core/v2.2/xliff-core.html. + 28 February 2024. Specification Draft. https://docs.oasis-open.org/xliff/xliff-core/v2.2/wd/xliff-core-wd.html. Latest version: https://docs.oasis-open.org/xliff/xliff-core/v2.2/xliff-core.html. @@ -6211,6 +6211,10 @@ Palouse horses<fn>A Palouse horse is the same as Updated Appendix A with the official MIME type listed in IANA Media Type Registry + + Allowed an optional <notes> element in <res:resourceItem>. Change approved during the meeting held on + February 20th, 2024. + In spite of the above mentioned changes, fixes, clarifications, and additions, the practical workings of the XLIFF Core hasn't been affected and none of diff --git a/xliff-22/xliff-extended-v2.2wd.html b/xliff-22/xliff-extended-v2.2wd.html index a10e6e2..771d9cc 100644 --- a/xliff-22/xliff-extended-v2.2wd.html +++ b/xliff-22/xliff-extended-v2.2wd.html @@ -1,6 +1,6 @@ - XLIFF Extended Version 2.2

    XLIFF Extended Version 2.2

    Specification Draft

    21 February 2024

    Specification URIs
    This version:
    https://docs.oasis-open.org/xliff/xliff-core/v2.2/wd/xliff-extended-v2.2-wd.html @@ -27,7 +27,7 @@ Normative for this Work Product that is provided in separate plain text files, in the event of a discrepancy between any such plain text file and display content in the Work Product's prose narrative document(s), the content in the separate plain text file prevails.

    Citation format:

    When referencing this specification the following citation format should be used:

    [XLIFF-2.2]

    XLIFF Version 2.2. Edited by Rodolfo M. Raya. - 21 February 2024. Specification Draft. https://docs.oasis-open.org/xliff/xliff-core/v2.2/wd/xliff-core-wd.html. Latest version: https://docs.oasis-open.org/xliff/xliff-core/v2.2/xliff-core.html.

    Notices

    Copyright © OASIS Open 2024. All Rights Reserved.

    All capitalized terms in the following text have the meanings assigned to them in the + 28 February 2024. Specification Draft. https://docs.oasis-open.org/xliff/xliff-core/v2.2/wd/xliff-core-wd.html. Latest version: https://docs.oasis-open.org/xliff/xliff-core/v2.2/xliff-core.html.

    Notices

    Copyright © OASIS Open 2024. 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 @@ -67,7 +67,7 @@ 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 https://www.oasis-open.org/policies-guidelines/trademark for above - guidance.

    Table of Contents

    1 Introduction
    1.1 Terminology
    1.1.1 Key words
    1.1.2 Definitions
    1.1.3 Key concepts
    1.2 Normative References
    1.3 Non-Normative References
    2 Conformance
    3 Fragment Identification
    3.1 Selectors for Core Elements
    3.2 Selectors for Modules and Extensions
    3.3 Relative References
    3.4 Examples
    4 The Core Specification
    4.1 General Processing Requirements
    4.2 Elements
    4.2.1 Tree Structure
    4.2.2 Structural Elements
    4.2.3 Inline Elements
    4.3 Attributes
    4.3.1 XLIFF Attributes
    4.3.2 XML namespace
    4.4 CDATA sections
    4.5 XML Comments
    4.6 XML Processing Instructions
    4.7 Inline Content
    4.7.1 Text
    4.7.2 Inline Codes
    4.7.3 Annotations
    4.7.4 Sub-Flows
    4.7.5 White Spaces
    4.7.6 Bidirectional Text
    4.7.7 Target Content Modification
    4.7.8 Content Comparison
    4.8 Segmentation
    4.8.1 Segments Representation
    4.8.2 Segments Order
    4.8.3 Segmentation Modification
    4.8.4 Best Practice for Mergers (Informative)
    4.9 Extension Mechanisms
    4.9.1 Extension Points
    4.9.2 Constraints
    4.9.3 Processing Requirements
    5 The Modules Specifications
    5.1 Translation Candidates Module
    5.1.1 Introduction
    5.1.2 Module Namespace and Validation Artifacts
    5.1.3 Module Fragment Identification Prefix
    5.1.4 XLIFF Core Reuse
    5.1.5 Translation Candidate Annotation
    5.1.6 Module Elements
    5.1.7 Module Attributes
    5.1.8 Example
    5.2 Glossary Module
    5.2.1 Introduction
    5.2.2 Module Namespace and Validation Artifacts
    5.2.3 Module Fragment Identification Prefix
    5.2.4 Module Elements
    5.2.5 Module Attributes
    5.2.6 Example
    5.3 Format Style Module
    5.3.1 Introduction
    5.3.2 Module Namespace and Validation Artifacts
    5.3.3 Module Fragment Identification Prefix
    5.3.4 Module Specification
    5.3.5 Module Attributes
    5.4 Metadata Module
    5.4.1 Introduction
    5.4.2 Module Namespace and Validation Artifacts
    5.4.3 Module Fragment Identification Prefix
    5.4.4 Module Elements
    5.4.5 Module Attributes
    5.5 Resource Data Module
    5.5.1 Introduction
    5.5.2 Module Namespace and Validation Artifacts
    5.5.3 Module Fragment Identification Prefix
    5.5.4 Module Elements
    5.5.5 Module Attributes
    5.5.6 Examples
    5.6 Size and Length Restriction Module
    5.6.1 Introduction
    5.6.2 Module Namespace and Validation Artifacts
    5.6.3 Module Fragment Identification Prefix
    5.6.4 Module Elements
    5.6.5 Module Attributes
    5.6.6 Standard profiles
    5.6.7 Third party profiles
    5.6.8 Conformance
    5.6.9 Example
    5.7 Validation Module
    5.7.1 Introduction
    5.7.2 Module Namespace and Validation Artifacts
    5.7.3 Module Fragment Identification Prefix
    5.7.4 Module Elements
    5.7.5 Module Attributes
    5.8 ITS Module
    5.8.1 Introduction
    5.8.2 Module Namespace and Validation Artifacts
    5.8.3 Module Fragment Identification Prefix
    5.8.4 Conformance to the ITS Module Specification
    5.8.5 ITS Tools Referencing
    5.8.6 ITS data categories defined in the ITS Module
    5.8.7 ITS data categories that have a partial overlap with XLIFF features
    5.8.8 ITS data categories available through XLIFF Core and other Modules
    5.8.9 ITS data categories not represented in XLIFF
    5.8.10 ITS Mapping Annotations
    5.8.11 Module Elements
    5.8.12 Module Attributes
    5.8.13 Example file
    5.9 Plural, Gender, and Select Module
    5.9.1 Introduction
    5.9.2 Module Namespace and Validation Artifacts
    5.9.3 Module Fragment Identification Prefix
    5.9.4 Module Elements
    5.9.5 Module Attributes
    5.9.6 Examples
    5.9.7 Recommended practices

    Appendixes

    A MIME Type for XLIFF Version 2.0 and Later Releases (Normative)
    B XLIFF Grammar Files (Normative) (Normative)
    B.1 XML Schemas Tree
    B.2 Support Schemas
    C Specification Change Tracking (Informative)
    D Acknowledgements (Informative)

    1 Introduction

    XLIFF is the XML Localization Interchange File Format designed by a + guidance.

    Table of Contents

    1 Introduction
    1.1 Terminology
    1.1.1 Key words
    1.1.2 Definitions
    1.1.3 Key concepts
    1.2 Normative References
    1.3 Non-Normative References
    2 Conformance
    3 Fragment Identification
    3.1 Selectors for Core Elements
    3.2 Selectors for Modules and Extensions
    3.3 Relative References
    3.4 Examples
    4 The Core Specification
    4.1 General Processing Requirements
    4.2 Elements
    4.2.1 Tree Structure
    4.2.2 Structural Elements
    4.2.3 Inline Elements
    4.3 Attributes
    4.3.1 XLIFF Attributes
    4.3.2 XML namespace
    4.4 CDATA sections
    4.5 XML Comments
    4.6 XML Processing Instructions
    4.7 Inline Content
    4.7.1 Text
    4.7.2 Inline Codes
    4.7.3 Annotations
    4.7.4 Sub-Flows
    4.7.5 White Spaces
    4.7.6 Bidirectional Text
    4.7.7 Target Content Modification
    4.7.8 Content Comparison
    4.8 Segmentation
    4.8.1 Segments Representation
    4.8.2 Segments Order
    4.8.3 Segmentation Modification
    4.8.4 Best Practice for Mergers (Informative)
    4.9 Extension Mechanisms
    4.9.1 Extension Points
    4.9.2 Constraints
    4.9.3 Processing Requirements
    5 The Modules Specifications
    5.1 Translation Candidates Module
    5.1.1 Introduction
    5.1.2 Module Namespace and Validation Artifacts
    5.1.3 Module Fragment Identification Prefix
    5.1.4 XLIFF Core Reuse
    5.1.5 Translation Candidate Annotation
    5.1.6 Module Elements
    5.1.7 Module Attributes
    5.1.8 Example
    5.2 Glossary Module
    5.2.1 Introduction
    5.2.2 Module Namespace and Validation Artifacts
    5.2.3 Module Fragment Identification Prefix
    5.2.4 Module Elements
    5.2.5 Module Attributes
    5.2.6 Example
    5.3 Format Style Module
    5.3.1 Introduction
    5.3.2 Module Namespace and Validation Artifacts
    5.3.3 Module Fragment Identification Prefix
    5.3.4 Module Specification
    5.3.5 Module Attributes
    5.4 Metadata Module
    5.4.1 Introduction
    5.4.2 Module Namespace and Validation Artifacts
    5.4.3 Module Fragment Identification Prefix
    5.4.4 Module Elements
    5.4.5 Module Attributes
    5.5 Resource Data Module
    5.5.1 Introduction
    5.5.2 Module Namespace and Validation Artifacts
    5.5.3 Module Fragment Identification Prefix
    5.5.4 Module Elements
    5.5.5 Module Attributes
    5.5.6 Examples
    5.6 Size and Length Restriction Module
    5.6.1 Introduction
    5.6.2 Module Namespace and Validation Artifacts
    5.6.3 Module Fragment Identification Prefix
    5.6.4 Module Elements
    5.6.5 Module Attributes
    5.6.6 Standard profiles
    5.6.7 Third party profiles
    5.6.8 Conformance
    5.6.9 Example
    5.7 Validation Module
    5.7.1 Introduction
    5.7.2 Module Namespace and Validation Artifacts
    5.7.3 Module Fragment Identification Prefix
    5.7.4 Module Elements
    5.7.5 Module Attributes
    5.8 ITS Module
    5.8.1 Introduction
    5.8.2 Module Namespace and Validation Artifacts
    5.8.3 Module Fragment Identification Prefix
    5.8.4 Conformance to the ITS Module Specification
    5.8.5 ITS Tools Referencing
    5.8.6 ITS data categories defined in the ITS Module
    5.8.7 ITS data categories that have a partial overlap with XLIFF features
    5.8.8 ITS data categories available through XLIFF Core and other Modules
    5.8.9 ITS data categories not represented in XLIFF
    5.8.10 ITS Mapping Annotations
    5.8.11 Module Elements
    5.8.12 Module Attributes
    5.8.13 Example file
    5.9 Plural, Gender, and Select Module
    5.9.1 Introduction
    5.9.2 Module Namespace and Validation Artifacts
    5.9.3 Module Fragment Identification Prefix
    5.9.4 Module Elements
    5.9.5 Module Attributes
    5.9.6 Examples
    5.9.7 Recommended practices

    Appendixes

    A MIME Type for XLIFF Version 2.0 and Later Releases (Normative)
    B XLIFF Grammar Files (Normative) (Normative)
    B.1 XML Schemas Tree
    B.2 Support Schemas
    C Specification Change Tracking (Informative)
    D Acknowledgements (Informative)

    1 Introduction

    XLIFF is the XML Localization Interchange File Format designed by a group of multilingual content publishers, software providers, localization service providers, localization tools providers, and researchers. It is intended to give any multilingual content owner a single interchange file format that can be understood by any localization provider, @@ -2355,6 +2355,10 @@ +---<resourceItemRef> * | +---<resourceItem> * + | + +---<notes> * + | | + | +===<note> ? | +---<source> ? | | @@ -2374,7 +2378,7 @@ MUST remove <resourceItemRef> when removing the referenced <resourceItem>.

    5.5.4.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 other namespaces, OPTIONAL

    Constraints

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

      Contains:

      At least one of the following

      - Zero or one <notes> element followed by
      - 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 other namespaces, OPTIONAL

      Constraints

    5.5.4.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 other namespaces, 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

    5.5.5 Module Attributes

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

    5.5.5.1 id

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

    Value description: NMTOKEN

    Default value: undefined

    Used in: <resourceItem> and <resourceItemRef>

    5.5.5.2 xml:lang

    Language - The xml:lang attribute specifies the language variant of the text of a given element. + MUST NOT be left blank.

    5.5.4.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 other namespaces, 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

    5.5.5 Module Attributes

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

    5.5.5.1 id

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

    Value description: NMTOKEN

    Default value: undefined

    Used in: <resourceItem> and <resourceItemRef>

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

    5.5.5.3 mimeType

    MIME type, mimeType - indicates the type of a resource object. This generally corresponds to @@ -2420,7 +2424,7 @@ 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]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].

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

    5.5.5.5 href

    Hypertext Reference, href - IRI referencing an external resource.

    Value description: IRI.

    Default value: undefined

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

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

    5.5.6 Examples

    In this example, the <resourceData> + 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.

    5.5.6 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> @@ -2480,6 +2484,9 @@ <file id="f3"> <res:resourceData> <res:resourceItem id="r1" mimeType="image/jpeg" context="yes"> + <notes> + <note>Registry configuration UI screen shot</note> + </notes> <res:source xml:lang="en-us" href="resources\en\registryconfig1.resources.jpg" /> <res:target xml:lang="lb-lu" @@ -2505,7 +2512,7 @@ </segment> </unit> </file> -

    5.6 Size and Length Restriction Module

    5.6.1 Introduction

    The Size and Length Restriction module provides a mechanism to annotate the XLIFF +

    5.6 Size and Length Restriction Module

    5.6.1 Introduction

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

    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 @@ -2525,9 +2532,9 @@ 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.

    5.6.2 Module Namespace and Validation Artifacts

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

    XML Schema for this module is available at https://docs.oasis-open.org/xliff/xliff-core/v2.2/wd/schemas/size_restriction.xsd.

    5.6.3 Module Fragment Identification Prefix

    The fragment identification prefix for the Size and Length restriction module is: - slr

    5.6.4 Module Elements

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

    5.6.4.1 Tree Structure

    Legend:

    ? = zero or one
    +            profiles defined by the OASIS XLIFF Technical Committee.

    5.6.2 Module Namespace and Validation Artifacts

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

    XML Schema for this module is available at https://docs.oasis-open.org/xliff/xliff-core/v2.2/wd/schemas/size_restriction.xsd.

    5.6.3 Module Fragment Identification Prefix

    The fragment identification prefix for the Size and Length restriction module is: + slr

    5.6.4 Module Elements

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

    5.6.4.1 Tree Structure

    Legend:

    ? = zero or one
     <profiles>
 |
 +---<normalization> ?
@@ -2537,15 +2544,15 @@
    5.6.4.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 other namespaces, 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.

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

    This element is always empty.

    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.

    5.6.4.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 other namespaces, OPTIONAL

    Attributes:

    - profile, REQUIRED
    - attributes from other namespaces, 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.

    5.6.5 Module Attributes

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

    5.6.5.1 storageProfile

    This attribute specifies, which profile to use while checking storage size restrictions. + storage and size restrictions defined in the standard profiles.

    Contains:

    This element is always empty.

    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.

    5.6.4.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 other namespaces, OPTIONAL

    Attributes:

    - profile, REQUIRED
    - attributes from other namespaces, 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.

    5.6.5 Module Attributes

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

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

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

    5.6.5.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 5. Values

    ValueDescription
    noneNo additional normalization SHOULD be done, content + 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 5. 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 perform 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>.

    5.6.5.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 6. Values

    ValueDescription
    noneNo additional normalization SHOULD be done, content + normalization forms C and D as specified by the Unicode Consortium are supported, see Unicode Standard Annex #15.

    Value description: Normalization to apply.

    Table 6. 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 @@ -2606,20 +2613,20 @@ <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.

    5.6.6 Standard profiles

    5.6.6.1 General restriction profile ”xliff:codepoints”

    This profile implements a simple string length restriction based on the number of + if and only if sizeInfo is used. They MUST NOT be specified at the same time.

    5.6.6 Standard profiles

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

    5.6.6.1.1 sizeRestriction

    The value of this attribute holds the ”maximum” or ”minimum and maximum” size + makes use of the following attributes from this module:

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

    5.6.6.1.2 sizeInfo

    The value of this attribute is an integer representing how many code points + a string with unbounded size.

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

    5.6.6.2 Storage restriction profiles ”xliff:utf8”, ”xliff:utf16” and + empty, the default for all elements is 0.

    5.6.6.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 @@ -2628,21 +2635,21 @@ 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 7. Profiles

    NameDescription
    xliff:utf8The number of 8bit bytes needed to represent the string encoded + [Unicode].

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

    5.6.6.2.1 storageRestriction

    The value of this attribute holds the ”maximum” or ”minimum and maximum” size + as UTF-32 as specified by the Unicode consortium.

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

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

    5.6.6.2.2 equivStorage

    The value of this attribute is an integer representing how many bytes the + a string with unbounded size.

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

    5.6.7 Third party profiles

    The general structure of this module together with the extensibility mechanisms + contributed by the <cp>.

    5.6.7 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 @@ -2650,7 +2657,7 @@ 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.

    5.6.8 Conformance

    To claim conformance to the XLIFF size and length restriction module an + general size are other feasible options.

    5.6.8 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 @@ -2663,7 +2670,7 @@ 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.

    5.6.9 Example

    A short example on how this module can be used is provided here with inline XML + according to the profile(s) requirements.

    5.6.9 Example

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

     <xliff version="2.2" srcLang="en-us"
     xmlns="urn:oasis:names:tc:xliff:document:2.2"
@@ -2701,11 +2708,11 @@
   </file>
 </xliff>

    -

    5.7 Validation Module

    5.7.1 Introduction

    This module defines a specific set of validation rules that can be applied to target text +

    5.7 Validation Module

    5.7.1 Introduction

    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.

    5.7.2 Module Namespace and Validation Artifacts

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

    XML Schema for this module is available at https://docs.oasis-open.org/xliff/xliff-core/v2.2/wd/schemas/validation.xsd.

    5.7.3 Module Fragment Identification Prefix

    The fragment identification prefix for the Validation module is: val

    5.7.4 Module Elements

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

    5.7.4.1 Tree Structure

    Legend:

    + = one or more
    +      scope.

    5.7.2 Module Namespace and Validation Artifacts

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

    XML Schema for this module is available at https://docs.oasis-open.org/xliff/xliff-core/v2.2/wd/schemas/validation.xsd.

    5.7.3 Module Fragment Identification Prefix

    The fragment identification prefix for the Validation module is: val

    5.7.4 Module Elements

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

    5.7.4.1 Tree Structure

    Legend:

    + = one or more
     <validation>
 |
 +---<rule> +
@@ -2729,7 +2736,7 @@
                 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.

    • 5.7.5 Module Attributes

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

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

    +                module.

    5.7.5 Module Attributes

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

    5.7.5.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">
   <val:validation>
     <val:rule isPresent="online" />
@@ -2881,7 +2888,7 @@
       is REQUIRED in the same <val:rule> element.
    5.7.5.7 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>

    5.7.5.8 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 listed in the table below - along with their corresponding types of normalization to be applied.

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

    5.7.5.9 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 + along with their corresponding types of normalization to be applied.

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

    5.7.5.9 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 <val:validation>.

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

    @@ -2905,7 +2912,7 @@
     </segment>
   </unit>
 </file>
-

    Value description: yes or no

    Default value: no

    Used in: <rule>

    5.8 ITS Module

    5.8.1 Introduction

    This module defines Inline Annotations (normative usage descriptions for attributes on inline +

    Value description: yes or no

    Default value: no

    Used in: <rule>

    5.8 ITS Module

    5.8.1 Introduction

    This module defines Inline Annotations (normative usage descriptions for attributes on inline annotation markers), attributes and elements that are needed to map [ITS] data categories using only XLIFF-defined elements and attributes. The module also defines an external rules file to be used by generic ITS processors working with XLIFF @@ -2947,9 +2954,9 @@ Documents can implement an additional capability in their ITS Processors to detect spans like this one <sm id="1"/>span of text<em startRef="1"/> without going into any more XLIFF specific features and becoming full fledged XLIFF - Agents.

    5.8.2 Module Namespace and Validation Artifacts

    The namespaces for the ITS module are: http://www.w3.org/2005/11/its and + Agents.

    5.8.2 Module Namespace and Validation Artifacts

    The namespaces for the ITS module are: http://www.w3.org/2005/11/its and urn:oasis:names:tc:xliff:itsm:2.1.

    XML Schemas for this module are available at https://docs.oasis-open.org/xliff/xliff-core/v2.2/wd/schemas/its.xsd and https://docs.oasis-open.org/xliff/xliff-core/v2.2/wd/schemas/itsm.xsd.

    [Note]Note

    Although setting and usage of prefixes for namespaces in XML is arbitrary, we are using - its: for the http://www.w3.org/2005/11/its namespace and itsm: for the urn:oasis:names:tc:xliff:itsm:2.1 namespace throughout this specification.

    5.8.3 Module Fragment Identification Prefix

    The fragment identification prefix for the ITS module is: its.

    [Note]Note

    Although this module has to use two different XML namespace prefixes it uses only one + its: for the http://www.w3.org/2005/11/its namespace and itsm: for the urn:oasis:names:tc:xliff:itsm:2.1 namespace throughout this specification.

    5.8.3 Module Fragment Identification Prefix

    The fragment identification prefix for the ITS module is: its.

    [Note]Note

    Although this module has to use two different XML namespace prefixes it uses only one fragment identification and authority prefix which is its.

    5.8.4 Conformance to the ITS Module Specification

    [Note]Note

    Some ITS data categories like Translate are supported natively by XLIFF. Other data categories are not supported by XLIFF because they are focusing on source content and not XLIFF content. The below conformance statement is only relevant for data categories for which the usage in XLIFF 2.1 @@ -3007,7 +3014,7 @@ the normative usage description of this attribute and the following sections for further details on structural and inline elements.

    5.8.6.1.1 Structural Elements

    If a structural element of the original document has a Allowed Characters annotation, it is recommended to represent that annotation using a <mrk> element that - encloses the whole content of the <source> element.

    Example 1. Extraction of Allowed Characters at structural levels

    Original: 

    +      encloses the whole content of the <source> element. 
    Example 1. Extraction of Allowed Characters at structural levels
    Original: 
     ...
 <p its-allowed-characters="[a-ZA-Z]">Text</p>
 ...
@@ -3045,7 +3052,7 @@
           XLIFF Documents.
    [Warning]Warning
    Please note that the Domain data category uses the itsm:domains attribute that belongs to the
         urn:oasis:names:tc:xliff:itsm:2.1 namespace (prefixed with itsm:)
       and not to the http://www.w3.org/2005/11/its (prefixed with its)
-      as most of the other attributes described in this module.
    5.8.6.2.1 Structural Elements
    Example 2. Extraction of Domain at structural levels
    Original:
    +      as most of the other attributes described in this module.
    5.8.6.2.1 Structural Elements

    Example 2. Extraction of Domain at structural levels

    Original:

     <!doctype html>
 <html lang="en">
   <head>
@@ -3076,7 +3083,7 @@
       usage description on inline markers.
    5.8.6.2.3 ITS Domain Annotation

    This is used to express inline the [ITS] Domain data category.

    Usage:

    • The id attribute is REQUIRED.

    • The itsm:domains attribute is REQUIRED.

    • The type attribute is OPTIONAL and set to - its:generic.

    • The translate attribute is OPTIONAL.

    Example 3. Extraction of Domain metadata on inline elements

    Original:

    +          its:generic.
  • The translate attribute is OPTIONAL.

    • Example 3. Extraction of Domain metadata on inline elements

    Original:

     <!doctype html>
 <html lang="en">
   <head>
@@ -3134,7 +3141,7 @@
     pair with the following attributes: its:localeFilterList and its:localeFilterType.
    See the ITS Locale Filter Annotation for
         the normative usage description of those attributes and the following sections for further
         details on structural and inline elements.
    5.8.6.3.1 Structural Elements
    When the target locale in XLIFF is undefined, the locale filter data  category
-        MAY be Extracted using the ITS Locale Filter Annotation.
    Example 4. Extraction of Locale Filter at structural levels
    Original: 
    +        MAY be Extracted using the ITS Locale Filter Annotation.
    Example 4. Extraction of Locale Filter at structural levels
    Original: 
     <p its-locale-filter-list='fr'>Text A</p>
 <p its-locale-filter-list='ja'>Text B</p>
  
    Extraction:
    @@ -3235,7 +3242,7 @@
           its:generic.
  • Exactly one of the following MUST be set:
    •               .
    • At least one of the following MUST be set:
  • The translate attribute is OPTIONAL.
  • The following attributes MUST NOT be set if and only if          is declared, otherwise all of the following
         are OPTIONAL:
    • [Warning]Warning
    Usage of the            attribute implies usage of Localization
         Quality Issue standoff elements. See <locQualityIssues> and <locQualityIssue> for related Constraints and Processing
-        Requirements.
    Example 5. Enriching XLIFF Documents with Localization Quality Issue Annotations
    Simple (i.e. without stand off):
    +        Requirements.

    Example 5. Enriching XLIFF Documents with Localization Quality Issue Annotations

    Simple (i.e. without stand off):

     <unit id="1">
   <segment>
     <source>This is the content</source>
@@ -3307,7 +3314,7 @@
         and/or rating profile information set at a group or file level. Also summary 0-100 ratings
         set at higher levels can be for instance overridden with voting set at unit or inline
         elements. Keep in mind that for a specific portion of text only one can exist a rating or a
-        vote result and these are to be accompanied with different threshhold attributes.

    Example 6. Enriching XLIFF Documents with Localization Quality Rating Annotations

    +        vote result and these are to be accompanied with different threshhold attributes.

    Example 6. Enriching XLIFF Documents with Localization Quality Rating Annotations

     <unit id="1">
   <segment>
     <source>Some text and a term</source>
@@ -3371,7 +3378,7 @@
       elements in source and target documents, therefore Provenance attributes listed in the above
         Processing Requirement are allowed on all structural levels.
    It is possible that Provenance metadata will be Extracted from
       source content but more likely Provenance metadata will be first introduced into the
-      translated content during the XLIFF based roundtrip.
    Example 7. Provenance metadata added by Modifiers or Enrichers on structural levels
    In this example a person of the name Honza Novák has been the translator of
+      translated content during the XLIFF based roundtrip.
    Example 7. Provenance metadata added by Modifiers or Enrichers on structural levels
    In this example a person of the name Honza Novák has been the translator of
         the whole unit content and Franta Kocourek the reviser of the whole
         translation.
     ...
@@ -3388,7 +3395,7 @@
 
    Preserving the Provenance metadata in the target content after
         Merging the Translations back to the original
       format can be useful, the metadata could be for instance used in a check in and publishing
-      process within a content management system.
    Example 8. Provenance metadata preserved by Mergers in the native format.
    In this example the translator and reviser Provenance metadata introduced during the
+      process within a content management system.
    Example 8. Provenance metadata preserved by Mergers in the native format.
    In this example the translator and reviser Provenance metadata introduced during the
         XLIFF roundtrip has been preserved after Merging of the
           Translations back to HTML.
     ...
@@ -3410,7 +3417,7 @@
          MUST be set:
    [Warning]Warning
    Usage of the        attribute implies usage of Provenance standoff elements.
       See <provenanceRecords>
       and <provenanceRecord>
-      for related Constraints and Processing Requirements.
    Example 9. Enriching XLIFF Documents with Provenance Annotations
    Inline only (i.e. without stand off):
    +      for related Constraints and Processing Requirements.
    Example 9. Enriching XLIFF Documents with Provenance Annotations
    Inline only (i.e. without stand off):
     ...
 <unit id='1'>
   <segment>
@@ -3483,7 +3490,7 @@
     details.
    Processing Requirements
    5.8.6.7.1 Structural Elements
    Text Analysis is not to be used at structural levels. If a structural element of the original document has [ITS]
       Text Analysis information associated, it MAY be Extracted
-      using the ITS Text Analysis Annotation.
    Example 10. Extraction of Text Analysis at structural levels
    Original:
    +      using the ITS Text Analysis Annotation.
    Example 10. Extraction of Text Analysis at structural levels
    Original:
     <p its-ta-class-ref="http://nerd.eurecom.fr/ontology#Place"
     its-ta-ident-ref="http://dbpedia.org/resource/Arizona">Arizona</p>
  
    Extraction:
    @@ -3509,7 +3516,7 @@
           taConfidence attribute.
  •  The its:annotatorsRef attribute is
           REQUIRED if and only if the its:taConfidence attribute is present
           and not in scope of another relevant its:annotatorsRef attribute, in all other cases it is
-          OPTIONAL. 
    • Example 11. Extraction of ITS Text Analytics metadata in scope of the ITS tools annotation
    Original:
    +          OPTIONAL. 
    Example 11. Extraction of ITS Text Analytics metadata in scope of the ITS tools annotation
    Original:
     <div its-annotators-ref="text-analysis|http://enrycher.ijs.si">
     ...
     <p><span its-ta-class-ref="http://nerd.eurecom.fr/ontology#Place"
@@ -3540,7 +3547,7 @@
       <note> and the <note> element. ITS attribute locNoteType
       is mapped onto the XLIFF Core attribute priority.
       The value alert is mapped onto priority 1. The value
-        description is mapped onto any of the integers 2-10.
    Example 12. Extraction of a Localization note at a structural level
    Original:
    +        description is mapped onto any of the integers 2-10.
    Example 12. Extraction of a Localization note at a structural level
    Original:
     <msgList xmlns:its= "http://www.w3.org/2005/11/its" xml:space= "preserve"
     its:version= "2.0">
   <data name= "LISTFILTERS_VARIANT" its:locNote= "Keep the leading space!"
@@ -3593,7 +3600,7 @@
       element has priority
       1 or does not have the priority attribute set explicitly, the ITS
         locNoteType is alert. Explicitly set values 2-10 map
-      onto the ITS locNoteType value description.
    Example 13. Extraction of an inline Localization Note 
    Original:
    +      onto the ITS locNoteType value description.
    Example 13. Extraction of an inline Localization Note 
    Original:
     <!DOCTYPE html>
 <html lang=en>
   <head>
@@ -3637,7 +3644,7 @@
         Core
       Annotations mechanism.
       Use <mrk> or an <sm/> / <em/> pair with
-        type="term". See Term Annotation.
    Example 14. Extraction of Terminology from structural elements
    Original:
    +        type="term". See Term Annotation.
    Example 14. Extraction of Terminology from structural elements
    Original:
     <p its-term='yes'>Term</p>
  
    Extraction:
     <unit id='1'>
@@ -3649,7 +3656,7 @@
         XLIFF Core
       Annotations mechanism.
       Use <mrk> or an <sm/> / <em/> pair with
-        type="term". See Term Annotation.
    Example 15. Extraction of inline Terminology using Annotation markers
    Original:
    +        type="term". See Term Annotation.
    Example 15. Extraction of inline Terminology using Annotation markers
    Original:
     <p>Text with a <span its-term='yes'>term</span>.</p>
  
    Extraction:
     <unit id='1'>
@@ -3675,7 +3682,7 @@
           defined termConfidence attribute.
  •  The its:annotatorsRef attribute is
           REQUIRED if and only if the its:termConfidence attribute is
           present and NOT in scope of another relevant its:annotatorsRef attribute, in
-          all other cases it is OPTIONAL. 
    • Example 16. Extraction of ITS Terminology with termConfidence 
    +          all other cases it is OPTIONAL. 
    Example 16. Extraction of ITS Terminology with termConfidence 
     <div its-annotators-ref="terminology|http://example.org/TermService">
   ...
   <p>Text with a <span its-term='yes'
@@ -3726,7 +3733,7 @@
         inline annotated using the same mechanism.
    [Warning]Warning
    Preserving source elements content that is in other than the main source language as original
         data stored outside of the translatable content at the unit level and referenced from
         placeholder codes is NOT advised, as important context would be very likely hidden from
-        translators, human or machine.
    Example 17. Core only extraction and roundtrip of a non localized hardware reference in other than
+        translators, human or machine.
    Example 17. Core only extraction and roundtrip of a non localized hardware reference in other than
         the main source language
    Original:
     <p> Use the <span class="HWbutton" xml:lang="DE-DE">Aus</span> button to
     completely switch off the machine. </p>
@@ -3748,7 +3755,7 @@
       Language Information data category,
       including full inline support that cannot be provided via the XLIFF
         Core due to normative Constraints. 
    Usage:
    • The id attribute is REQUIRED.
    • The itsm:lang attribute is REQUIRED.
    • The type attribute is OPTIONAL and set to
-          its:generic.
    • The translate attribute is OPTIONAL.
    Example 18. Extraction of Language Information
    Original:
    +          its:generic.
  • The translate attribute is OPTIONAL.
    • Example 18. Extraction of Language Information
    Original:
     <!doctype html>
 <html lang="en">
   <head>
@@ -3787,7 +3794,7 @@
       between the [ITS]
       MT Confidence and
         XLIFF-defined features. See the mtConfidence attribute for the mapping details, Advanced Constraints
-      and Processing Requirements.
    Example 19. MT Confidence as Translation Candidates metadata
    +      and Processing Requirements.
    Example 19. MT Confidence as Translation Candidates metadata
     <xliff version="2.2" xmlns="urn:oasis:names:tc:xliff:document:2.2"
     xmlns:mtc="urn:oasis:names:tc:xliff:matches:2.0"
     xmlns:its="http://www.w3.org/2005/11/its" its:version="2.2"
@@ -3834,7 +3841,7 @@
         MAY be represented upon Extraction using the
         MT Confidence Inline Annotation.  The whole
       unit source content MUST be enclosed within the annotation in such a case, possibly spanning multiple segments.
    5.8.7.4.3 Inline Elements
      
-    
    Example 20. Extraction of ITS MT Confidence Metadata from a Raw MTed source document
    Original:
    +    
    Example 20. Extraction of ITS MT Confidence Metadata from a Raw MTed source document
    Original:
     <p><span its:mtConfidence="0.8982"
     its:annotatorsRef="mt-confidence|MTServices-XYZ">Some Machine
         Translated text. </span></p>
@@ -3854,7 +3861,7 @@
           attribute its:mtConfidence
           MUST be set.
  • The translate attribute is OPTIONAL.
  •  The its:annotatorsRef attribute is
           REQUIRED if and only if the its:mtConfidence attribute is not in scope of
-          another relevant its:annotatorsRef attribute.
    • Example 21. Populating XLIFF Core targets with raw MT along with ITS MT
+          another relevant its:annotatorsRef attribute.
    Example 21. Populating XLIFF Core targets with raw MT along with ITS MT
         Confidence metadata
    Original:
     <p> Some human authored text for translation. </p>
  
    Extracted text Enriched with a Machine Translated candidate and
@@ -3904,7 +3911,7 @@
     modules:
    1. Translate and
    2. External Resource.
    3. Preserve Space
    5.8.8.1 Translate
    Indicates whether content is translatable or not. See [ITS]
     Translate for
     details.
    ITS data category Translate in source content influences how Extractors prepare source content for Translation via XLIFF Documents.
    5.8.8.1.1 Structural Elements
    
-      Use the translate attribute:
    Example 22. Extraction of Translate at structural levels
    Original:
    +      Use the translate attribute:
    Example 22. Extraction of Translate at structural levels
    Original:
     <p translate='yes'>Translatable text</p>
 <p translate='no'>Non-translatable text</p>
  
    Extraction:
    @@ -3924,7 +3931,7 @@
       non-translatable text as inline code data can hide important context information from
       translators, human or machine. The Extraction as code data is
       preferable if the non-translatable text has purely programmatic purpose and bears no
-      linguistic relationship to the surrounding translatable text.
    Example 23. Extraction of non-translatable inline text using Annotation markers
    Original:
    +      linguistic relationship to the surrounding translatable text.
    Example 23. Extraction of non-translatable inline text using Annotation markers
    Original:
     <p>The  <span translate="no">World Wide Web Consortium</span> makes the
     World Wide Web world wide.</p>
  
    Extraction:
    In this case the non-translatable span is a critical part of the content (a brand name)
@@ -3937,7 +3944,7 @@
         </source>
   </segment>
 </unit>
- 
    Example 24. Protection of non-translatable inline text using an inline code
    
+ 
    Example 24. Protection of non-translatable inline text using an inline code
    
         
     <p>You have <code translate='no'>%1</span> messages.</p>
  
    
@@ -3967,7 +3974,7 @@
       using the XLIFF Resource Data Module. The Extractor needs to determine
       the media type of the external resource, since this is not available via [ITS]
       External Resource
-      information.
    Example 25. Extraction of External Resource at structural levels
    Original:
    +      information.
    Example 25. Extraction of External Resource at structural levels
    Original:
     <its:rules version="2.0" xmlns:its="http://www.w3.org/2005/11/its"
     xmlns:html="http://www.w3.org/1999/xhtml">
   <its:externalResourceRefRule selector="//html:video/@src"
@@ -3987,7 +3994,7 @@
 </res:resourceData>
 ...
 
    5.8.8.2.2 Inline Elements
     External resources is Extracted using the XLIFF Resource Data
-      module. Use a <res:source> element as a child of a <res:resourceItem>element.
    Example 26. Extraction of External Resource at inline levels
    Original:
    +      module. Use a <res:source> element as a child of a <res:resourceItem>element.
    Example 26. Extraction of External Resource at inline levels
    Original:
     <!doctype html>
 <html lang="en">
   <head>
@@ -4026,7 +4033,7 @@
 
    5.8.8.3 Preserve Space
    Indicates how to handle whitespace in a given content portion. See
     [ITS] Preserve Space for details.
    5.8.8.3.1 Structural Elements
    
       Whitespace handling at the structural level is indicated with xml:space in XLIFF Core and extensions:
-      
    Example 27. Extraction of preserved whitespace at the structural level
    Original:
    +      
    Example 27. Extraction of preserved whitespace at the structural level
    Original:
     <listing xml:space='preserve'>Line 1 Line 2</listing>
  
    Extraction:
     <unit id='1' xml:space='preserve'>
@@ -4070,7 +4077,7 @@
     implementations, to understand how to extract source content. The data category is not
     represented directly in XLIFF Documents.
    The data category provides three values: yes, no and
       nested. See the ITS 2.0 specification for examples of how to use these values in general XML
-    vocabularies or in HTML. The below examples show how to deal with the values in XLIFF. 
    5.8.9.2.1 Elements Within Text Value Yes
    The element needs to be mapped to one of the XLIFF 2.1 inline elements: <pc>,
+    vocabularies or in HTML. The below examples show how to deal with the values in XLIFF. 
    5.8.9.2.1 Elements Within Text Value Yes
    The element needs to be mapped to one of the XLIFF 2.1 inline elements: <pc>,
       <sc>/<ec> or <ph>, while its content is extracted.
    Example for using pc - Original: 
     ...
 <p>This paragraph contains <span its-within-text="yes">a spanned part
@@ -4128,7 +4135,7 @@
   </segment>
 </unit>
 ...
-
    5.8.9.2.2 Elements Within Text Value Nested
    The sub-flow (i.e. element’s content) should be stored in a different unit
+
    5.8.9.2.2 Elements Within Text Value Nested
    The sub-flow (i.e. element’s content) should be stored in a different unit
       while the original element is replaced by a ph element and order of the flow
       defined by the subFlows attribute.
       
    Example - Original: 
    @@ -4158,7 +4165,7 @@
 </unit>
 ...
 
    All the sub-flows and the unit element which invokes them have to be in the
-      same file element. 
    5.8.9.2.3 Elements Within Text Value No
    In XLIFF 2.1 such element content should be stored in separate unit elements. 
    Example - Original: 
    +      same file element. 
    5.8.9.2.3 Elements Within Text Value No
    In XLIFF 2.1 such element content should be stored in separate unit elements. 
    Example - Original: 
     ...
 <ul>
   <li>First sentence</li>
@@ -4228,7 +4235,7 @@
       <provenanceRecord>, and
       <provenanceRecords>.
 
-    
    5.8.11.1 Tree Structure
    Legend:
    1 = one
    + = one or more
    ? = zero or one
    * = zero, one or more
    +    
    5.8.11.1 Tree Structure
    Legend:
    1 = one
    + = one or more
    ? = zero or one
    * = zero, one or more
     <locQualityIssues>
 |
 +---<locQualityIssue> +
@@ -4257,7 +4264,7 @@
         from the common parent element or one of the common parent's descendants as per Constraints
         for the provenanceRecordsRef
         attribute.
    Processing Requirements
    5.8.12 Module Attributes
    The ITS Module uses the following attributes from the
+          MAY delete that provenanceRecords element.
    5.8.12 Module Attributes
    The ITS Module uses the following attributes from the
         http://www.w3.org/2005/11/its namespace: allowedCharacters, annotatorsRef,         ,         ,         ,         ,         , locQualityIssuesRef,         ,         , locQualityRatingProfileRef,
         locQualityRatingScore, locQualityRatingScoreThreshold, locQualityRatingVote, locQualityRatingVoteThreshold, 
       mtConfidence, org, orgRef, person, personRef, provenanceRecordsRef, revOrg, revOrgRef, revPerson, revPersonRef, revTool, revToolRef, taClassRef, taConfidence, taIdent, taIdentRef, taSource, termConfidence,
@@ -4768,7 +4775,7 @@
         <file>
         <group>
         <unit>, <mrk>, <sm>,
-        <mtc:match>, <its:locQualityIssue>, <its:locQualityIssues>, <its:provenanceRecord>, and <its:provenanceRecords>.
    5.8.13 Example file
    Example 28. ITS Data Categories Example
    The following example file includes markup related to several ITS 2.0 data categories.
    <!-- xliff-its-example.xlf: Example file that shows several features of
+        <mtc:match>, <its:locQualityIssue>, <its:locQualityIssues>, <its:provenanceRecord>, and <its:provenanceRecords>.
    5.8.13 Example file
    Example 28. ITS Data Categories Example
    The following example file includes markup related to several ITS 2.0 data categories.
    <!-- xliff-its-example.xlf: Example file that shows several features of
 using ITS 2.0 as part of XLIFF 2.1
 Version: 0.2.1 
 Date: 04 April 2017 -->
@@ -4937,7 +4944,7 @@
     </unit>
   </file>
 </xliff>
-
    5.9 Plural, Gender, and Select Module
    5.9.1 Introduction
    This module provides an XLIFF capability to store information needed
+
    5.9 Plural, Gender, and Select Module
    5.9.1 Introduction
    This module provides an XLIFF capability to store information needed
     to represent and process messages with variants. This includes plural
     & gender variants, and a generic select.
    We have all seen messages like this: “You have 12
     day(s).”
    This was a common way to deal with plural in English, but didn’t
@@ -4981,9 +4988,9 @@
         her party”
  • “{host_name} invited {count} guests to
         his party”
  • “{host_name} invited {count} guests to
         their party”
    • This XLIFF extension is designed to represent such concepts, already
-    supported by several technologies.
    5.9.2 Module Namespace and Validation Artifacts
    The namespace for the Plural, Gender, and Select module is:
-    urn:oasis:names:tc:xliff:pgs:1.0.
    XML Schema for this module is available at https://docs.oasis-open.org/xliff/xliff-core/v2.2/wd/schemas/plural_gender_select.xsd.
    5.9.3 Module Fragment Identification Prefix
    The fragment identification prefix for the Plural, Gender, and
-    Select module is: pgs.
    5.9.4 Module Elements
    None.
    5.9.5 Module Attributes
    The attributes defined in the Plural, Gender, and Select module are:
+    supported by several technologies.
    5.9.2 Module Namespace and Validation Artifacts
    The namespace for the Plural, Gender, and Select module is:
+    urn:oasis:names:tc:xliff:pgs:1.0.
    XML Schema for this module is available at https://docs.oasis-open.org/xliff/xliff-core/v2.2/wd/schemas/plural_gender_select.xsd.
    5.9.3 Module Fragment Identification Prefix
    The fragment identification prefix for the Plural, Gender, and
+    Select module is: pgs.
    5.9.4 Module Elements
    None.
    5.9.5 Module Attributes
    The attributes defined in the Plural, Gender, and Select module are:
     switch, and case.
    5.9.5.1 switch
    Indicates the variable(s) used to select the message variant, and the
   kind of “selector” that will be used.
    Value description: Text.
    The text contains a space-separated list of items, each item
   containing a selector keyword, followed by colon (:), and followed by
@@ -5008,7 +5015,7 @@
         masculine, neuter, other, anything else (to handle
         languages with more
         than 3 grammatical genders)
  • select: the values can be anything, or the
-        other keyword
    • 5.9.6 Examples
    5.9.6.1 Plural
    ICU
+        other keyword
    5.9.6 Examples
    5.9.6.1 Plural
    ICU
       MessageFormat: 
    {file_count, plural,
        =0 {You deleted no file.}
        =1 {You deleted one file.}
@@ -5027,7 +5034,7 @@
       
    unit @switch(plural:file_count)
     segment "You deleted no files."                       @case(0)
     segment "You deleted one file."                       @case(1)
-    segment "You deleted <ph disp="file_count"/> files."  @case(other)
    5.9.6.2 Ordinal
    <unit id="tu1" pgs:switch="ordinal:place">
+    segment "You deleted <ph disp="file_count"/> files."  @case(other)
    5.9.6.2 Ordinal
    <unit id="tu1" pgs:switch="ordinal:place">
   <!-- For English ordinals "one" is NOT the same as "1" -->
   <segment id="seg1" pgs:case="one">
     <source>You won <ph id="1" disp="place"/>st place</source>
@@ -5046,7 +5053,7 @@
     segment "You won #st place"  @case(one)
     segment "You won #nd place"  @case(two)
     segment "You won #rd place"  @case(few)
-    segment "You won #th place"  @case(other)
    5.9.6.3 Gender
    <unit id="seg1" pgs:switch="gender:host_gender">
+    segment "You won #th place"  @case(other)
    5.9.6.3 Gender
    <unit id="seg1" pgs:switch="gender:host_gender">
   <segment id="seg1" pgs:case="feminine">
     <source>You are invited to her party</source>
   </segment>
@@ -5063,7 +5070,7 @@
     segment "You are invited to their party"  @case(other)
    Gender also allows for cases other than feminine /
       masculine / neuter / other in
       order to support languages with more
-      than 3 genders.
    5.9.6.4 Combinations
    <unit id="seg1" pgs:switch="gender:host_gender plural:guest_count">
+      than 3 genders.
    5.9.6.4 Combinations
    <unit id="seg1" pgs:switch="gender:host_gender plural:guest_count">
   <segment id="seg1" pgs:case="feminine 0">
     <source><ph id="1" disp="host_name"/> did not invite
         anyone to her party.</source>
@@ -5120,8 +5127,8 @@
        "$host_name invited one guest to their party."
   case [    other other]:
        "$host_name invited $guest_count guests to their party."
-}
    5.9.7 Recommended practices
    There are a few things that an implementer can do to help
-    applications that are not aware of this module.
    5.9.7.1 Generate “translator-friendly” identifiers
    This can be done by combining a “normal” message ID with
+}
    5.9.7 Recommended practices
    There are a few things that an implementer can do to help
+    applications that are not aware of this module.
    5.9.7.1 Generate “translator-friendly” identifiers
    This can be done by combining a “normal” message ID with
       information from the case.
    Using the short representation (and # for
       identifiers): 
    segment "$host_name invited @subFlow(tu2 tu3)
          to @subFlow(tu4 tu5 tu6) party." #msgid
@@ -5151,7 +5158,7 @@
     <target xml:lang="ro">Ați șters
         <ph id="1" disp="file_count"/> de fișiere.</target>
   </segment>
-</unit>
    5.9.7.2 Keep the same order of the selectors
    By keeping the generated text segments in the same order we can
+</unit>
    5.9.7.2 Keep the same order of the selectors
    By keeping the generated text segments in the same order we can
       improve Translation Memory leveraging that relies on context (the text
       before and after the current segment).
    Proposed order: 
    • Plural, ordinal 
      • exact selectors firsts, sorted by numerical value
                   (=0, =1, =2,
@@ -5162,7 +5169,7 @@
                   order: feminine, masculine,
                   neuter, other
    • Selection 
      • the selectors in alpha order
    Keeping a consistent order (the one suggested above or a different
       one) will improve the leveraging of Translation Memory tools that rely on context (what
-      is before and after the segment) to improve the result.
    5.9.7.3 Generate “translator-friendly” notes for plurals
    Native speakers intuitively know what the correct plural form
+      is before and after the segment) to improve the result.
    5.9.7.3 Generate “translator-friendly” notes for plurals
    Native speakers intuitively know what the correct plural form
       is.
    But will have a difficult time explaining what the rules are. And
       even fewer will be able to map those rules to the predefined plural
       keywords (zero, one, two,
@@ -5196,7 +5203,7 @@
       ICU library.
    A browser friendly table with all the supported rules for all
       languages, including examples, is available here.
    Warning: these examples are
       language dependent. This means one cannot just send a single XLIFF to be
-      translated into several languages (see next item).
    5.9.7.4 Generate separate localization packages for each language
    Depending on the degree of automation this might mean just a small
+      translated into several languages (see next item).
    5.9.7.4 Generate separate localization packages for each language
    Depending on the degree of automation this might mean just a small
       change in a configuration, or a lot of manual work.
    Some companies already use workflows doing this because they
       pre-populate the <target>, pre-leverage, include
       translation candidates or glossary info, partial Translation Memories, etc.
    Having such a workflow means that the tools can add the missing
@@ -5239,7 +5246,7 @@
     +---Plural, Gender, and Select Module
   
  
-
    B.2 Support Schemas
    Third party support schemas that are normatively referenced from this specification or
+
    B.2 Support Schemas
    Third party support schemas that are normatively referenced from this specification or
             from the machine readable artifacts that are a part of this multipart product are
             distributed along with the XLIFF-defined schemas in a subfolder named
             informativeCopiesOf3rdPartySchemas and further subdivided in folders
@@ -5264,7 +5271,8 @@
                     2nd, 2022.
  • Renamed Appendix B to "XLIFF Grammar Files (Normative)". Change approved on
                 January 3rd, 2023.
  • Clarified values for version attribute. Change approved on
                 January 17th, 2023.
  • Added new Plural, Gender, and Select                    Module. 
  • Updated Appendix A
-                with the official MIME type listed in IANA Media Type Registry 
    • In spite of the above mentioned changes, fixes, clarifications, and additions, the
+                with the official MIME type listed in IANA Media Type Registry 
  • Allowed an optional <notes> element in <res:resourceItem>. Change approved during the meeting held on
+            February 20th, 2024.
    • In spite of the above mentioned changes, fixes, clarifications, and additions, the
         practical workings of the XLIFF Core hasn't been affected and none of
         the changes have affected the core namespace
             "urn:oasis:names:tc:xliff:document:2.0" or the XLIFF
@@ -5273,4 +5281,4 @@
         grammar and structure. All valid XLIFF 2.0 and 2.1 files are valid XLIFF 2.2 files. The
         changes introduced in version 2.2 are designed to preserve compatibility with versions 2.0
         and 2.1.
    NVDL and Schematron files used in previous versions of XLIFF are available at https://github.com/oasis-tcs/xliff-xliff-22/tree/master/xliff-21.
    Appendix D Acknowledgements (Informative)
    The following individuals have participated in the creation of this specification and are
-        gratefully acknowledged:
    • Filip, David - Huawei Technologies Co., Ltd. 
    • Morado Vázquez, Lucía - University of Geneva 
    • Nita, Mihai - Google Inc.
    • Raya, Rodolfo M. - Individual 
    • Schnabel, Bryan - Individual 
    • Souto Pico, Manuel - cApStAn SA
    • Umaoka, Yoshito - IBM 
    xliff-core-wd
    Standards Track Work Product
    Copyright © OASIS Open 2024. All rights reserved.    		21 February 2024
    
\ No newline at end of file
+        gratefully acknowledged:
    • Filip, David - Huawei Technologies Co., Ltd. 
    • Morado Vázquez, Lucía - University of Geneva 
    • Nita, Mihai - Google Inc.
    • Raya, Rodolfo M. - Individual 
    • Schnabel, Bryan - Individual 
    • Souto Pico, Manuel - cApStAn SA
    • Umaoka, Yoshito - IBM 
    xliff-core-wd
    Standards Track Work Product
    Copyright © OASIS Open 2024. All rights reserved.    		28 February 2024
    
\ No newline at end of file
diff --git a/xliff-22/xliff-extended-v2.2wd.pdf b/xliff-22/xliff-extended-v2.2wd.pdf
index f6aeaf4..6d22cbf 100644
Binary files a/xliff-22/xliff-extended-v2.2wd.pdf and b/xliff-22/xliff-extended-v2.2wd.pdf differ
diff --git a/xliff-22/xliff-extended-v2.2wd.xml b/xliff-22/xliff-extended-v2.2wd.xml
index 3fbb8d2..1c09cea 100644
--- a/xliff-22/xliff-extended-v2.2wd.xml
+++ b/xliff-22/xliff-extended-v2.2wd.xml
@@ -59,7 +59,7 @@
     
 
 
-    21 February 2024
+    28 February 2024
 
     
       2024
@@ -179,7 +179,7 @@
       XLIFF-2.2
 
       XLIFF Version 2.2. Edited by Rodolfo M. Raya.
-        21 February 2024. Specification Draft. https://docs.oasis-open.org/xliff/xliff-core/v2.2/wd/xliff-core-wd.html. Latest version: https://docs.oasis-open.org/xliff/xliff-core/v2.2/xliff-core.html. 
+        28 February 2024. Specification Draft. https://docs.oasis-open.org/xliff/xliff-core/v2.2/wd/xliff-core-wd.html. Latest version: https://docs.oasis-open.org/xliff/xliff-core/v2.2/xliff-core.html. 
 
       
     
@@ -7584,6 +7584,10 @@ backslash (\).
 +---<resourceItemRef> *
 |
 +---<resourceItem> *
+  |
+  +---<notes> *
+  | |
+  | +===<note> ?
   |
   +---<source> ?
   | |
@@ -7652,9 +7656,10 @@ backslash (\).
     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
+      - Zero or one <notes> element followed by
+      - Zero or one <source> element followed by
+      - Zero or one <target> element followed by
+      - Zero, one or more <reference> elements
     
     Attributes:
     
@@ -8083,6 +8088,9 @@ backslash (\).
 <file id="f3">
   <res:resourceData>
     <res:resourceItem id="r1" mimeType="image/jpeg" context="yes">
+      <notes>
+        <note>Registry configuration UI screen shot</note>
+      </notes>
       <res:source xml:lang="en-us"
           href="resources\en\registryconfig1.resources.jpg" />
       <res:target xml:lang="lb-lu"
@@ -15211,6 +15219,10 @@ unit #g_msgid_plural_gender @switch(p
             Updated Appendix A
                 with the official MIME type listed in IANA Media Type Registry 
         
+        
+            Allowed an optional <notes> element in <res:resourceItem>. Change approved during the meeting held on
+            February 20th, 2024.
+    
     
     In spite of the above mentioned changes, fixes, clarifications, and additions, the
         practical workings of the XLIFF Core hasn't been affected and none of