Contents

  1. Approved Features for XLIFF 2.x or 3.0
  2. Features under consideration for XLIFF 2.x or 3.0 (not yet evaluated by TC)
    1. (S4) Permission Control and Validation
  3. Discarded Proposed Features for XLIFF 2.x or 3.0
  4. [XLIFF 2.1 Archive]
    1. [Approved Features for XLIFF 2.1]
    2. (B28) Bare-bones XLIFF Core with Extensions - DONE
  5. [XLIFF 2.0 Archive]
    1. [Approved Features for XLIFF 2.0]
    2. (B28) Bare-bones XLIFF Core with Extensions - DONE
    3. (Y29) Enhanced Commenting Support - DONE
    4. (Y30) Reference implementations or toolkit(s) similar to DITA - OUTSIDE OASIS
    5. (B31) Allow XML content in <internal-file> element - DONE
    6. (Y32) Segmentation - DONE
    7. Segmentation Method Roundtrip
    8. (J33) Glossaries - DONE
    9. (Y22) Translation Proposals DONE
    10. (B26) Add optional format attribute for quick at-a-glance review - DONE
    11. (D17) Criteria for Core vs. Module - DONE
    12. (B25) Preserve metadata without using extensibility - DONE
    13. (A9) Update Language Code Information - DONE
    14. (Y20) Element simpleNote - DONE
    15. (Y27) Grouping of Entries - DONE
    16. (F34) Bi-directional text support - DONE
    17. (Y8) Translation State - DONE
    18. (Y7) Improved Whitespace Handling - DONE
    19. (C3) Native support for ITS - DONE
    20. (D15) Mime-type for XLIFF [move forward when DC ready]
    21. (R43) Change track module - DONE [pending CRC32 discussion]
    22. (F35) Length and Size restrictions - DONE [pending normalization discussion]
    23. (R36) Resource Data Module - DONE
    24. (R41) Reference Language in matches module - DONE
    25. (R37) Validations Module - DONE [pending discussion on normalization default]
    26. [Features under consideration for XLIFF 2.0 (not yet evaluated by TC)]
    27. (S4) Permission Control and Validation
    28. (Y21) Term Proposals
    29. (Y23) QA Annotations
    30. (B34) Minimum set of container elements
    31. (R39) Optional Build Attribute for File
    32. (R40) Optional custom values for match type
    33. (R42) Optional name attribute on <notes> and <mds:metadata> module
    34. [Discarded Proposed Features for XLIFF 2.0]
    35. (S1) Change Tracking / Version Control
    36. (C14) Using XLIFF as a primary content authoring container
    37. (X0) Create RELAX NG version of XLIFF Schema
    38. (B12) Ability to store Multilingual Content
    39. (T2) Document-centric Localisation
    40. (T5) XLIFF as a Project Model
    41. (T10) Terminology Markup
    42. (A16) Multiple File elements
    43. (?13) Subsetting / restricting XSD
    44. (S6) Resource Inheritance
    45. (S24) Representation of plural entries
    46. (S4) Permission Control and Validation

To create a new Feature, please use the form below, and enter a wiki-name such as "NameOfMyFeature" that identifies this feature. You will also need to edit this page and include the feature under the relevant section

1. Approved Features for XLIFF 2.x or 3.0

2. Features under consideration for XLIFF 2.x or 3.0 (not yet evaluated by TC)

2.1. (S4) Permission Control and Validation

Owner: Shirley

Importance: Uncategorized

Category: Data Model, Extension

State: under-evaluation Core/Module: Not determined

Impact on Specification: Not determined

Impact on Schema: Not determined

Spec Updated: No. Schema Updated: No

It would be useful to have a language to be able to specify e.g. that in the 'review' process, a reviewer can only change the state attribute and add notes, and in the 'tm matching' process, a tool can only add <alt-trans> elements. After a process is completed, we could then automatically validate the XLIFF files that the constraints have been met according to the specification.

3. Discarded Proposed Features for XLIFF 2.x or 3.0


4. [XLIFF 2.1 Archive]

4.1. [Approved Features for XLIFF 2.1]

4.2. (B28) Bare-bones XLIFF Core with Extensions - DONE

Owner:

Importance: Must Have

Category: XML Schemas, Specification

State: Done Core/Module: core

David Spec sign-off: YES

Tom Schema sign-off: No

Spec Updated: Yes. Schema Updated: Yes

Create a bare-bones XLIFF core, then provide extension modules that support additional features.

5. [XLIFF 2.0 Archive]

5.1. [Approved Features for XLIFF 2.0]

5.2. (B28) Bare-bones XLIFF Core with Extensions - DONE

Owner:

Importance: Must Have

Category: XML Schemas, Specification

State: Done Core/Module: core

David Spec sign-off: YES

Tom Schema sign-off: No

Spec Updated: Yes. Schema Updated: Yes

Create a bare-bones XLIFF core, then provide extension modules that support additional features.

5.3. (Y29) Enhanced Commenting Support - DONE

Owner: Yves

Importance: Must Have

Category: Specification and Schema

  1. Allow a comment to be associated with specific content inside the source or target of a trans-unit.
  2. Allow a comment to be associated with content that spans across segments and trans-units.
  3. Allow extensible meta-data to be associated with a comment.

State: Done Core/Module: Not determined

David Spec sign-off: YES

Tom Schema sign-off: No

Spec Updated: Yes. Schema Updated: No

5.4. (Y30) Reference implementations or toolkit(s) similar to DITA - OUTSIDE OASIS

Owner: Yves

Importance: Must Have

Category: Applications

State: in-development Core/Module: N/A

Impact on Specification: N/A

Impact on Schema: N/A

Spec Updated: No. Schema Updated: No

5.4.1. Toolkit

The goal is to have a library that implements all features of XLIFF 2.0 as described by the specification and can used:

  • by other tools to read/write and manipulate XLIFF documents
  • by other implementations to compare and verify processing expectations

Something similar to the DITA toolkit http://www.ditaopentoolkit.org/

This is provided through the XLIFF Toolkit: http://code.google.com/p/okapi-xliff-toolkit/

5.4.2. Validation Tool

Validation is implemented by a different tool.

Status: Validation of existing XLIFF versions implemented. XLIFFChecker is an open source tool written in Java that supports validation of XLIFF 1.0, 1.1 and 1.2 (Strict and Transitional). Binaries are available for Windows, Linux and Mac.

5.5. (B31) Allow XML content in <internal-file> element - DONE

Owner: Bryan

Importance: Must Have

Category: Data Model, XML Schema

State: Done Core/Module: core

David Spec sign-off: YES

Tom Schema sign-off: No

Spec Updated: Yes. Schema Updated: Yes

5.6. (Y32) Segmentation - DONE

Owner: Yves, Helena

Importance: Uncategorized

Category: Data Model

State: Done Core/Module: core

David Spec sign-off: YES [TODO: PRs for how elements and attributes in segment, source, target should behave when re-segmenting.]

Tom Schema sign-off: No

Spec Updated: Yes. Schema Updated: Yes

Segmentation representation should be an integral part of XLIFF.

There should be a unique way to represent segmentation inside an XLIFF document, so tools can create, remove or manipulate segments as part of their features, and pass on those changes to the next tool in the process chain. The representation should include a way to represent un-segmented content. The access to segmented and un-segmented content should be similar so tools do not have to work using condition. One should be able to annotate and assign various processing information to each segment.

Moved 2.11. Split and merge segments (---> See Segmentation) here

Moved 2.18. Crossover aligned segments (---> See Segmentation) here

5.7. Segmentation Method Roundtrip

Owner: Steven L.

Importance: Uncategorized

Category: Data Model

Module to specify and keep track of segmentation method changes. Ability to track segmentation methods.

5.8. (J33) Glossaries - DONE

Owners: Joachim

Importance: Must Have

State: Done Core/Module: module

David Spec sign-off: YES

Tom Schema sign-off: No

Spec Updated: Yes. Schema Updated: Yes

Allow embedding simple glossaries in the XLIFF document.

A simple glossary entry would contain:

  • a term in the source language
  • an optional translation of the source term in the target language
  • an optional definition or comment

Either the optional translation or the definition/comment must be present for the glossary entry to be useful (source term alone would not be enough).

Glossary entries could be stored either at <unit> level or in the header of the file in an optional <glossary> element.

Feature approved as work item on January 3, 2012.

5.9. (Y22) Translation Proposals DONE

Owner: Yves

Importance: Uncategorized

Category: Data Model

State: Due: done Core/Module: module

David Spec sign-off: YES

Tom Schema sign-off: No

Spec Updated: YES Schema Updated: No

Yves: There is a proposal all where ok with here: https://lists.oasis-open.org/archives/xliff/201301/msg00023.html It just need to be put in the specification and schema.

Requirement: XLIFF should be able to store translation candidates for a given source entry.

The source text of a document can be pre-processed against various translation resource (TM, MT, etc.) to provide translation candidates. XLIFF should be able to store lists of possible translations along with information about the quality of the match, the quality of the translation, its provenance, etc.

XLIFF 1.2 used <alt-trans alttranstype='proposal'> to implement translation proposals.

5.10. (B26) Add optional format attribute for quick at-a-glance review - DONE

Owner: Bryan

Importance: Uncategorized

Category: Data Model | XML Schema

State: Done Core/Module: module

David Spec sign-off: NO [Bryan needs to restructure the module to reference subfs]

Tom Schema sign-off: No

Spec Updated: Yes. Schema Updated: No

Put an optional attribute on XLIFF elements that match a subset of HTML formatting elements (for example, HTML elements names like <script> would not be included). It would enable a quick "at-a-glance" HTML page to be created for review cycle. It would be important to specify that the attribute is not meant for round-tripping back into the original format. A second, optional attribute could be added for formatting style information. This attribute would be only available in cases where the first optional attribute is used.

It will be important that robust details are included in the specification. It is also recommended that a representation guide is published, that includes an example XSL stylesheet.

Example are listed in the details page

5.11. (D17) Criteria for Core vs. Module - DONE

Owner: David W., Christian, all

Importance: Must Have

Category: Specification and XML Schema

State: Done Core/Module: core

David Spec sign-off: N/A

Tom Schema sign-off: N/A

Spec Updated: N/A. Schema Updated: N/A

Initial definitions of core and module were proposed in http://lists.oasis-open.org/archives/xliff/201111/msg00081.html

The proposal was approved on December 6, 2011. Meeting minutes: http://lists.oasis-open.org/archives/xliff/201112/msg00012.html

5.12. (B25) Preserve metadata without using extensibility - DONE

Owner: Bryan and Rodolfo

Importance: Uncategorized

Category: Data Model | XML Schema | Spec

State: Done Core/Module: module

David Spec sign-off: YES

Tom Schema sign-off: No

Spec Updated: Yes. Schema Updated: Yes

http://lists.oasis-open.org/archives/xliff/201108/msg00040.html

In XLIFF 1.2 we sometimes need to use extensibility to preserve source metadata when converting an source files to XLIFF. For XLIFF 2.0, there is a need for preserving metadata; the solution should be generic and contemplate formats like HTML5, PO, or XML attributes in general - removing the need to extend.

5.13. (A9) Update Language Code Information - DONE

Owner: Helena Chapman, Steven Loomis

Importance: Should Have

Category: Other

State: Done Core/Module: ?

David Spec sign-off: YES

Tom Schema sign-off: No

Spec Updated: Yes. Schema Updated: No

The language code information that is in XLIFF 1.2 specification is obsolete. It says "A language code as decribed in the [RFC 4646], the successor to [RFC 3066]". The latest RFC is 5446. So, the text should be "A language code as decribed in the [RFC 5646], the successor to [RFC 4646]" “A language code as described in IETF BCP 47” (change made by Arle). There is more information in the W3C webpage http://www.w3.org/International/articles/language-tags/ This information is present in the following attributes' description:

  • source-language
  • target-language
  • xml:lang

It is also present in the normative references section (page 71).

5.14. (Y20) Element simpleNote - DONE

Owner: Yves

Importance: Uncategorized

Category: XML Schema

State: Done Core/Module: core

David Spec sign-off: YES

Tom Schema sign-off: No

Spec Updated: Yes. Schema Updated: No

5.15. (Y27) Grouping of Entries - DONE

Owner: Yves

Importance: Should Have | Must Have | Nice to Have | Uncategorized

Category: Data Model

State: Done Core/Module: core

David Spec sign-off: YES

Tom Schema sign-off: No

Spec Updated: Yes. Schema Updated: Yes

Data extracted into an XLIFF document are often from formats with some sort of structure: for example document with sections and tables, resource files with dialog boxes, menus, etc.

It is important to provide in XLIFF a way to map such structures in a common way, so tools can provide more efficient support for structure-related features, for example verifying shortcut keys in a menu.

5.16. (F34) Bi-directional text support - DONE

Owner: Fredrik

Importance: Should Have

Category: Data Model, XML Schema

State: done Core/Module: Core

Impact on Specification: Not fully determined, require inheritance of attribute values.

David Spec sign-off: YES

Tom Schema sign-off: No

Spec Updated: Yes. Schema Updated: Yes

In order to support display and editing of bi-directional text in a portable way the XLIFF format must provide a way to encode directionality in a standard way separated from the (possibly) native format.

5.17. (Y8) Translation State - DONE

Owner: Yves

Importance: Uncategorized

Category: Data Model and Processing Expectations

State: Done Core/Module: core

David Spec sign-off: YES

Tom Schema sign-off: No

Spec Updated: Yes. Schema Updated: Yes

As an exchange format XLIFF must provide a clear and consistent way to indicate the state of the translation of each entries. there are a number of inconsistencies in the current 1.2 that cause different tools to use different attributes and values for indicating the same things.

5.18. (Y7) Improved Whitespace Handling - DONE

Owner: Yves

Importance: Uncategorized

Category: Data Model, XML Schema

State: Done Core/Module: ?

David Spec sign-off: YES

Tom Schema sign-off: No

Spec Updated: Yes. Schema Updated: Yes

XLIFF 1.2 have some support for handling various types of whitespace in XML through the xml:space attribute, although this support is broken at times, as described in the following email. For XLIFF 2.0 we should implement support for improved whitespace handling.

5.19. (C3) Native support for ITS - DONE

Owner: Yves, DavidF

Importance: Should Have

Category: Data Model, Representation Guides, Profiles

State: Due 19 March 2013 Core/Module: module

David Spec sign-off: YES

Tom Schema sign-off: No

Spec Updated: No. Schema Updated: No

The W3C International Tag Set (ITS) standard defines i18n properties for XML based files. Could we use this to better handle XML files within XLIFF?

5.20. (D15) Mime-type for XLIFF [move forward when DC ready]

Owner: DavidF

Importance: Uncategorized

Category: Other

State: Due 15th August 2013 Core/Module: external

David Spec sign-off: N/A

Tom Schema sign-off: N/A

Spec Updated: N/A. Schema Updated: N/A

Mime-type for XLIFF (http://lists.oasis-open.org/archives/xliff/200802/msg00011.html)

5.21. (R43) Change track module - DONE [pending CRC32 discussion]

Owner: Ryan and Shirley

Importance: Uncategorized

Category: Data Model | XML Schema

State: Due 10March2013 Core/Module: module

David Spec sign-off: YES [but pending CRC32 discussion]

Tom Schema sign-off: No

Spec Updated: No. Schema Updated: No

Add optional change tracking attributes to <segment>. Note: combined with (S1)

5.22. (F35) Length and Size restrictions - DONE [pending normalization discussion]

Owner: Fredrik

Importance: Should Have

Category: Data Model, XML Schema

State: Done Core/Module: module

Impact on Specification: None to Core, works with normal Core Processing Requirements. Module specification need to be added.

Impact on Schema: Additional elements and attributes defined in module. Need to add module elements and attributes to core schema at some points.

David Spec sign-off: YES [but pending normalization discussion]

Tom Schema sign-off: No

Spec Updated: Yes. Schema Updated: Yes

In XLIFF 1.2 there is provision to specify restrictions on size, both physical and logical. The XLIFF 2.0 specification should include support for this feature.

5.23. (R36) Resource Data Module - DONE

Owner: Ryan King

Importance: Uncategorized

Category: Data Model | XML Schema

State: Due 28February2013 Core/Module: module

David Spec sign-off: YES [need to change cannot to MUST NOT in PRs]

Tom Schema sign-off: No

Spec Updated: No. Schema Updated: No

Add a module for processing binary data in XLIFF. We think that the 2.0 implementation could be essentially the same as 1.2 with just the elements and attributes used *for now* so the we essentially get it on the 2.0 radar.

5.24. (R41) Reference Language in matches module - DONE

Owner: Ryan King

Importance: Uncategorized

Category: Data Model | XML Schema

State: Due 10March2013 Core/Module: module

David Spec sign-off: YES

Tom Schema sign-off: No

Spec Updated: No. Schema Updated: No

Add an optional Reference Language to the matches module. This is a crucial feature for Microsoft and other large companies that localize minority languages.

5.25. (R37) Validations Module - DONE [pending discussion on normalization default]

Owner: Ryan King

Importance: Uncategorized

Category: Data Model | XML Schema

State: Due 10March2013 Core/Module: module

David Spec sign-off: YES [pending discussion on normalization default]

Tom Schema sign-off: No

Spec Updated: No. Schema Updated: No

The target text of a document can be verified against various validation rules. The Validations Module should be able to store a list of pre-defined validation rules, along with a description about how to process the target text using those rules, to perform specific verifications.

5.26. [Features under consideration for XLIFF 2.0 (not yet evaluated by TC)]

5.27. (S4) Permission Control and Validation

Owner: Shirley

Importance: Uncategorized

Category: Data Model, Extension

State: under-evaluation Core/Module: Not determined

Impact on Specification: Not determined

Impact on Schema: Not determined

Spec Updated: No. Schema Updated: No

It would be useful to have a language to be able to specify e.g. that in the 'review' process, a reviewer can only change the state attribute and add notes, and in the 'tm matching' process, a tool can only add <alt-trans> elements. After a process is completed, we could then automatically validate the XLIFF files that the constraints have been met according to the specification.

5.28. (Y21) Term Proposals

Owner: Yves

Importance: Uncategorized

Category: Data Model

State: under-evaluation Core/Module: Module

Impact on Specification: Not determined

Impact on Schema: Not determined

Spec Updated: No. Schema Updated: No

Requirement: XLIFF should be able to store term candidates for a given source entry.

The source text of a document can be pre-processed against a term base to find source term with an existing translation. XLIFF should be able to store lists of terms found in the source along with their translation and any relevant information.

5.29. (Y23) QA Annotations

Owner: Yves

Importance: Uncategorized

Category: Data Model

State: under-evaluation Core/Module: undecided

Impact on Specification: Not determined

Impact on Schema: Not determined

Spec Updated: No. Schema Updated: No

Requirement: XLIFF should be able to exchange a common set of information about quality assurance issues.

Quality assurance tools can process XLIFF document in a process separate from the translation or edit process. In fact some tools are dedicated to perform QA and have no facility to edit the content. It is important for XLIFF to have a mechanism that allows such tools to annotate the content of the XLIFF document in a common way, so different tools can work seamlessly.

5.30. (B34) Minimum set of container elements

Owner: Bryan

Importance: Uncategorized

Category: Data Model | XML Schema

State: in-development Core/Module: Not determined

Impact on Specification: Not determined

Impact on Schema: Not determined

Spec Updated: No. Schema Updated: No

There is a minimum set of container elements (heierachy) that we should preserve as framework for XLIFF 2.0. I think that set is: xliff, file, header, skl, internal-file, external-file, body, group, and unit.

(legend: 1 = one
  + = one or more
  ? = zero or one
  * = zero, one or more)


 <xliff>1
 | 
 | 
 +--- <file>+
      |
      +--- <header>?
      |    |
      |    +--- <internal-skl>?|<external-skl>?
      | 
      |
      +--- <body>1
           |
           +--- <group>*|<unit>*

5.31. (R39) Optional Build Attribute for File

Owner: Ryan King

Importance: Uncategorized

Category: XML Schema

Add an optional build attribute to 2.0 <file> element in core.

5.32. (R40) Optional custom values for match type

Owner: Ryan King

Importance: Uncategorized

Category: Data Model | XML Schema

Be able to specify optional custom values for match type attribute in the <mtc:matches> module.

5.33. (R42) Optional name attribute on <notes> and <mds:metadata> module

Owner: Ryan King

Importance: Uncategorized

Category: Data Model | XML Schema

Add an optional name attribute on <notes> in core and <mds:metadata> module.

5.34. [Discarded Proposed Features for XLIFF 2.0]

5.35. (S1) Change Tracking / Version Control

Owner: Shirley - Rodolfo

Importance: Should Have

Category: Data Model, Extension

State: under-evaluation Core/Module: Not determined

Impact on Specification: Not determined

Impact on Schema: Not determined

Spec Updated: No. Schema Updated: No

XLIFF 1.2 has preliminary support for change tracking through the <phase> element and phase-name attribute. However, it doesn't support all features, e.g. what if I want to know in which process the merged-trans attribute was set for a <group>?

* Version control Metadata - need to track revision information

5.36. (C14) Using XLIFF as a primary content authoring container

Owner: Christian

Importance: Uncategorized

Category: Data Model

State: under-evaluation Core/Module: Not determined

Impact on Specification: Not determined

Impact on Schema: Not determined

Spec Updated: No. Schema Updated: No

Author stores contend directly to XLIFF instead of another proprietary format

5.37. (X0) Create RELAX NG version of XLIFF Schema

Owner: TBD

Importance: Uncategorized

Category: XML Schema

Create RELAX NG version of XLIFF Schema

5.38. (B12) Ability to store Multilingual Content

Owner: Bryan

Importance: Uncategorized

Category: Data Model

State: in-design. Core/Module: Not determined

Impact on Specification: Not determined

Impact on Schema: Not determined

Spec Updated: No. Schema Updated: No

Use the file element and have the same id and source for corresponding trans units.

5.39. (T2) Document-centric Localisation

Owner: TBD

Importance: Uncategorized

Category: Data Model, XML Schema

State: under-evaluation Core/Module: Not determined

Impact on Specification: Not determined

Impact on Schema: Not determined

Spec Updated: No. Schema Updated: No

XLIFF 1.2 is in many ways a resource-centric approach to translation, and doesn't take into account some of the needs in document-centric translation, such as e.g. reordering of paragraphs, 1-n, n-1 and n-n translations. Is there a need or a case for developing a document-centric and a resource-centric extension, with a common core schema?

5.40. (T5) XLIFF as a Project Model

Owner: TBD

Importance: Should Have

Category: Data Model

State: under-evaluation Core/Module: Not determined

Impact on Specification: Not determined

Impact on Schema: Not determined

Spec Updated: No. Schema Updated: No

XLIFF 1.2 uses a File/Resource as the model. We wish in XLIFF 2.0 to implement a richer project container

5.41. (T10) Terminology Markup

Owner: TBD

Importance: Uncategorized

Category: Data Model | XML Schema | Other | ...

State: under-evaluation Core/Module: Not determined

Impact on Specification: Not determined

Impact on Schema: Not determined

Spec Updated: No. Schema Updated: No

5.42. (A16) Multiple File elements

Owner: Asgeir, Bryan

Importance: Uncategorized

Category: XML Schema

State: under-evaluation Core/Module: Not determined

Impact on Specification: Not determined

Impact on Schema: Not determined

Spec Updated: No. Schema Updated: No

Proposed by Asgeir here http://lists.oasis-open.org/archives/xliff/201006/msg00012.html

5.43. (?13) Subsetting / restricting XSD

Owner:

Importance: Uncategorized

Category: XML Schema

State: under-evaluation Core/Module: Not determined

Impact on Specification: Not determined

Impact on Schema: Not determined

Spec Updated: No. Schema Updated: No

Subsetting / restricting XSD for XLIFF 2.0

5.44. (S6) Resource Inheritance

Owner: Helena Chapman, Steven R. Loomis

Importance: Uncategorized

Category: Data Model, XML Schema

State: under-evaluation Core/Module: Not determined

Impact on Specification: Not determined

Impact on Schema: Not determined

Spec Updated: No. Schema Updated: No

For some l10n libraries, it is common to support language inheritance, in that if a resource is not specified in the specific locale (e.g. en-AU), then look at the more generic locale (e.g. en). Handling localisation of these resources in XLIFF is quite ad-hoc with XLIFF 1.x. I.e. there is no 'right' way for an editor to specify 'use the more generic locale for this resource'.

5.45. (S24) Representation of plural entries

Owner: Helena Chapman, Steven R. Loomis

Importance: Uncategorized

Category: Data Model

State: under-evaluation Core/Module: undecided

Impact on Specification: Not determined

Impact on Schema: Not determined

Spec Updated: No. Schema Updated: No

several message format have support for plural entries: a message with several strings corresponding to the different plural for the given text. For example PO and TS format have such features. It would be useful to make sure XLIFF 2.0 has a way to handle those constructs.

5.46. (S4) Permission Control and Validation

Owner: Shirley

Importance: Uncategorized

Category: Data Model, Extension

State: under-evaluation Core/Module: Not determined

Impact on Specification: Not determined

Impact on Schema: Not determined

Spec Updated: No. Schema Updated: No

It would be useful to have a language to be able to specify e.g. that in the 'review' process, a reviewer can only change the state attribute and add notes, and in the 'tm matching' process, a tool can only add <alt-trans> elements. After a process is completed, we could then automatically validate the XLIFF files that the constraints have been met according to the specification.

XLIFF2.0/FeatureTracking (last edited 2018-03-05 01:35:06 by bryan.s.schnabel)