OASIS XML Localisation Interchange File Format (XLIFF) TC

 View Only

[xliff] XLIFF migration policy

  • 1.  [xliff] XLIFF migration policy

    Posted 08-02-2002 09:29
     MHonArc v2.5.2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    xliff message

    [Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


    Subject: [xliff] XLIFF migration policy


    All:
    
    Below is the Migration Policy document with all suggestions
    implemented,  including those from the latest discussion involving
    Mark,  Gerard and Christian.
    
    An item shall be added to next week's meeting agenda for final comments
    & request for motion / second to conduct an email ballot to formally
    accept the policy statement.
    
    Regards,
    Tony
    
    
    
    
    --
    Tony Jewtushenko    mailto:tony.jewtushenko@oracle.com
    Sr. Tools Program Manager   direct tel: +353.1.8039080
    Product Management - Tools Technology Team
    Oracle Corporation, Ireland
    
    
    Title: Migration Policy

    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 desBois on cross-release compatibility. Removed �WIP� references, and references specific to version numbers 1.0 / 1.1.

     

     

    Migration Policy:

    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:
      1. Shall be comprised of small changes that would not require re-certification of supporting tools or technologies
      2. Shall deprecate but not remove any features present in the previous release.
      3. Shall increment the version number to the right of the decimal point.
    • As a guideline,�Major� releases
      1. May be comprised of significant architectural changes that may require re-certification of supporting tools and technology.
      2. May delete features that were deprecated in previous releases.
      3. 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 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 lists will be closed if they existed as open lists in a previous release.

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

     

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

     

    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.

     

     

     

    Attachment: Tony.Jewtushenko.vcf
    Description: Card for Tony Jewtushenko



    [Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


    Powered by eList eXpress LLC