RE: [xliff] RE: 2.0 Binary Data Module Proposal

[Yves Savourel <ysavourel@enlaso.com>]

Hi Ryan, all,

Here are some comments about the proposed binary module:


=== First, a few notes on 1.2 bin-unit, to place this module into perspective:

The bin-unit element has been in XLIFF since the first version and until 1.2. It was meant to allow tools to work with objects such as images, icons, cursors, etc. which can be embedded into resource files (Remember that the earlier version of XLIFF were more resource-oriented than 2.0). From my experience it has been used very rarely so far.

The idea was that some object could be edited by a dedicated editor (e.g. a bitmap editor), but the text to translate was treated by normal means. After translation a tool could open the binary data and change the binary object to put the translated text there.

This, in my opinion, is a bit different from the intended usage of the binary module.
 

=== Now commenting on the proposal itself:

Like Fredrik, I'm un-comfortable with the proposed binary module.

First I see in the example that the binary element seems to be used for two very distinct purposes:
a) providing a screen-shot of the dialog box
and b) providing the binary data of the controls so they can be modified.

I don't see a problem with illustrative screen shots: it's good to have them. But that should be a different module related to reference material, etc. One can't really have the same processing requirements for both types of binaries. Also a tool might want to support reference screen shot but not 'binary source/target' 


For the aspect of carrying the data/code that need to be modified:

It seems to me that the binary element is used here as a way to transport proprietary un-extracted data/code in a big bag that only tools understanding the format could use. It's not necessarily wrong, but I wonder if that belongs to interoperability.

I'm not sure how much different the proposed binary feature is compared to a <file>: you have some kind of original format and extracted text that need to be modified. And the original format needs to be also modified in addition to the text. Aside from possibly carrying a target version of original format, and all things being relative, this proposal does pretty much the same thing as a <file> with skeleton.

By carrying the other data needing modification in a binary object, we reduce their accessibility and the potential to do things like leveraging of coordinates in an interoperable way.

I do understand the need for extractors to XLIFF and tools editing XLIFF to have a way to carry such non-textual information. I'm simply wondering how long it will take for a binary module like this to conflict with other modules that will want to extend the non-textual information in a more interoperable way (for example a module for the 1.2 coord, font, etc.).


=== Content of <group>:

The current text for <group> says: "One or more <unit> or <group> elements in any order followed by..."
And it seems the schema allows <unit> and <group> to be siblings inside a <group>.
Tom can confirm or correct this.


cheers,
-yves