• XLIFF2.0Goals

XLIFF 2.0 - Goals and Requirements

These are the goals and requirments for XLIFF 2.0.

Important Dates for XLIFF 2.0

• October 2008 - Review the goals, measure readiness
• April 2009 - Vote on the first draft

Goals Evaluated by the XLIFF TC

• Must have - Has to be part of the next release.
• Should have - Will probably be part of the next release.
• Nice to have - Good ideas that we want to record but are not required to be in the next release (could be goals we accomplish, but do not tie to the approval of XLIFF 2.0).

Must Have

• Create an XLIFF 2.0 Requirements Document (Similar to XSLT 2.0 Requirements Document http://www.w3.org/TR/xslt20req) [Bryan, Rodolfo]

  • Initial draft is here: http://www.oasis-open.org/apps/org/workgroup/xliff/download.php/26820/XLIFF-2%5B2%5D.0_requirements.htm

• Create a bare-bones XLIFF core, then provide extension modules that support additional features. [Magnus, Christian]
  • "Simplify, Extend and Clarify" - V2.0
    • (Core XLIFF functionality would be in primary XLIFF namespace; would be very simple to implement.) (Extensions would provide support for more complicated features like, Segmentation, Pre-Translation, Generic Inline Markup, etc.) Magnus said that he will try and get back to this and add more information.

  • Official XLIFF guide for subsetting the XLIFF XSD (http://www.oasis-open.org/archives/xliff/200709/msg00008.html)

  • Named Types for XLIFF XSD (http://www.oasis-open.org/archives/xliff/200709/msg00007.html)

• Reference implementations or toolkit(s) similar to DITA [Rodolfo]
• XLIFF validator tool to be included in a toolkit [Rodolfo]

• Enable internal-file to contain XML Markup, not CDATA [Christian] (http://www.oasis-open.org/archives/xliff/200709/msg00006.html)

  • Bryan mocked up samples of how this could be done (http://lists.oasis-open.org/archives/xliff/200806/msg00005.html)

Should Have

• Submitting to ISO once XLIFF becomes an OASIS standard [Tony]
• Additional Representation Guides (DITA,.NET / Win32, Docbook)

  • Proposed ICU Reference Guide http://source.icu-project.org/repos/icu/icuhtml/trunk/design/locale/xliff-profile-icuresourcebundle-1.2.htm [Eric]

• Subsetting / restricting XSD as proposed by Christian - V2.0 Should have but could be Must have. We will wait until Christian discusses with TC
• Version control Metadata - need to track revision information - V2.0

• Include xml:tm in the non-normative section (http://www.lisa.org/standards/xmltm/)

Nice to Have

• Ability to store Multilingual Content. - (will be promoted to Must or Should if a champion is assigned) We had a brief discussion on this and various questions were raised about how this would work. Bryan mentioned that his company achieve this through using the file element and having the same id and source for corresponding trans units. It was agreed that we would find the owner for this and they should champion it. Until then we will keep it on the requirements doc.
• XLIFF Round Trip tool could be modified to support [Bryan] (A goal that will be done, but not a requirement for XLIFF 2.0):
  • Feature updates:
    • Update to XLIFF 1.2
    • Add option to produce minimalist or maximalist XLIFF round trip

  • DITA/ITS -> XLIFF -> Translated DITA model

  • (Bryan: "It looks like I can change the xliffRoundTrip Tool license from GPL to Apache {according to an inquiry I made to licensing@fsf.org, the GPL license expert debunked our misconception that 'Once something has a GPL license it is impossible to get out of it'}")

Discarded Proposed Goals

The following ideas were discussed. The TC decided that they are not in scope for XLIFF 2.0.

• Create RELAX NG version of XLIFF Schema

Potential Goals under consideration

The following ideas have been raised. They are potential goals that the TC will consider.

1. Rodolfo suggested adding the possibility to split and merge segments in XLIFF 2.0.
   • Magnus commented on work done in the Segmentation SC.
2. Schema Catalogues; host a namespace Catalogues for XLIFF 3rd party custom / extension namespaces. - V2.0 –It was agreed that Rodolofo should look at catalogues which OASIS has already developed.
3. More work on inline-elements: - v 2.0
   • Separate inline elements from other elements?
   • Maybe as an extension?
   • Stronger rules for when to use each inline tag?)
4. Define a multi-lingual "Localisation Kit" format, which may include:
   • (XLIFF content + original source material+ all target language files+ skeleton files + reference files + some sort of manifest document describing/defining the payload.)
   • Could be part of XLIFF 1.2 adoption.
5. Using XLIFF as a primary content authoring container. – V 2.0 (Author stores contend directly to XLIFF instead of another proprietary format.)
6. Terminology Markup – (Has been suggested by Kara Warburton of IBM some time ago to support terminology markup such as translate (yes/no), subject-categorization, type, etc.) No additional information from Kara
7. Create a means for XLIFF tool providers to have their implementations certified or tested for interoperability

8. Suggestion for schema cleanup towards 2.0 (http://lists.oasis-open.org/archives/xliff-comment/200711/msg00004.html)

9. Implementer FAQ Entry / Suggestion (http://lists.oasis-open.org/archives/xliff-comment/200711/msg00005.html)

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

11. Improving whitespace handling (http://lists.oasis-open.org/archives/xliff/200802/msg00012.html)

12. Ideas from Asgeir
    • [Better support for XML localisation]
      • 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?
    • [change-tracking / version control]

      • preliminary support through the <phase> element and phase-name attribute.

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

    • [Fine-grained validation & permission control]

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

    • [Document-centric vs Resource-centric translation]
      • 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?
    • [Resource Inheritance]
      • 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'.
    • [XLIFF Templates]
      • provide a special target-language-neutral XLIFF template 'blue print' that is used to initialize each language-specific XLIFF file.

Issues collected from xliff-comment list (categorized by TC as necessary for 1.2 errata, and 2.0 requirements)

The following ideas have been raised on the XLIFF Comment List. They have been considered to be worthy of noting in XLIFF 1.2 errata, but not substantive, as to cause delay in OASIS Ballot.

• (also listed in above potential goals) Mime-type for XLIFF (http://lists.oasis-open.org/archives/xliff/200802/msg00011.html)

• Small inconsistency between the schema and specification with regards to count-type attribute values (http://lists.oasis-open.org/archives/xliff-comment/200710/msg00000.html)

• The 'datatype' attribute is specified with a default value of 'Empty string'. This should be 'undefined' (http://lists.oasis-open.org/archives/xliff-comment/200710/msg00001.html)

• Schema glitch in <xliff> element definition (http://lists.oasis-open.org/archives/xliff-comment/200711/msg00000.html)

• Tool element inconsistency between spec and schema (schema allows text) (http://lists.oasis-open.org/archives/xliff-comment/200711/msg00001.html)

• Content Model for <alt-trans> element enforces order (http://lists.oasis-open.org/archives/xliff-comment/200711/msg00003.html)

• (also listed above in potential goals) Suggestion for schema cleanup towards 2.0 (http://lists.oasis-open.org/archives/xliff-comment/200711/msg00004.html)

• (also listed above in potential goals) Implementer FAQ Entry / Suggestion (http://lists.oasis-open.org/archives/xliff-comment/200711/msg00005.html)

Some transient comments regarding Goals vs. Requirments

• # Rodolfo: We should not tie all of the goals to a specific release version (i.e., 2.0). Some of the goals should be attached to point releases, and made available with or without passage of 2.0.
• # Christian: We should vote on passing 1.3, or other point releases. We've already voted to focus on 2.0, not point releases
• # Rodolfo: Not proposing point releases - Just want to not hold up good deliverables, like Representation Guides, or Release of newly licensed, update xliffRoundTrip Tool by tying them to a specific version
• # Andrzej pointed out the moving from 1.1 to 1.2 took years
• # Bryan: Some of the goals lend themselves to being requirements for our next official release; some are more suited as goals that should be implemented as soon as they are complete. Bryan volunteered to create a survey which lists all of the documented goals, and asks members to classify each according to whether they think it should be a requirement for XLIFF 2.0, or a goal to be implemented along the way
• #Tony suggested we use the following classification for proposed functionality:
  • Must have which has to be part of the next release.
  • Should have which will probably getting into the next release.
  • Nice to have which is a good idea that we want to record but is unlikely to be in the next release.
    • We agreed it would be good to have a requirements document similar to XSL 2.0.
    • We agreed to put proposed functionality into a table in the WIKI which showed this detail.
    • We will ask Rodolfo to check whether there is a template document for requirements.