XLIFF Migration Policy

Version Information:

Version	Date	Author	Description
1.0	11 June 02	Tony Jewtushenko	Initial Document
1.01	24 July 02	Tony Jewtushenko	Revisions based on 23 July 2002 TC Meeting.
1.02	1 Aug 02	Tony Jewtushenko	Input from Mark Levins, Christian Lieske, and Gerard Cattin des Bois on cross-release compatibility. Removed “WIP” references, and references specific to version numbers 1.0 / 1.1.
1.03	6 Aug 02	John Reid	Revisions based on TC meeting 6-Aug-2002

The Technical Committee will evaluate each individual release and classify it as “Major” or “Minor” release.
As a guideline, “Minor” releases:

Shall be comprised of small changes that would not require re-qualification of supporting tools or technologies
May deprecate but not remove any features present in the previous release.
Shall increment the version number to the right of the decimal point.

May be comprised of significant architectural changes that may require re-qualification of supporting tools and technology.
May delete features that were deprecated in previous releases.
Shall result in an increment to the version number to the left of the decimal point.

In general, a Minor release will have stricter rules on changes than Major releases: Minor releases will usually be comprised of small and superficial changes and bug fixes to an existing specification rather than deep architectural changes which would typically be implemented only for Major releases.

Support for deprecated elements, values or attribute names, at least until next Major version number revision.
On a Minor release no list may be closed, if it was open in a previous release. On a Major release a list may be closed.

The names of required elements and attributes will not be changed. However, a new element/attribute may be added that has different semantics. The new element/attribute would replace the current required element/attribute, may or may not be required, and may or may not be deprecated. The replaced element/attribute would no longer be required.

Where appropriate, the TC will audit food-chain migration and compliance issues when deciding on architectural changes to a release. The “food chain” describes the dependencies within related organization. For instance translators for a localisation vendor company, localisation engineers for the publishing company and software developers are all different point on the food chain, and may be affected differently by different types of changes.
Results of such an audit may influence the TC’s release and migration strategy.

Tools designed to support Minor XLIFF releases should provide backward compatibility for files that adhere to the same major release specification. For instance, tools that support version 1.1 files should be able to cope with 1.0
Tools designed to support XLIFF should not upgrade the version of a file without either warning the user or requiring explicit UI or command line setting.
For files created with and complying to a later version of XLIFF, tools must preserve unknown elements in that file.
For files created with and complying to a later version of XLIFF, tools must not delete data that they do not understand.

For each major release it is the intention of the Technical Committee to make available the following material:

A Migration Policy Statement
A Migration guidelines white paper
A “Migration Support Kit” – containing Whitepaper, Sample Files, and possibly sample XSLT’s

It is the intention of the Technical Committee to make available Formal Marketing, Public Relations, and Education strategies and plans as part of the rollout of new releases.