Minutes from XLIFF OMOS TC Public Info Sessions on June 7 and 8 2016

Hi all,

[this also went as BCC to Non-OASIS attendees of the info sessions..

Non-OASIS attendees will not be able to reply to the list, you can send your reaction through the XLIFF OMOS TC commenting facility

https://www.oasis-open.org/committees/comments/index.php?wg_abbrev=xliff-omos 

or

FEISGILTT 2016 <> (on CC)]

as promised please find copy pasted and attached as docx the meeting minutes of Dublin OASIS XLIFF OMOS TC Info Sessions

I am also exposing a pdf version of the same on the FEISGILTT webpage

http://locworld.com/feisgiltt2016-cfp/ 

http://locworld.com/wp-content/uploads/2015/11/FEISGILTT-2016-XLIFF-OMOS-Public-Info-sessions.pdf

I invite every attendee to post more detail or amendments to the draft minutes I posted.

The plan is to approve these minutes as minutes of record in the next XLIFF OMOS TC conference call

https://www.oasis-open.org/committees/event.php?event_id=41695

Finally, these are just the OMOS related info sessions, the XLIFF TC list is addressed only FYI (on CC). Once I'll make the XLIFF TC info session minutes these will be sent to XLIFF TC and CCed to OMOS, again all OASIS attendees will be on BCC.

Cheers and thanks for your attention

dF

Dr. David Filip
===========

OASIS XLIFF OMOS TC Chair

OASIS XLIFF TC Secretary, Editor, Liaison Officer

Spokes Research Fellow

ADAPT Centre

KDEG, Trinity College Dublin

Mobile: +420-777-218-122

FEISGILTT 2016 XLIFF OMOS Public Info
sessions

Draft meeting
minutes                Tue June 7 and Wed June
8, 2016

Participants:

[participation in particular sessions was
not tracked, this list is based on FEISGILTT 2016 participation]

XLIFF OMOS TC members

Chair

David Filip (ADAPT Centre)

Secretary

Loïc Dufresne de Virel (Intel),

Members

Ryan King (Microsoft), Kevin O’Donnell
(Microsoft), Soroush Saadatfar (ADAPT Centre @ LRC @ University of Limerick), Felix
Sasaki (Individual), Phil Ritchie (Vistatec), Chase Tingley (Spartan Software)

Public

Victor Alves (Individual), Jan Bareš (Moravia), George
Bina (Syncro Soft), Konrad Chmielewski (XTRF), David Clarke (Welocalize),
Mariza Flores (Thousand Words Translations), Andreas Galambos (Transmission Übersetzungne), Andrew
Gibbons (Welocalize), Ján
Husarčík (Moravia), Łukasz Kaleta (XTRF), Gary Lefman
(Cisco), David Lewis (ADAPT Centre),
Ian Morris (Individual), Dimitris Orfanoudakis (TAUS), Achraf Oumghar
(Lionbridge), Felix Sasaki (DFKI), Uta Seewald-Heeg (Anhalt University of
Applied Sciences), Richard Sikes (Content Rules), Vinod Sudharshan (TAUS),
Angelika Zerfaß (zaac).

 

XLIFF OMOS TC Public Info Sessions
started at 1.30pm WEST on June 7th 2016.

XLIFF OMOS Debrief

Chair: dF

Panelists: XLIFF OMOS TC membership

dF debriefed the delegates on the XLIFF
OMOS TC formation at OASIS https://www.oasis-open.org/news/announcements/call-for-participation-xliff-object-model-and-other-serializations-xliff-omos-tc
along the lines of the joint OASIS & Gala briefing webinar http://bit.ly/XOMOSWebinar that took
place in January 2016.

Charter of the XLIFF OMOS TC https://www.oasis-open.org/committees/xliff-omos
has been reviewed

In particular https://www.oasis-open.org/committees/xliff-omos/charter.php

Scope of Work, IPR Mode and Audience of the
new TC that is also called the sister committee of the TC. The community
concluded at FEISGILTT 2016 in Berlin that the new committee needs formed at
OASIS https://lists.oasis-open.org/archives/xliff/201507/msg00028.html
and http://locworld.com/wp-content/uploads/2015/04/FEISGILTT-2015-Public-Info-sessions.pdf

dF explained how it was necessary to form
the new TC because the new standardization items requested by the XLIFF
community in Dublin and Vancouver 2014 were out of scope of the original XLIFF
TC Charter (https://www.oasis-open.org/committees/xliff/charter.php) albeit
clarified and updated. stressed the importance of the Non-Assertion IPR mode
for open source reference implementations of JLIFF and any APIs to be based on
the XLIFF OM.

 

XLIFF OM Work in Progress

Chair:
dF

Panelists:
XLIFF OMOS TC membership

 

dF explained about the OMOS TC plan to work
on git as a version control. Since OASIS hasn’t yet launched git as a version
control option for TCs, dF agreed with OASIS Admins that a temporary GitHub
repository https://github.com/DavidFatDavidF/XLIFFOM
will be used with a Readme vetted by the OASIS Admins.

dF explained that the UML class diagram
that the TC has been discussing https://www.oasis-open.org/apps/org/workgroup/xliff-omos/email/archives/201605/msg00002/xliff_OM_v4.png
is being redeveloped with amendments as the discussion progresses on the GitHub
repository.

The panel agreed that the group and unit
data items were distinct entities not only in the XML serialization but also in
the abstract data model. 

Ryan was arguing that segment and ignorable
were actually only facets of a single subunit data item. The panel actually
reached consensus that it was indeed the case and not a JSON driven artifact.
The resulting action item for dF and Chase and whoever is going to participate
on the XLIFFOM repository is to introduce segment and ignorable as facets of a
single subunit data item.

 
 
  
  
  
  
  
  
  
  
  
  
  
  
 
 
 

 

Fig. 1 Fully linear inline data model

dF explained that the subunit or inline
data model within the XLIFFOM is fully linear not allowing for XML-like
recursion. OMOS TC previously agreed that <pc> and <mrk> were XML
specific and not needed in the abstract model.

Andrew Gibbons (Welocalize) suggested that
information on XLIFF using inline pair tags will get lost in a transform
facilitated by the XLIFFOM. dF agreed that this was the case, however the pair
tags have an exhaustively defined equivalence in XLIFF 2 and XLIFF Modifiers
were free to transform pair based inline notations into atomic marker based
notations and vice versa (if possible WRT XML well-formedness constraints).
Most importantly, Mergers were
obliged to accept pair or atomic inline tags disregarding whether the Extractor had actually used pair or
atomic representations during the initial Extraction.
dF also said pooling/joining of all segments and ignorables within each unit
was a recommended best practice for Mergers.
Mergers are obviously allowed to
perform equivalent modifications when accepting XLIFF Documents after a roundtrip.

 

JLIFF 1.0 Work In Progress

Chair: dF

Reporter: Ryan King (Microsoft)

 

Ryan reported on the JLIFF examples
generated between Yves and himself.

Ryan explained how JLIFF was just another
serialization and the true challenge was to make sure that both XLIFF and JLIFF
share the same data model (OM).

[Ryan’s
presentation will be uploaded]

XLIFF OMOS TC Public Info Sessions were
adjourned on 7th June 2016 at 4pm WEST

 

XLIFF OMOS TC Public Info Sessions
started at 1.30pm WEST on June 8th 2016.

1st TMX Symposium (Is this the time for TMX
Next?)

Chair: dF

Reporter: Angelika Zerfaß (zaac)

 

The TMX Symposium started with Angelika’s
industry wish list presentation:

http://locworld.com/wp-content/uploads/2015/11/TMX-wishlist.pdf

This gave to the delegates the idea what is
the TMX use case and what were the regular user’s frustrations with the current
version of the standard and a variety of its implementations.

ReporterŁ Dave Lewis (ADAPT/TCD)

Dave Lewis introduced what features would
be needed to make TMX based data useful as Linked Open Data

http://locworld.com/wp-content/uploads/2015/11/TMX-lod.pdf

Most importantly, TMX has no explicitly
defined fragment identification mechanism, which see the major drawback in
making TMX stores work as LOD.

Discussion (Workshop: Is this the time for TMX Next?)

dF explained that the XLIFF OMOS TC was
chartered, so that TMX would fall within its scope. The chief reason for the
Chartered scope to allow for further development of TMX was the fact that ETSI
ISG LIS that came to own TMX after the LISA demise in 2011 was disbanded in late
2015. However, OASIS XLIFF OMOS will not be legally entitled to perform any
work on maintenance or continued development of the TMX standard until OASIS
has negotiated the IP transfer with ETSI. The status of this negotiation is
unclear. It’s even been impossible to find out if the negotiation started to
date.

Based on discussing the position statements
of the reporters, the following strengths, standardization gaps and issues and
with the current TMX version and implementations were identified.

Strengths

·       
Multilingual – good for post
mortem bulk exchange

·       
Widely adopted

o  
However falling short of the
lossless leverage promise due to incompatible implementations (see
implementation issues)

·       
Storage efficient (unordered,
doesn’t store context)

o  
This strength was perceived as
outdated with the steep drop of storage pricing that happened since 2004.

Missing features:

·       
Common explicitly defined fragment
identification mechanism

o  
Parts of TMX files cannot be
reliably referenced

·       
Context matching, either proper
context or id based – possible issues with existing patented IP owned by SDL
and Lionbridge, if this gap was to be filled in the next gen standard.

·       
Insufficient provenance
specification

·       
Mark up salad – hard to support
inline data model

o  
Need to catch up with the pruned
down XLIFF 2 inline data model

·       
Even if implementers were
sharing SRX rules along with their TMX files, the TMX standard lacks any
re-segmentation provision, which is probably hardly possible with the basic design
principle of an unordered segment pairs collection.

Implementation issues

·       
Most of the implementations are
not Level 2 compliant, as result implementations are not able to properly
exchange segments with inline markup, which in turn lowers leverage that can be
achieved by TMs exchanged via TMX. See also Mark up salad.

·       
Implementers don’t implement
SRX along with TMX, as originally intended by LISA OSCAR, as result the
receiving implementer don’t know what kind of segmentation rules was applied
when creating the TMX, which in turn lowers leverage.

o  
Some implementers blatantly
disregard the TMX inline markup provisions and use their own proprietary
non-XML markup that cannot be even recognized as markup by other
implementations, thus farther damaging the exchanged leverage (based on implementation
cases reported by Angelika).

§  However, this is something not addressable by standardization proper.
It’s a mindset and evangelization issue. Implementers simply cannot setup their
own secret markup within payload of an exchange format spoiling the game for
everyone else.

·       
Lack of a powerful state of the
art TMX editor

o  
Olifant still the best usable
toll available

o  
Need better filtering and
analytic capabilities

Possible solutions 

(Conclusions of the Workshop after the
coffee break)

 

1.    
Develop TMX Next at XLIFF OMOS
TC

·       
Blocking issues: 

o  
OASIS need to conclude TMX IP
transfer negotiation with ETSI. Outlook unclear.

·       
Possible issues down the road:

o  
Need to make sure that Context
Matching IP owners are represented. Lionbridge currently not on the TC. The IP
owners would either need to provide their Non-Assertion Covenants to protect
the TMX Next implementers, or the IP would need to be worked around.

·       
Advantages:

o  
Clear upgrade path, TMX next
would be a clear successor of TMX 1.4b (1.4.2)

 

2.    
Develop an XLIFF 2 profile that
would fully replace TMX in TM exchange scenarios

In the XLIFF Symposia (held since 2010, as
part of FEISGILTT since 2012) it transpired that some tool makers and service
providers were using XLIFF as a leverage facilitating exchange format to
overcome TMX related issues and lack of TMX development since 2004 or even
2001.

Several delegates suggested that XLIFF can
be used for TM exchange purposes, since the storage efficiency advantage of TMX
has become obsolete since 2004 due to the continued price drop of storage
cpapacity. However, the need to duplicate the source language with each new
XLIFF file per target language seemed prohibitive from the point of view of
transfer bandwidth.  

Ryan King (Microsoft) suggested that the
reference language mechanism available through the translation candidates
module should be used to fully replace TMX as multlilingual TMX exchange
format.

After a short discussion, mainly between
Ryan and dF, it was agreed that such a profile can be made fully XLIFF 2
conformant. The main aspects being:

1.     
The TM exchange XLIFF MUST
contain all source sentences in core <source> elements

2.     
The trgLang attribute MUST NOT
be defined (hence no core <target> elements in the file).

3.     
All <mtc:match> elements
REQUIRE the OPTIONAL reference attribute to be set to “yes”.

4.     
Each of the <target> children
of all the <mtc:match> elements would REQUIRE their OPTIONAL xml: lang attribute
to be set to the BCP 47 tag value corresponding to one of the target languages
of the multilingual TM.

 

·       
Blocking issues: 

o  
N/A

·       
Possible issues down the road:

o  
The status of TMX as a legacy
format could not be clearly addressed.

o  
Possible change management
issues when pushing the new exchange format adoption.

§  Nevertheless, Angelika said that her customer stakeholders don’t
care what the TM exchange standard is called (they don’t necessarily know that
it is currently TMX) provided that they do not lose leverage due to the
exchange vehicle. 

·       
Advantages:

o  
Shared inline data model with
XLIFF 2 for free – hence no leverage loss due to incompatible inline markup

o  
Re-segmentation possible

o  
TMX transfer negotiations
between OASIS and ETSI could be dropped.

o  
Would not infringe on SDL and
Lionbridge context matching IP.

 

XLIFF OMOS TC Public Info Sessions were
adjourned on 8th June 2016 at 3.50pm WEST

Attachment:
FEISGILTT 2016 XLIFF OMOS Public Info sessions.docx

Description: application/vnd.openxmlformats-officedocument.wordprocessingml.document