More inline preface with [ryanki2] :)
-----Original Message-----
From: xliff@lists.oasis-open.org [
mailto:xliff@lists.oasis-open.org] On Behalf Of Yves Savourel
Sent: Thursday, January 31, 2013 6:10 AM
To: xliff@lists.oasis-open.org
Subject: RE: [xliff] RE: Resource Data Module <was: RE: [xliff] Binary Module>
Hi Ryan,
Thanks for the answers. Please see my notes inline (YS>)
-- 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?
[ryanki] The comment from the draft was: "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." This is just an example that may need to be reworded for clarity.
It is conceivable that a user agent COULD use the resource ID in the name attribute to map to a resource ID in the reference XML and by default, or possibly depending on an extensible attribute, open an editor that allows the translator to make modifications
to the resource data mapped to that resource ID.
YS> I see how things *could* work. But my point is that there is no defined way in the current draft to link a <resourceData> to a given <unit>. This is bound to cause problem when tools manipulate the XLIFF content.
[ryanki2] I don't think that the standard should, or even could, dictate how strings within an XLIFF are mapped to data in an external resource outside of the standard. That has to be done by a user agent that understands both XLIFF, possibly extensible
attributes, and the external resource. With that in mind, perhaps I should remove that from the example (or enhance the example with extensible attributes and an explanation to that effect…see my other comment below).
-- 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?
[ryanki] The crux of it is that we are no longer proposing the use of a custom mime-type in the actual XLIFF, instead resource data should be referenced externally as a file. The processing of that external file happens outside of the XLIFF, though extensible
attributes or metadata might be defined to help the user agent deal with it.
YS> I see a 'mime-type' attribute in the module. So we do use mime-type values in XLIFF.
Personally I think using the IANA MIME type registry is enough: one can register new types there. So I don't see a need to have some XLIFF-specific registry. My point was that moving the resource out of <unit> doesn't affect the mime type usage, and since
moving out the resource brings new issue like how to link unit and resource I'm just wondering what are the benefits to have the resource outside of its related unit.
[ryanki2] Two reasons for <file> level referencing: 1) It removes the embedded binary blob from the XLIFF, meaning a user agent that only understands the XLIFF standard doesn't have to deal with how to decode and display the binary blob. 2) The majority
of the TC folks in the 12/18 call didn't want to support referencing files at the <unit> level. So that leaves us with <file> level referencing. Here’s an example of what I mean:
<file id="1">
<res:resourceData id="1" mime-type="text/xml" xtr:editor="resourceEditor">
<res:source href="" />
<res:target href="" />
</res:resourceData>
<unit id="1" name="130;WIN_DLG_CTRL_" xtr:resourceDataID="1">
<segment id="1" state="translated">
<source>Load Registry Config</source>
<target>Registrierungskonfiguration laden</target>
</segment>
</unit>
</file>
A user agent that supports the xtr namespace could map the unit to the resource file (xtr:resourceDataID=”1”) and know to open the XML in its resource editor (xtr:editor=”resourceEditor”) where it could locate the resource data using the <unit>’s name
attribute. A user agent that doesn’t support the xtr namespace could still open the file in an XML editor/viewer for basic interoperability.
-- 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.
[ryanki] Good point. We could add a "translate" attribute: yes=translatable, no=context; or a "context" attribute: yes=context, no=translatable. Would that work?
YS> Sure. The context attribute would probably make more sense since what need to be done for the other type (translate/localize/resize/etc.) is less clear.
cheers,
-yves
---------------------------------------------------------------------
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: