OASIS XML Localisation Interchange File Format (XLIFF) TC

Sorry, I attached the wrong pdf. Sending with the correct one attached. -------------------------- As discussed in Tuesday’s TC call, we will break out the binary data module proposal into two separate modules. One module will live at the <unit> level and will contain only binary resource data. This module enables the use case for resizing and repositioning target dialogs and UI controls, etc. Textual data is not contained in this module, but will have been extracted to an appropriate <segment>, which is a sibling to the binary resource module contained in a <unit>.  It was proposed that the second module live at <file> level and contain pointers to binary file data in an accompanying container format. This module would enable the SharePoint scenario of carrying around binary files as payload that may or may not have textual elements in them that may be used for reference (e.g. an image), or localized outside of XLIFF (e.g. a document), but are related to the localizable content contained within the XLIFF.   This thread is to discuss the binary resource use case. The attached proposal is based on the original already circulated but edited to conform to the binary resource use case only. Please use this thread to discuss and give feedback. Thanks everyone for your help and support on this module.   Thanks, Ryan Attachment: Binary Resource Module.pdf Description: Binary Resource Module.pdf

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

I had a similar concern about state attribute as Yves. However, I also have a concern about custom mine-type and maintaining it on the XLIFF WIKI over time. From:         Yves Savourel <ysavourel@enlaso.com> To:         <xliff@lists.oasis-open.org> Date:         12/24/2012 11:22 PM Subject:         RE: [xliff] Binary Module Sent by:         <xliff@lists.oasis-open.org> 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 --------------------------------------------------------------------- To unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org For additional commands, e-mail: xliff-help@lists.oasis-open.org

Sorry I'm late to the binary discussion, but I have been on vacation for several weeks. The idea of including lots of binary data in an XLIFF file seems to contradict the intent of the XLIFF standard.  XLIFF is supposed to be a simple, easy-to-process XML format.  I thought one of the user comments was that the current XLIFF 1.2 specification is too complex and that we were trying to simplify it in XLIFF 2.0.  The design of this binary module seems rather complex, relying on processing rules defined outside of the XLIFF specification.  The whole idea of XLIFF is to extract the text from whatever format it is defined in, and make it format independent in the XLIFF file.  The tools handling the file should not really care where the text came from.  Any unique information which must be passed along with the text would be contained in XLIFF attributes.  As soon as we allow extensive binary data in the file, it impacts the interoperability of XLIFF. It also seems to be too late in the release cycle to be introducing significant new modules.  These discussions should be delayed until after XLIFF 2.0 is released, as they are taking time away from finalizing the XLIFF 2.0 specification.  Otherwise, 2.0 will be pushed out further (causing dissatified customers), or we'll end up with a specification which has not had enough time to thoroughly think through the ramifications of the proposals. David Corporate Globalization Tool Development EMail:  waltersd@us.ibm.com           Phone: (507) 253-7278,   T/L:553-7278,   Fax: (507) 253-1721

Thank you Yves for your evaluation and feedback. You are correct on each point below for the functionality provided by the binary module. Your notes on the proposal itself were also very helpful. Each one was valid and made sense. I will make changes to the draft accordingly. thanks, ryan
Original Message----- From: xliff@lists.oasis-open.org [ mailto:xliff@lists.oasis-open.org ] On Behalf Of Yves Savourel Sent: Monday, December 24, 2012 8:22 PM To: xliff@lists.oasis-open.org Subject: RE: [xliff] Binary Module 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 --------------------------------------------------------------------- To unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org For additional commands, e-mail: xliff-help@lists.oasis-open.org