RE: [xliff] RE: Resource Data Module <was: RE: [xliff] Binary Module>

Hi Yves, all,

Thanks, Yves, for the great feedback. Let me give you some more background on our thinking around this module so you have some more context. Also, see my comments to your feedback inline.

The reality of the situation is that there is no standard on how read and write localizable binary data, such as control size and position, etc., to and from an interchange format such as XLIFF. With Microsoft's desire to move more of our translation work to XLIFF, our original idea was to use a base64 encoded binary blob to encapsulate this information, which is what we currently do in our internal localization format. However, as many pointed out, this isn't very interoperable because there is no standard that defines how each content provider should structure the binary blob - which could vary from resource type to resource type and parser to parser - and it is unclear to me whether such a standard could even be created when new resource types are being created all the time with different localization requirements. This leaves us in a situation where for every resource type, there is potentially the need to create a reader/writer and binary blob format specific to that resource type and maybe even specific to the content provider. It is, therefore, understandable that this lack of interoperability calls for the need of a custom mime-type registry to describe how to read and write the binary blob format that the custom mime-type describes.

As stated previously, we believe that it will be very difficult for Microsoft and other content providers to keep and maintain such a registry on the OASIS wiki. We also think that the module should provide some level of basic interoperability, and any further processing of the data can be done via extensibility, e.g. metadata or attributes from a different namespace, by those user agents that know how to process it, which is possible with any other core XLIFF element or module that allows extensibility. Therefore, we scaled the proposal down to referencing an external resource with a mime-type that most user agents should be able to do something with, e.g. display a jpeg or icon in an image viewer/editor, an XML in an xml viewer/editor, etc., and again, any further processing would depend on extensible metadata/attributes.

Hope that helps frame this proposal a bit better. See my comments inline below.

Ryan

-----Original Message-----

From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Yves Savourel

Sent: Wednesday, January 30, 2013 12:51 PM

To: xliff@lists.oasis-open.org

Subject: RE: [xliff] RE: Resource Data Module <was: RE: [xliff] Binary Module>

Let me rephrase the last note (got interrupted):

Please discard "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."

so the note is:

[ryanki] The user agent could use the xml:lang attribute as an aid to processing the external file. For example, and image viewer might want to display source, target, and reference screen captures differently, or differentiate between multiple reference screen captures in some way based on the language of the capture.

Thanks,

-yves

-----Original Message-----

From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Yves Savourel

Sent: Wednesday, January 30, 2013 1:47 PM

To: xliff@lists.oasis-open.org

Subject: RE: [xliff] RE: Resource Data Module <was: RE: [xliff] Binary Module>

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?

[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.

-- 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.

-- 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).

[ryanki] Thanks that makes sense. I'll make that change.

-- 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?

-- 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).

[ryanki] Thanks, I must admit, I simply copied this from the 1.2 spec. I'll make that update.

-- 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

---------------------------------------------------------------------

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

---------------------------------------------------------------------

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

xliff message