RE: [xliff] Binary Module

[Yves Savourel <ysavourel@enlaso.com>]

Hi Ryan, all,

Thanks for the updated proposal regarding the 'resource' case of the binary module.

I'd like to step back for one moment and list the requirements that, I think, you have for the functionality provided by the proposed binary module. From the email discussions and examples I have seen so far, I believe they are as follow:

- one should be able to store an arbitrary block of non-textual data that may be binary (e.g. a widget)

- one should be able to identify the original format of that block of data (e.g. a Windows control)

- one should be able to identify the encoded representation of that block of data (e.g. base64)

- one should be able to associate that block of data to a given unit

- one should be able to store both the source and the target representation for that block of data

- one should be able to store both the source and target representation outside the XLIFF document

- one should be able to keep track of the status of the target representation (which may differ from the status of the corresponding text)

- one should be able to indicate whether or not the block of data needs to be modified (in addition to the extracted text)


=== Notes on the requirements:

In many aspects it looks like your requirement are basically calling for some form of element that is comparable to the skeleton with two main enhancements: a) it is directly associated with a unit, and b) it is capable of carrying a target representation.


=== Notes on the proposal itself:

-- I would name that <bin-unit> element something else to avoid the perception that a) it is at the same level as a <unit> (a sibling), and b) that it is always binary (one can store non-binary data there too). If originalData was not already taken I would suggest that. Maybe unitData or something similar will do?

-- Keeping <source> and <target> should be fine because they are in a different namespace than the core <source> and <target>.

-- The tree show "<bin-unit> *" not "<bin-unit> ?" is that mean you really want to allow more than one block of data per unit? If so is there an existing use case that justifies it? (I can't think of any case where a text would be existing in two different location and need to be treated as one).

-- If we can keep this element to zero or one then there is probably no need for the id attribute.

-- Why use CDATA with Base64? Just curious, since none of the 64 possible character of base64 needs to be escaped. Note that nothing guarantee that you will get CDATA back. On very large file that's just extra nodes for nothing.

-- The state attribute for the translated text is at the segment level per the F2F resolution (see https://lists.oasis-open.org/archives/xliff/201210/msg00070.html). By the way: I realized today that I'm the one with the action item to update the specification with the 'state' and 'subState' attributes. I'll try to do that as soon as I can find the time. Sorry for the delay.


cheers,
-yves