OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

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

Subject: RE: [xliff] Groups - Event "XLIFF TC Call" added

Dear Helena, Bryan, all,


First let me say that I really appreciate your clear words.


We had a longer discussion process in Lionbridge over the past weeks about our position concerning XLIFF 2.0, how to use it (as a processing format, or only as an exchange format), and about the recent addition (to v2.0) specifically of the bin-unit.


Looking at it, the bin-unit, as Helena points out, breaks the guarantee that XLIFF wanted to give in the first place: That you can take an XLIFF file from any creator, and by knowing the XLIFF spec you can be sure that you know how you will process the translatable (textual) content.


It would be interesting to understand why the bin-unit was added to v1.2. Having it back in 2.0 breaks, as we see it, the fundamental principle of XLIFF again. Please, we are open for any elaboration on this point, did we misunderstand about that principle?


I think that the TC decision process about this feature went too fast, at least too fast to discuss options and alternatives, and consider the issues.


We would propose to split XLIFF into two standards: One Container standard and one Content standard. The Content standard would be XLIFF without the bin-units, and the Container standard would be the bin-units, if you will. The Container would allow to store arbitrary binary files, including XLIFF, alongside property data describing these files. The Container could also be used to store multiple revisions of the same file, which is a very common scenario in the loc process. From any XLIFF file inside the container you could point to any arbitrary file in the same container. This will replace the bin-unit.


Now why will this help us: because it will raise awareness with our clients that arbitrary files which they put into the container are not prepped files as XLIFF files are. This way they will understand that if they put, say, a binary word processor file of a only locally known maker in it, we will not automagically be able to translate it. It will raise awareness with our production people that arbitrary files in the container mean risk, cost, and time. Therefore they will analyze the files properly before approving the handoff, and adjust the offer. When there are only XLIFF files in the Container, they can prepare a cheaper offer.


One might argue that this Container exists: Linport. That might be the case, I do not yet know it well enough to tell. However, to some extend we appear to be in a catch 22 with Linport, as they refuse to use XLIFF as their Content format as long as it is as lax as today. And bin-units would be very lax in their view.


The Container could be as simple as ZIP plus a catalog.xml. I think that is what Linport does.


Thank you for your attention, I am curious about your opinion. And have a great weekend!



Joachim Schurig
Senior Technical Director,

Lionbridge Fellow


1240 Route des Dolines

06560 Sophia Antipolis




From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Helena S Chapman
Sent: Donnerstag, 13. Dezember 2012 16:48
To: Bryan Schnabel
Cc: xliff@lists.oasis-open.org
Subject: Re: [xliff] Groups - Event "XLIFF TC Call" added


Bryan. I would like to point to the elephant in the room and let's have a blunt discussion. I personally have real concerns with the direction of XLIFF 2.0. For example, the ability to include binary entities into XLIFF as a "container". Especially this late in the game for 2.0.

To me, XLIFF is an interchange format for "textual" content for localization purposes during the content life cycle. Using embedding binary in XLIFF as an example again, I want to know very clearly the reason for including binary entities into an interchange format and expect the tools to actually understand how to parse and process that in a interoperable fashion. I maintain XLIFF is NOT a processing format by design though some vendors may choose to use it so, it does NOT serve the purpose of the majority users' intent for using XLIFF.

Why would one want to include binary entity in XLIFF? Is it to pass video files embedded in content between systems? If so, the only thing the translation vendor would need to worry about really is the audio and transcript portion of the file. Why can't one just use SSML (http://www.w3.org/TR/speech-synthesis/) for the purpose of that interchange? Why introduce that complexity into XLIFF? Why can't it be managed as an external reference with an absolute path if needed? When it comes to binary entities, there is too much complexity around how it can be "processed", "understood", and "exchanged" consistently across systems, trying to absorb all that into XLIFF is simply asking for trouble.

XLIFF is becoming a "kitchen and sink" standard in the last few months and I do not agree with this direction. I am very lucky in that I have a much simpler job than most on the TC. I am in charge of my entire company's internationalization and translation architecture, tools and processes and we tell our vendors what to do. For these XLIFF 2.0 features that I disagree with, I simply tell my team that these features are simply passthrus that we do not process or support within our operation. However, for a real tool vendor who has to support more than a single client scenario, things are not as easy. This also points to the fact that we do NOT have enough major tool vendor participation (except for Lionbridge) to make this 2.0 effort really worthwhile.

I have abstained and kept quiet on the last few calls, however, I realized it perhaps is not in the best interest of XLIFF TC or myself if I continue to do so. I would prefer my name is not associated with a standard that cannot be widely adopted by the localization industry.

Best regards,

Helena Shih Chapman
Globalization Technologies and Architecture
+1-720-396-6323 or T/L 938-6323
Waltham, Massachusetts

From:        Bryan Schnabel <bryan.s.schnabel@tektronix.com>
To:        xliff@lists.oasis-open.org
Date:        12/03/2012 12:21 AM
Subject:        [xliff] Groups - Event "XLIFF TC Call" added
Sent by:        <xliff@lists.oasis-open.org>

Submitter's message
Two Notes:

1 - I will spend a few minutes announcing a change in secretary personnel
2 - We've had a very robust mailing list session. I will parse the emails and provide a summary for the agenda so we can hit the ground running
-- Bryan Schnabel

Event Title: XLIFF TC Call

Date: Tuesday, 04 December 2012, 11:00am to 12:00pm EST

Please join my meeting.

Use your microphone and speakers (VoIP) - a headset is recommended. Or, call in using your telephone.

  France: +33 (0) 182 880 780

  Germany: +49 (0) 892 2061 159

  Spain: +34 911 23 0850

  Sweden: +46 (0) 852 500 612

  United Kingdom: +44 (0) 203 535 0611

  United States: +1 (773) 945-1031

Access Code: 905-529-225

Audio PIN: Shown after joining the meeting

Meeting ID: 905-529-225

This meeting counts towards voter eligibility.

=== 1/ Roll call

=== 2/ Administration

--- 1. Approve Tuesday, 20 November 2012 meeting minutes:


--- 2. XLIFF TC officer update

--- 3. Updates to features in SVN: when a ballot is needed, and when a simple acknowledgment of the feature owner will do

=== 3/ XLIFF 2.0 (
http://wiki.oasis-open.org/xliff/XLIFF2.0/FeatureTracking )

--- 1. Features proposed/discussed on the mailing list

 a.  Lots of emails, I will parse them, and summarize here, before the meeting

--- 2. XLIFF 2.0 Technical issues (
http://wiki.oasis-open.org/xliff/XLIFF2.0/FeatureTracking#TechnicalIssuesforXLIFF2.0 )

--- 3. Conformance criteria

--- 4. Charter: Need to bring up to date to reflect XLIFF 2.0

     David's proposal

     Here’s the current charter


=== 4/ Sub Committee Reports

--- 1. Inline text (Yves)

--- 2. XLIFF Promotion and Liaison SC Charter (David)

=== 5/ Current XLIFF business

=== 6/ New Business


Owner: Bryan Schnabel
: OASIS XML Localisation Interchange File Format (XLIFF) TC
: This event is shared with the OASIS Open (General Membership), and General Public groups.
Public Event Link

[attachment "ical_34010.ics" deleted by Helena S Chapman/San Jose/IBM]
To unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: xliff-help@lists.oasis-open.org

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