Thanks David for the feedback. I have updated the attached pdf (highlighted in green) based on the below items. #1 – Since removing <source> depends on whether the context attribute is set to yes, probably the creation of <source> should depend on this as well. So it should be zero or one <source> and the PR on the creation of <source> should be conditional. The same would be true for <target>. #2 – zero, one or more. #3 – I think of <reference> as a second “source” for the translator in a different language, which is for reference only, and therefore, not required for translation, so it could be created or removed depending on use case, and like a contextual <source> element, it shouldn’t be modified. #4 – We’ve discussed this on other threads. Since the XLIFF standard cannot possibly understand external XML (or other resource) formats, the most we can expect is for a user agent to do something with it based on the mime-type, e.g. for text/xml, display it in an XML viewer or editor. Beyond that, implementers would need to define a custom attribute to determine how to handle it. See my example (xtr:editor) in the attached mail. It was decided in a subsequent TC conference call to make resourceDataID part of the module, now called resourceDataRef, but the attribute for handling the resource needs to remain custom. Thanks, Ryan From: David Walters [mailto:
waltersd@us.ibm.com] Sent: Tuesday, February 26, 2013 5:21 AM To: Ryan King Cc:
xliff@lists.oasis-open.org Subject: Re: [xliff] Latest Changes: Resource Data Module I noticed a few inconsistencies. In the syntax diagram, it indicates that there must be 1 <source> element. In the "Processing Requirements" section of <source>, it states that "User agents may create <source> if not already present." Which is correct? In the syntax diagram, it indicates that there may be zero, one or more <reference> elements. In the "Contains" section of <resourceData>, it states that it can contain "Zero or one <reference> element". Which is correct? For <reference>, the "Processing Requirements" section states the following. So if an agent can remove and add a <reference>, why can't the agent modify a <reference> (which could be viewed as removing and adding)? User agents may create <reference> if not already present User agents should not modify <reference> User agents may remove <reference> For the "mime-type" attribute, how does an agent know how to locate the information which may need to be changed? In your examples, there is a mime-type of "text/xml", and it mentions about having to resize a control based on the translated text. But there may be lots of XML formats which all have resizing information defined differently. How is an agent supposed to know which formats they need to support? David Corporate Globalization Tool Development EMail:
waltersd@us.ibm.com Phone: (507) 253-7278, T/L:553-7278, Fax: (507) 253-1721 Ryan King ---02/25/2013 07:30:59 PM---Hello All, Please find attached the latest changes for the ResourceData module based on the feedback From: Ryan King <
ryanki@microsoft.com > To: "
xliff@lists.oasis-open.org " <
xliff@lists.oasis-open.org >, Date: 02/25/2013 07:30 PM Subject: [xliff] Latest Changes: Resource Data Module Sent by: <
xliff@lists.oasis-open.org > Hello All, Please find attached the latest changes for the ResourceData module based on the feedback from TC members in email and from the TC conference calls. Changes are highlighted in yellow. Please sned any additional feedback you may have. I am planning to author the docBook files add them to the specification this week. Thanks, Ryan[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 --- Begin Message --- From : Ryan King <
ryanki@microsoft.com> To : Yves Savourel <
ysavourel@enlaso.com>, "xliff@lists.oasis-open.org" <
xliff@lists.oasis-open.org> Date : Thu, 31 Jan 2013 20:03:24 +0000
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:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php --- End Message --- Attachment: Resource Data Module.pdf Description: Resource Data Module.pdf