OASIS XML Localisation Interchange File Format (XLIFF) TC

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 = " resourcesen
egistryconfig.resources.xml "
/>
    < res:target
href = " resourcesde
egistryconfig.resources.xml "
/>
  </ res:resourceData >
  < res:resourceData
id = " 2 "
mime-type = " image/jpeg " >
    < res:source
xml:lang = " en-us "
href = " screenshotsenloadregistryconfig.jpg " />
    < res:target
xml:lang = " de-de "
href = " screenshotsdeloadregistryconfig.jpg " />
    < res:reference
xml:lang = " de-lb "
href = " screenshotslbloadregistryconfig.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
 

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 = " resourcesen
egistryconfig.resources.xml "
/>
    < res:target
href = " resourcesde
egistryconfig.resources.xml "
/>
  </ res:resourceData >
  < res:resourceData
id = " 2 "
mime-type = " image/jpeg " >
    < res:source
xml:lang = " en-us "
href = " screenshotsenloadregistryconfig.jpg " />
    < res:target
xml:lang = " de-de "
href = " screenshotsdeloadregistryconfig.jpg " />
    < res:reference
xml:lang = " de-lb "
href = " screenshotslbloadregistryconfig.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
 

Hi Ryan, all, Thanks for the reminder. I have a few notes: -- I’m not sure how is expressed the relationship between the resourceData element at the top of the file and the unit. You mentioned using the name attribute of the unit. But in your example there is no such relation. So how this is working? -- You also mention that maintaining a registry of custom mime-type for XLIFF would be difficult and say "To this end, we'd like to propose that we only keep one module at the <file>..." How moving the data out of the unit and putting in at the top of the file is resolving the mime-type value issue? Am I missing something? -- For the href attribute, the definition saya "The location of the file or URI referencing an external resource". I don't think "location of the file" is specific enough: what format that location uses. I think you really mean just "URI referencing an external resource" which (I think) would take care of a local file as well. Also should we use IRI instead of URI? (I can't recall if that question was resolved at the TC level). -- The definition of the module says: "This module is used to store references to external resource data that may need to be localized or used as contextual reference during translation". Those are two very distinct functions. How does a user agent knows which resource is for one and which resource is for the other? For example a tool may want to remove contextual references for make room, but it would want to keep the resources that do need to be localized. -- mime-type attribute: the definition for the value says "A list of standard values is available from the [RFC 1341] document, the MIME specification.". I think that RFC defines the format of the MIME type, not the list of standard values. that list is (I think) here: http://www.iana.org/assignments/media-types . I also think RFC 1341 is obsolete and 2045 is the latest ( http://tools.ietf.org/rfc/rfc2045.txt ). And 2048 defines how to register new types ( http://www.ietf.org/rfc/rfc2048.txt ). -- xml:lang attribute: I'm not sure this is actually useful. xml:lang applies to the *content* of the element where it is in scope. But there is no real content in those element, so it's basically marking up nothing. Also one of the definition says: "When the optional xml:lang attribute is present, its value must be equal to the value of the srcLang attribute of the enclosing <xliff> element." That's all for now. I have no idea when I'll have time to look at the Change Track draft. I hope this helps, -yves

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 = " resourcesen
egistryconfig.resources.xml "
/>
    < res:target
href = " resourcesde
egistryconfig.resources.xml "
/>
  </ res:resourceData >
  < res:resourceData
id = " 2 "
mime-type = " image/jpeg " >
    < res:source
xml:lang = " en-us "
href = " screenshotsenloadregistryconfig.jpg "
/>
    < res:target
xml:lang = " de-de "
href = " screenshotsdeloadregistryconfig.jpg "
/>
    < res:reference
xml:lang = " de-lb "
href = " screenshotslbloadregistryconfig.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

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 = " resourcesen
egistryconfig.resources.xml "
/>
    < res:target
href = " resourcesde
egistryconfig.resources.xml "
/>
  </ res:resourceData >

  < res:resourceData
id = " 2 "
mime-type = " image/jpeg " >

    < res:source
xml:lang = " en-us "
href = " screenshotsenloadregistryconfig.jpg " />

    < res:target
xml:lang = " de-de "
href = " screenshotsdeloadregistryconfig.jpg " />

    < res:reference
xml:lang = " de-lb "
href = " screenshotslbloadregistryconfig.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

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
 


From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org]
On Behalf Of Ryan King
Sent: Freitag, 1. Februar 2013 00:06
To: Helena S Chapman
Cc: xliff@lists.oasis-open.org
Subject: RE: [xliff] RE: Resource Data Module <was: RE: [xliff] Binary Module>


 
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 = " resourcesen
egistryconfig.resources.xml "
/>
    < res:target
href = " resourcesde
egistryconfig.resources.xml "
/>
  </ res:resourceData >

  < res:resourceData
id = " 2 "
mime-type = " image/jpeg " >

    < res:source
xml:lang = " en-us "
href = " screenshotsenloadregistryconfig.jpg " />

    < res:target
xml:lang = " de-de "
href = " screenshotsdeloadregistryconfig.jpg " />

    < res:reference
xml:lang = " de-lb "
href = " screenshotslbloadregistryconfig.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

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
 


From:
xliff@lists.oasis-open.org [ mailto:xliff@lists.oasis-open.org ]
On Behalf Of Ryan King
Sent: Freitag, 1. Februar 2013 00:06
To: Helena S Chapman
Cc: xliff@lists.oasis-open.org
Subject: RE: [xliff] RE: Resource Data Module <was: RE: [xliff] Binary Module>


 
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 = " resourcesen
egistryconfig.resources.xml "
/>
    < res:target
href = " resourcesde
egistryconfig.resources.xml "
/>
  </ res:resourceData >

  < res:resourceData
id = " 2 "
mime-type = " image/jpeg " >

    < res:source
xml:lang = " en-us "
href = " screenshotsenloadregistryconfig.jpg " />

    < res:target
xml:lang = " de-de "
href = " screenshotsdeloadregistryconfig.jpg " />

    < res:reference
xml:lang = " de-lb "
href = " screenshotslbloadregistryconfig.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

Ryan, I am uncomfortable with the concept of an XLIFF file pointing to another file, with the expectation that the referenced file would be modified during the translation process.  From your description in the Resource Data Model:

  This module is used to store references to external resource data that may need to be localized  or used as contextual reference during translation.


The whole concept of XLIFF is that all localization information should be defined within the XLIFF file itself, and that everything is defined in a format-neutral manner.  Implying that an outside file must be modified in a format-specific manner does not conform to the intent of the XLIFF standard.  The XLIFF charter states:   " The specifications are tool-neutral, ...".   When the XLIFF file is created, all localizable information should be defined directly in the XLIFF file.  If that is not possible, then the XLIFF Specification would have to be enhanced to allow defining that data in a format-neutral way.

In the referenced example below, the first <res:resourceData> element references an XML file.  What are the XLIFF processing expectations for that XML file?  If the XML file contains the <unit>'s <source> text and we are trying to show how the text is originally defined or used, then we are now in the format-specific realm and are no longer format-neutral.  The second <res:resourceData> element references a JPEG file.  I can understand the usefulness of providing a reference image of how the<source> text is used within the product, but I do not see the usefulness of providing an image of how the <target> text is used, as the translation has not yet been performed.

Maybe I am the only one which concern about this module, and how it is changing the general scope of XLIFF as an interchange format.  But I would also like to hear what othes have to say about this change in direction.


David

Corporate Globalization Tool Development
EMail:  waltersd@us.ibm.com          
Phone: (507) 253-7278,   T/L:553-7278,   Fax: (507) 253-1721


Ryan King ---01/30/2013 01:30:47 PM---Hi All, I haven’t seen any feedback on the draft for the Resource Data Module (formerly Binary Data

From: Ryan King <ryanki@microsoft.com>
To: "xliff@lists.oasis-open.org" <xliff@lists.oasis-open.org>,
Date: 01/30/2013 01:30 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 = " resourcesen
egistryconfig.resources.xml "  />
    < res:target   href = " resourcesde
egistryconfig.resources.xml "  />
  </ res:resourceData >
  < res:resourceData   id = " 2 "   mime-type = " image/jpeg " >
    < res:source   xml:lang = " en-us "   href = " screenshotsenloadregistryconfig.jpg "  />
    < res:target   xml:lang = " de-de "   href = " screenshotsdeloadregistryconfig.jpg "  />
    < res:reference   xml:lang = " de-lb "   href = " screenshotslbloadregistryconfig.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 David Walters/Rochester/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  

Thanks David for your feedback. One of the motivations for a resource data module is to
enable localization of user interface elements which can be affected by
translation of string data , for example, modification of size and position due to increased string length. Since existing resource formats can vary widely and new ones can be created at will, it would be very difficult to represent localizable resource
data such as this as standardized XLIFF elements. Hence, in order to keep XLIFF as interoperable as possible, and to still enable localization of user interface elements, the need to associate localizable string data in XLIFF to localizable resource data in
an external file.
 
As for a needing a target reference screenshot, there are cases, such as when a source string has been updated, but a translation of the previous source exists,
or a target string has been recycled from a previous translation, where a target screenshot could still provide a translator with needed context, e.g. surrounding strings and user interface elements, etc.
 
Thanks,
Ryan
 


From: David Walters [mailto:waltersd@us.ibm.com]

Sent: Thursday, February 7, 2013 5:21 AM
To: Ryan King
Cc: xliff@lists.oasis-open.org
Subject: Re: [xliff] RE: Resource Data Module <was: RE: [xliff] Binary Module>


 
Ryan, I am uncomfortable with the concept of an XLIFF file pointing to another file, with the expectation that the referenced file would be modified during the translation process.  From your
description in the Resource Data Model:
  This module is used to store references to external resource data that
may need to be localized  or used as contextual reference during translation.



The whole concept of XLIFF is that all localization information should be defined within the XLIFF file itself, and that everything is defined in a format-neutral manner.  Implying that an outside file must be modified in a format-specific manner does not conform
to the intent of the XLIFF standard.  The XLIFF charter states:   " The specifications are tool-neutral,
...".   When the XLIFF file is created, all localizable information should be defined directly in the XLIFF file.
 If that is not possible, then the XLIFF Specification would have to be enhanced to allow defining that data in a format-neutral way.

In the referenced example below, the first <res:resourceData> element references an XML file.  What are the XLIFF processing expectations for that XML file?  If the XML file contains the <unit>'s
<source> text and we are trying to show how the text is originally defined or used, then we are now in the format-specific realm and are no longer format-neutral.  The second <res:resourceData> element references a JPEG file.  I can understand the usefulness
of providing a reference image of how the<source> text is used within the product, but I do not see the usefulness of providing an image of how the <target> text is used, as the translation has not yet been performed.

Maybe I am the only one which concern about this module, and how it is changing the general scope of XLIFF as an interchange format.  But I would also like to hear what othes have to say about
this change in direction.


David

Corporate Globalization Tool Development
EMail:   waltersd@us.ibm.com          
Phone: (507) 253-7278,   T/L:553-7278,   Fax: (507) 253-1721


Ryan
King ---01/30/2013 01:30:47 PM---Hi All, I haven’t seen any feedback on the draft for the Resource Data Module (formerly Binary Data

From:
Ryan King < ryanki@microsoft.com >
To:
" xliff@lists.oasis-open.org " < xliff@lists.oasis-open.org >,

Date:
01/30/2013 01:30 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 = " resourcesen
egistryconfig.resources.xml "  />
    < res:target   href = " resourcesde
egistryconfig.resources.xml "  />
  </ res:resourceData >
  < res:resourceData   id = " 2 "   mime-type = " image/jpeg " >
    < res:source   xml:lang = " en-us "   href = " screenshotsenloadregistryconfig.jpg "  />
    < res:target   xml:lang = " de-de "   href = " screenshotsdeloadregistryconfig.jpg "  />
    < res:reference   xml:lang = " de-lb "   href = " screenshotslbloadregistryconfig.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 David Walters/Rochester/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