Thanks Joachim, I think saying “textual” or “non-textual” is too ambiguous and that is why I removed it from this version of the draft. If I have resizing information
in my resource file, and it is stored as a base64 encoded binary blob, some might argue that it is just text by the very fact it is base64 encoded. If I were to expose the resizing information as numerical values equating to XYZ coordinates instead, is that
text? Or because they are numerical values, they aren’t text? On a higher level, XML could be considered just text. So I don’t want implementers to misunderstand and think that the module only allows referencing pure binary files like a jpeg. I understand
the spirit of your comment, however, and would welcome alternate terminology.
ryan
From: Schurig, Joachim [mailto:Joachim.Schurig@lionbridge.com]
Sent: Tuesday, February 5, 2013 6:36 AM
To: Ryan King; Helena S Chapman
Cc: xliff@lists.oasis-open.org
Subject: RE: [xliff] RE: Resource Data Module <was: RE: [xliff] Binary Module>
Dear Ryan,
Thank you for the changes. I am a lot more comfortable with this approach now, too!
I think it would still make sense to explicitly highlight that referenced non-context resource data (= for translation) shall not be textual data. Or would
English natives imply this from the name of it?
Cheers,
Joachim
Good question Helena, we didn’t think about the change track module being used on other modules, just for core elements <source>, <target>, and <note>. I haven’t
seen any feedback on the change track module yet…but maybe we can think about how it can be used for more than just core elements…
From:
xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org]
On Behalf Of Helena S Chapman
Sent: Thursday, January 31, 2013 11:47 AM
To: Ryan King
Cc: xliff@lists.oasis-open.org
Subject: Re: [xliff] RE: Resource Data Module <was: RE: [xliff] Binary Module>
I am much more comfortable with this. Thank you for making those changes.
One question, if a target is to be replaced completely, would there a need to keep track of that "replacement history"? Would that be handled thru the "track changes" proposal?
From: Ryan King <ryanki@microsoft.com>
To: "xliff@lists.oasis-open.org"
<xliff@lists.oasis-open.org>
Date: 01/30/2013 02:31 PM
Subject: [xliff] RE: Resource Data Module <was: RE: [xliff] Binary Module>
Sent by: <xliff@lists.oasis-open.org>
Hi All, I haven’t seen any feedback on the draft for the Resource Data Module (formerly Binary Data Module). Please send them to the list so that I can incorporate any changes before
working on the DocBook files and publishing it to the spec.
Thanks,
Ryan
From:
xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org]
On Behalf Of Ryan King
Sent: Wednesday, January 23, 2013 3:46 PM
To: xliff@lists.oasis-open.org
Subject: [xliff] Resource Data Module <was: RE: [xliff] Binary Module>
Hello All,
In the TC call on 12/8, there was the suggestion of keeping a registry on the OASIS wiki for the custom mime-types of the binary module proposal. After the call, we had some discussions internally
about the feasibility of this and believe that it will be very difficult to keep and maintain such a registry on the OASIS wiki. I believe that others have expressed similar concerns. To this end, we'd like to propose that we only keep one module at the <file>
level that references external files/containers, and no longer propose embedding binary data at the <unit> level as a module. Here is an example:
<file
id="1">
<res:resourceData
id="1"
mime-type="text/xml">
<res:source
href="resources\en\registryconfig.resources.xml"
/>
<res:target
href="resources\de\registryconfig.resources.xml"
/>
</res:resourceData>
<res:resourceData
id="2"
mime-type="image/jpeg">
<res:source
xml:lang="en-us"
href="screenshots\en\loadregistryconfig.jpg" />
<res:target
xml:lang="de-de"
href="screenshots\de\loadregistryconfig.jpg" />
<res:reference
xml:lang="de-lb"
href="\screenshots\lb\loadregistryconfig.jpg" />
</res:resourceData>
<unit
id="1"
name="130;WIN_DLG_CTRL_">
<segment
id="1"
state="translated">
<source>Load
Registry Config</source>
<target>Registrierungskonfiguration
laden</target>
</segment>
</unit>
<unit
id="2"
name="133;WIN_DLG_CTRL_">“
<segment
id="1"
state="translated">
<source>Remove
Registry Config</source>
<target>Registrierungskonfiguration
entfernen</target>
</segment>
</unit>
</file>
In this example, external XML is referenced that may contain resource data for a user interface control. The control is the container for the text “Load Registry Config” and may need to be resized
to accommodate the increased length of the string due to translation. The name attribute of the <unit> containing the <segment> to be translated could serve as the key for a user agent to associate text and resource. A second set of external files are referenced,
which are images that could be used for context when translating.
Please find attached the detailed specification for the module. We would appreciate your comments and thoughts.
Thanks,
Ryan, Alan, Kevin, and Uwe
-----Original Message-----
From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org]
On Behalf Of Ryan King
Sent: Wednesday, January 16, 2013 5:11 PM
To: Yves Savourel; xliff@lists.oasis-open.org
Subject: RE: [xliff] Binary Module
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
[attachment "Resource Data Module.pdf" deleted by Helena S Chapman/San Jose/IBM]
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php