XLIFF
1.1 W.I.P. – 1.0 to 1.1 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.
|
Document Conventions:
The document is coded in the following way (adhering
to Peter Reynolds’s document convention):
Green if there is agreement
Navy if more discussion is needed
and red if it is contentious.
Where I have
made a change I have emphasised the changed word.
Migration Policy Proposals:
Rules for Major vs. Minor releases:
Support for Existing Users:
Rules for Name Changes:
Impact of Migration on Users Organisations:
Cross-release Compatibility
Guidelines:
User Migration Assistance
Marketing, Public Relations and Education:
Rules for Major vs. Minor releases:
- 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-certification of supporting
tools or technologies
- Shall deprecate
but not remove any features present in the previous release.
- Shall increment
the version number to the right of the decimal point.
- As a guideline, “Major” releases
- May be comprised
of significant architectural changes that may require re-certification 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 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 Existing Users:
- Deprecated support
for changed elements, values or attribute names, at least until next Major
version number revision.
- Enumerated lists are
a potential issue if they are closed.
Therefore, no 1.1 lists will be closed if they existed as open
lists in 1.0.
Rules for Name Changes:
- Name changes to
required elements and attributes will be considered only if semantics
change.
Impact of Migration on
Users Organisations:
- Where appropriate, the
TC will audit food-chain migration and compliance issues when deciding on
architectural changes to 1.0. 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.
Cross-release Compatibility
Guidelines:
- 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.
- Tools must not
delete data that it does not understand.
- Tools must preserve
unknown elements in the file.
User Migration Assistance
- A Migration Policy
Statement will be published as section of each specification.
- A Migration guidelines
white paper will be authored and provided as a deliverable of each
release.
- A “Migration Support Kit” – containing Whitepaper,
Sample Files, and possibly sample XSLT’s - will be made available for download
at the XLIFF TC website.
Marketing, Public Relations and
Education:
- Formal Marketing, Public Relations, and
Education strategies and plans shall be devised as part of the rollout of
new releases.