RE: XLIFF 2.0

["Schnabel, Bryan S" <bryan.s.schnabel@tektronix.com>]

Hi Klemens,

I am happy to help you with your inquiries about XLIFF 2.0. I am also still hopeful that Jaap will pursue the opportunity for TAUS to become a partner with OASIS to facilitate the active participation of TAUS members in the XLIFF TC. As your astute questions indicate, this is a very opportune time for those in our community who wish to improve XLIFF to join in (and sign up)!

I will answer some of your questions (embedded) below. And I will cc this list of questions to other members who are best positioned to provide answers to subjects for which they are experts. I am cc'ing the XLIFF TC list to open your questions to their expertise.

Among the experts on the list, your questions will reach Yves (as the chair of the Inline Text SC), Rodolfo (as secretary of the TC), David (as your fellow member of TAUS, for one with a unique perspective seeing XLIFF form both points of view), and Helena and Peter (who are closely following the LISA standards). 

Thanks for your interest, and renewed welcome to you and TAUS to join the TC and help make XLIFF the best it can be for our community!

Bryan

-----Original Message-----
From: Dr. Klemens Waldhör [mailto:klemens.waldhoer@heartsome.de] 
Sent: Monday, April 25, 2011 7:58 AM
To: Schnabel, Bryan S
Subject: XLIFF 2.0

Hi Bryan,

at the moment I am trying to gather as much information about XLIFF 2.0 as
possible for TAUS.

I have some questions:

1) Is there a date out when Xliff 2.0 will be officially out?

Bryan> The TC has chosen to make completion of requirements the gating factor for XLIFF 2.0, rather than a calendar deadline.

2) I noted that there is a XLIFF Inline Markup SC but no documents seem to
be produced. Is this correct? I think this is esp. an interesting SC as
Inline markup is the core for good matching (in my view). And I always was a
little bit astonished that TMX uses (partially) different inline mark-ups
than XLIFF (also with regards to attributes). Which makes writing tools
using both standards more complex than required.

Bryan> I will let Yves provide the perspective from the view of the SC. But from the view of the TC, we expect that the work the SC is collecting on the (publically viewable) wiki (http://wiki.oasis-open.org/xliff/OneContentModel/Requirements) will result in a formal document (however this is a work in progress). As for the observations you've made, no arguments from me. You've actually described a big part of the motivation and SC charter.

3) Segmentation: Is it intended to change this segmentation indicator from
mrk to some more meaningful name? What I also wonder - maybe I missed it -
is there a counterpart to seg-source like seg-target? If one thinks a match
comes from a tm this might make sense as the target may be also constructed
from "segments".

4) Is it intended that the segmentation rules applied to an Xliff document
can be added to the document. Obv. one could do this in a header prop group,
but my question goes into the direction if an official tag is foreseen for
that purpose?

Bryan> I will give my answer to 3) and 4) here, and let the others add their views. Segmentation is exactly the topic we are taking on at this moment in the TC. There is a very topical thread (also publically viewable) going on that I invite you to follow (http://lists.oasis-open.org/archives/xliff/201104/msg00005.html)

5) TMX related: Are ideas discussed how a tm can be incorporated into Xliff?
At the moment essentially the alt-trans serves as a "tm" which matches the
current document (or better the segments as sources). Is it intended to add
something like glossary? Idea would be that one could "export" a whole tm
database into Xliff without the need of adding trans-units. I know and
understand that tmx and Xliff serve different purposes, one more database
and the other more document oriented.  But maybe it could be a good idea to
combine both under one umbrella format.  Or should this be done as part of
the extension points? (As some of my ideas could be realized anyway).
Bryan> Yes - plenty of discussions. We are also monitoring the discussions of other groups that are commenting on the future of TMX (like TAUS, for example)

6) DTD: never found an Xliff 1.2 DTD - is this intended?
Bryan> Yes. This is intended. Around the time of XLIFF 1.1 we found that the limitations of the DTD to prohibit the rules we needed to enforce to support the spec. So we moved to XML Schema. We found this to give us more precise control.

7) Trans-units: For some type of source documents it may be good to have an
attribute which allows describing the order or linking of trans-units (if
you think of InDesign which has a complex internal non-sequential (text)
structure, but also for CMS systems). In this way an editor could know which
trans-units follow logically each other while in the Xliff file itself they
are sequentially differently stored. Could be specifies Xpointer or similar.

8) Term matching: In some cases it might be interesting to markup special
parts of a segment (e.g. a group of words) as a term. And also with a
reference to the target. One could use "mrk" element for that  but looking
at the attributes there are many restrictions. I have to add I do not really
understand what non-XLIFF attributes  in " mid, ts, comment, non-XLIFF
attributes " really refers too. Maybe that I can add any attribute? At least
this seems to be the idea behind the description I read. Anyway I think that
an element like "term" with attributes could be more appropriate.

9) Alttrans: In course of the discussion how the match-quality value is
computed it might be also an idea to add "match-description" attribute which
describes how the match value is computed (e.g. based on the Levenshtein
algo, word matching or similar).

I hope that are not too many questions. Thanks for your help.

regards
Klemens