David,
There are a number of factual errors in your below mail which I would like to correct. This is because I would like to have a constructive discussion,
and to avoid wrong history keeping records.
1)
The ballot on the bin-unit was announced ad-hoc, in the TC call, after 2 work days of the bin-unit being discussed on the mailing list.
2)
The voting on the bin-unit feature went with 3 abstains, all others were yes. The abstains were Rodolfo, Fredrik, and myself. In voting,
an abstain typically means that you have not yet been able to form a clear decision.
3)
As I see it, Helena, and later I, were making (different) constructive proposals to solve the problems we see. You claim however that
we are non-constructive. Please explain your position.
I would really appreciate if we could get a discussion about what XLIFF tries to achieve. As I said in my previous mail, our assumption is that
an XLIFF file’s content can be translated without additional knowledge other than the XLIFF spec. If that is a wrong assumption please elaborate.
Thank you,
Joachim
From: Helena S Chapman [mailto:]
Sent: Freitag, 14. Dezember 2012 20:24
To: Dr. David Filip
Cc: Bryan Schnabel; Schurig, Joachim;
Subject: Re: [xliff] Groups - Event "XLIFF TC Call" added
I am the first one to admit, I am not in the best position to be on the XLIFF calls to make judgements on some of these issues sometimes. Having all these features proposed
in 4Q is also not great timing for me at work considering a lot of us are getting pulled different directions to accomplish good revenue results by year end. Having said that, my juggling different job responsibilities does not excuse me for letting this one
and maybe even others fall thru the cracks. I take full responsibilities for not voicing this earlier and I will take initiative to ensure the IBM voting members on this TC voice their concerns timely in the future. Otherwise, we are better off not attending
at all.
I officially rescind my position if I had voted for it previously, I thought my position was abstain and in one of the meetings I had asked for more time for discussion on some line items though
I cannot say which one it was at this point. My apologies for those who were inconvenienced by this. I would vote for NO on this today. Others from the IBM can voice their own opinions.
In the last three meetings, we were asked to vote on more features than I have ever seen previously in the limited amount of time I was involved. I am quite uncomfortable with the direction switching
from slow dance to hip hop in less than 0.5 seconds. I personally am not prepared and did not have the time to absorb all the comments and emails prior to the meetings. This may be an indication that I may not be the best person from IBM to participate in
this activity and that's something I will need to consider carefully for next year's activities.
From: "Dr. David Filip" <>
To: "Schurig, Joachim" <>
Cc: Helena S Chapman/San Jose/IBM@IBMUS, Bryan Schnabel <>, ""
<>
Date: 12/14/2012 01:44 PM
Subject: Re: [xliff] Groups - Event "XLIFF TC Call" added
Joachim, Helena, all,
First of all I am happy to see that more voting members are getting active in mailing discussion. That is very good for representativeness and for quality of the standard.
What I do not understand is why you have not voiced your concerns in the mailing list discussion ABOUT THE FEATURE(s) and in the feature freeze meeting(s). I was looking up minutes, these just say that the motion (for bin data) carried. Still, as far as I remember
there were a couple of abstentions and the only person voting against the binary feature was Rodolfo. The motion carried with a safe majority, and only one of the eligible voter's was from Microsoft.
I am personally very happy that Microsoft is taking initiative and that they listened to the call for identifying gaps in the standard. To me it shows commitment to implementing the standard.
Now, as Yves rightly pointed out, we are far from even committee draft, not talking about committee specification that will in turn go for PUBLIC REVIEW.
The Committee spec will go for public review with or without ANY of the "approved" features as per committee consensus or ballot resolution. The features being approved does not mean anything more or anything less than that the owner has got the TC mandate
to develop a detailed specification of the feature for the current Editor's draft.
I discourage anyone from making gestures that do not help making a better standard, on the contrary, I encourage constructive discussion on features and their technical elaboration. Ryan who is technically elaborating features and change requests on behalf
of Microsoft had laid them down in a transparent way following the chair's call for feature freeze. If you dislike some of them you have the same power as any other (voting) TC member to stop them by engaging in constructive discussions, specifying alternatives,
and honest participation in ballots. IMHO it would have been more transparent, open, and honest to try and stop them before they were approved for elaboration, not to waste anyone's time, if you indeed feel so strongly about some of them.
I totally agree with Helena that abstentions do not bring us anywhere. As I pointed out after the last meeting, one positive vote will carry a motion if the rest of voters will abstain.
At the same time, ballots should not be overused and should be called only after robust mailing and meeting discussion have covered the logical space of the issues and revealed that the competing views are not inclined to an unanimous consensual solution.
I maintain that this is how this TC has been using ballots, and I stress that this was the case even close to the feature freeze meetings. Discussions always happened for several business days, electronic ballots were open for 7 days, and ballot resolution
meetings had FULL participation of voting members.
I do not understand why many have not used their voting right in a transparent way.
Please address in this thread general process and planning issues and get back to the feature and change request e-mail threads if you want to comment on specific features such as the binary data feature.
i also encourage specific contributions to the specification development that we are unfortunately still lacking.
Best regards and have great weekend
dF
Dr. David Filip
=======================
LRC | CNGL | LT-Web | CSIS
University of Limerick, Ireland
telephone: +353-6120-2781
cellphone: +353-86-0222-158
facsimile: +353-6120-2734
mailto:
On Fri, Dec 14, 2012 at 4:42 PM, Schurig, Joachim <> wrote:
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
________________________________
Joachim Schurig
Senior Technical Director,
Lionbridge Fellow
Lionbridge
1240 Route des Dolines
06560 Sophia Antipolis
France
From:
[mailto:]
On Behalf Of Helena S Chapman
Sent: Donnerstag, 13. Dezember 2012 16:48
To: Bryan Schnabel
Cc:
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 <>
To:
Date: 12/03/2012 12:21 AM
Subject: [xliff] Groups - Event "XLIFF TC Call" added
Sent by: <>
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
Description
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.
Agenda
=== 1/ Roll call
=== 2/ Administration
--- 1. Approve Tuesday, 20 November 2012 meeting minutes:
https://lists.oasis-open.org/archives/xliff/201211/msg00114.html
--- 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
http://www.oasis-open.org/committees/xliff/charter.php
=== 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:
For additional commands, e-mail:
