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

["Schnabel, Bryan S" <bryan.s.schnabel@tektronix.com>]

Hello,

I've received word that Ryan and Uwe are on holiday and will not attend today's meeting. I think it will be best to have a conversation on what to do next with the binary unit when they are can attend.

So rather than having the next steps conversation today. I hope we can summarize the many voices we've heard, and try to prepare points of interest so we might have a very constructive session when all are in attendance.

Here's a preliminary framework as I understand it. Perhaps we can flesh this out in order to best come to conclusion:

=================================
Notes on binary unit threads

- Ryan provided a very comprehensive specification of the proposed module (see the PDF he attached earlier)

- Helena commented that the bin-unit expands the scope of XLIFF beyond textual, making it unwieldy
  (echoed later by Joachim "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.")

- Fredrik/Joachim
1) Improper or wide spread use of the bin-unit feature by other implementers, with unrealistic processing expectations.
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. 


- Yves said:
1) Bin-unit has been part of XLIFF from the beginning, though rarely used. Ryan's proposal changes its traditional use
2) It seems to be used for two different purposes, and should focus on one or the other (not one module for two purposes)
3) Why not use <file> and <skeleton>?

=================================

Personally, I am very excited with the prospect Yves proposed in 3). After the meeting I will take a look at Ryan's specification, and see if it could be made to work by adding a bit to <skeleton> - perhaps a bin-idref attribute that points to a traditional <trans-unit> for translatable text?

Looking forward to a good conversation!

- Bryan
________________________________________
From: xliff@lists.oasis-open.org [xliff@lists.oasis-open.org] on behalf of Yves Savourel [ysavourel@enlaso.com]
Sent: Sunday, December 16, 2012 1:00 PM
To: xliff@lists.oasis-open.org
Subject: RE: [xliff] RE: 2.0 Binary Data Module Proposal

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








---------------------------------------------------------------------
To unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: xliff-help@lists.oasis-open.org