< Return to Calendar

* f2f Berlin 2015 (Face-to-Face meeting)
Name * f2f Berlin 2015 (Face-to-Face meeting)
Time Monday, 01 June 2015, 09:00am to 05:15pm WEST
(Monday, 01 June 2015, 08:00am to 04:15pm UTC)



XLIFF f2f 01 June 2015

Present: Uwe, Bryan, Joachim, David, Ryan, Kevin, Felix

Quorum not reached with 5 voters out of 12

ITS Module

[overview of discussed categories and solutions is in the attached ITSProgress.xlsx]


Felix proposing not to have directionality from ITS 2.0 in XLIFF 2.1 since XLIFF 2.1 already does the right thing like HTML5, having 3 value: ltr, rtl, auto, in alignment with UAX9. ITS 2.0 has legacy values ltr, rtl, lro, rlo, which are not recommended anymore. So there should be no mapping from ITS 2 to XLIFF 2.1 for directionality. Probably have a sentence in XLIFF 2.1 explaining the above, i.e. saying why we won’t have ITS directionality in XLIFF 2.1. Once ITS is updated with the proper values for directionality we may have a reference to ITS directionality in XLIFF 2.x again.

Action: felix to supply text about directionality.

Preserve Space

TC discussion said, we don’t need to look at the wiki mapping anymore

ITS Terminology Annotation

Needs to assure that there is no ambiguity about the terminology information: external reference vs. reference to glossary.

Felix: have a different link in the Example 3 – replace http://en.wikipedia.org/wiki/Terminology with a real term , e.g. “rock” http://iate.europa.eu/FindTermsByLilId.do?lilId=325975&langId=en

Action: Felix to re-design the example. Already sent to David and Bryan


Comparing change track module http://docs.oasis-open.org/xliff/xliff-core/v2.0/xliff-core-v2.0.html#changeTracking_module and ITS 2 provenance http://www.w3.org/TR/its20/#provenance

Discussion on change track module use cases. Change track needs to allow inline elements.

Content vs. metadata change tracking. Have provenance in ITS module, without relation to change tracking?

Issues: 1) allow change tracking inline 2) interpret itsm value from the viewpoint of change tracking

One suggestion: have all change track “author” as mapping target for the six pieces of information in ITS provenance, see table here http://www.w3.org/TR/its20/#provenance . Then have ITS provenance to declare the type. If somebody changes “author”, they would have to delete the itsm .

Have a reference from ctr:author to URI that holds the provenance record. Then have itsm:prov=”yes” to trigger the interpretation of ctr:author as a URI:

<ctr:revision ctr:author=”uri-prov-record” itsm:prov=”yes”>

If itsm:prov is changed the referenced ITS prov record (which is at the extension point) also needs to be changed.


1) take ctr as is and combine it with prov records like <ctr:revision ctr:author=”uri-prov-record” itsm:prov=”yes”>

2) like 1), plus allow ctr inline elements

3) re-design of ctr to allow usage of ITS provenance and more


Reference versus everything in author:

ctr:author=”ryan-human-author:df-human-author”. This solution also needs itsm:prov=”yes”, so reference solution is cleaner.

Requirement for XLIFF process: no need to process the reference.


Options again:

  1. have both author as is plus ITS attributes. Pro:
  2. crazy idea to put all ITS information into author field.
  3. Key

Both 2) and 3) need itsm:prov=”yes”

Flag itsm:prov=yes set - > you use ITS attributes in the change track, so you don’t use author.

  1. author and ITS can co-exist. Flag itsm: says “yes” or “no”. Tools that don’t know ITS prov just ignore it.
  2. Final solution agreed was 4)+2) without the flag. On extraction from source the XLIFF author attribute is overloaded with all the its Provenance info except references to external provenance, also all itsm attributes available are populated. Tools that don’t understand itsm just manipulate the xliff author.

In general itsm attrbutes (in scope of ctr) need to be killed when ctr is manipulated w/o itsm support. When itsm info is lost on the roundtrip, its aware mergers need to repopulate Prov from the single author attribute.



If there is provRecords ref on the ITS side: generate several <item> elements, one for each provenance records.


itsm: attributes for provenance can appear also on mrk.

Need a scenario for killing the provenance information. If authorship on upper level is changed it should be deleted on lower level.


“Reference to external provenance information”: not mapped into XLIFF, would need to be mapped via an extension.

XLIFF 2.1 timeline

Shooting for October, but not sure if that is doable.

AI Bryan and Kevin: to backplan from OS by end of October for csd01/csprd01

XLIFF 2.2 moving forward

We will have requirements gathering for 2.2 on Wed June 3. XML serialization and fitting features will continue in XLIFF TC as XLIFF 2.2, but the community wants to go beyond XML and we don’t have mandate to do that in XLIFF TC, as currently chartered

Joachim suggested using fs like HTML for managing layout roundtrip

dF: Create resourceItem with context=“no“ mime type HTML, fs is not for roundtrip just for preview

dF: Please suggest this on June 3, this is just to see and summarize what may come up on 3rd. Christian will represent ULI requirements, Chase will report on remaining gaps in XLIFF:doc coverage.


Object model and other serializations

Discussion on how to move non-XML work items forward. Idea is to move forward in XLIFF TC and see where to publish (Oasis, ETSI, …)

What is the goal: standardize syntax (json-serialization), API, or object model.

Easier to think about something as a json-serialization, not a full-scale object model.

Should not talk about object model but json serialization, potentially also API.

Panel – “serialization panel”?

ITS again – MT Confidence

MT Confidence. On XLIFF Side: matchQuality. What to do with its:annotatorsRef?

Mapping with ITS: must be a URI. Need to take out mt confidence related info from annotatorsRef.

Example from ITS XLIFF Mapping wiki: https://www.w3.org/International/its/wiki/XLIFF_2.0_Mapping#MT_Confidence_.5BTRANSER_TO_XLIFF_2.1_DRAFT_IN_PROGRESS.5D

Handling of conflict with “origin” like with MT confidence.


Rule file

Action: Felix to double check namespace usage https://www.w3.org/International/its/wiki/XLIFF_2.0_Mapping#Rules_file_for_the_mapping



Seperate sub conformances.

ACTION: Felix to create a sentence for the spec.

Allowed characters

Do like in the wiki but also structural elements not including XLIFF elements (up to “file”).


[Meeting adjourned]



1) ITS Module

1. Overview of gaps (dF)

2. not problematic data cats (Term, TA, lang, etc.)

3. space handling (Yves)

4. slr profile (Fredrik)

5. MT Confidence (dF)

6. Provenance + ctr (Ryan)

2) Advanced validation

1. current schematrons and NVDL (Felix, Soroush)

2. schematrons and NVDL to cover the ITS module (Felix, Soroush)

3) Admin

1. pinpoint the current schedule for 2.1 release (Bryan, Kevin)

2. Report on progress of the ISO submission of XLIFF 2.0 (dF)


Short preparation for the requirements gathering panel on Wednesday June 4 (dF)

Non normative work

1. Committee Note: XLIFF 1.2 vs. XLIFF 2 (Yves)

2. Committee Note: XLIFF 2 TBX mapping (Fredrik, dF)

High level issues

Discuss where to work on:

1. JSON serialization

2. OM - XML independent

Re-charter XLIFF TC? Pros and Cons (dF)

The objective of this is to have if possible a TC position on that prior to the OM panel on Wed June 3

Submitter Dr. David Filip
GroupOASIS XML Localisation Interchange File Format (XLIFF) TC
Access This event is visible to OASIS XML Localisation Interchange File Format (XLIFF) TC and shared with
  • OASIS Open (General Membership)
  • General Public

Referenced Items
Name Type Date Action