RE: 2.0 Binary Data Module Proposal

Dear Ryan, Yves,

thank you for more details on the bin-unit.

I understand the use case for additional non-textual data that need to be modified. I would feel more comfortable if we could have a way to transport or define more information about the nature of the data and how it can be modified at some place, but I do not have a solution at hands. I would wish there would be a registry for the (XLIFF?-) private mime types publishers want to add, including processing instructions. Ideally, there would of course be one XLIFF module per each of such applications with complete specification.

There is the other use case with the new SharePoint. If I understand correctly, here you embed or reference whole external files, including those with textual content. As I proposed on Friday, I see the solution for these in a Container format, which could take these files, and you reference them from the bin-units. In my opinion, it should not be allowed to include textual content in bin-units.

I am unsure if it was understood from my Friday mail: The two issues we see as a service company are

1) improper or wide spread use of the bin-unit feature by other implementers, with unrealistic processing expectations. As everyone might imagine it is within the range of our capabilities to get information and implement proper processing e.g. for the Windows resource data.

2) Failure by service staff to discover early in the process the presence of translatable, non-tagged text documents of varying format inside bin-units. Besides this operational aspect there is the theoretical aspect that XLIFF should only include properly marked up textual content, as this is part of its original promise.

It is in the best interest of all parties in the localization process to find solutions for these two problems. As a standards body I see us responsible for problems that arise out of the use of our standard.

For problem 2) we think a Container format is the best solution (and that it solves a number of other problems as well). For problem 1) I have no solution (except defining a module for each application).

Best regards,

Joachim

________________________________
Joachim Schurig
Senior Technical Director,

Lionbridge Fellow

Lionbridge

1240 Route des Dolines

06560 Sophia Antipolis

France

xliff message