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

[Yves Savourel <ysavourel@enlaso.com>]

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