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
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!
Senior Technical Director,
1240 Route des Dolines
06560 Sophia Antipolis
From: email@example.com [mailto:firstname.lastname@example.org]
On Behalf Of Helena S Chapman
Sent: Donnerstag, 13. Dezember 2012 16:48
To: Bryan Schnabel
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.
Helena Shih Chapman
Globalization Technologies and Architecture
+1-720-396-6323 or T/L 938-6323
From: Bryan Schnabel <email@example.com>
Date: 12/03/2012 12:21 AM
Subject: [xliff] Groups - Event "XLIFF TC Call" added
Sent by: <firstname.lastname@example.org>
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
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 https://lists.oasis-open.org/archives/xliff/201209/msg00001.html
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
Group: OASIS XML Localisation Interchange File Format (XLIFF) TC
Sharing: 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: email@example.com
For additional commands, e-mail: firstname.lastname@example.org