[xliff] Proposal for consolidated attribute value list for xliff 1.1

[Gerard Cattin des Bois <gcatt@windows.microsoft.com>]

Title: Message

Attribute list value proposal regarding the XLIFF 1.1 Consolidated Attribute Values Lists

 

Problem: The current proposals we have been discussing for new values for this list of attributes raise the issues of cross-polination of attribute values from one attribute into the others. As it currently stands, a number of attributes values are found in other categories for a number of reasons. 

 

During the teleconference, we discussed the idea of adding three attributes to the current list of values. But, now that I think about it more carefully, that won't quite work. So, I am submitting a slightly modified proposal from what we discussed. Please, comment and provide suggestions for alternate solutions if you see a better one.

 

Solution: I would like to propose a simple, yet cohesive way to represent cross-polinated attribute values in the consolidated attribute values list as follows: 

1. Add 3 attributes values to the count-type attribute: datatype, restype, and state. Each attribute value must augment its value by adding a dot and an enumerated value from their corresponding attribute. Here is an example: count-type=datatype.cstring, or count-type=restype.dialog, or count-type=state.needs-translation. This in effect removes the unnecessary duplication of attribute value specification and the confusion as to their meaning. This also provides clarity by reference, meaning the enumerated part of the value is merely referenced to the appropriate attribute with its specified enumerated value rather than explicitly re-specified in each category. Consequently, whenever the list of state values changes, the list of possible enumeration regarding count-type=state will always match it exactly, without necessitating a change in the count-type attribute. The same applies to count-type.restype and count-type.datatype. Specifying count-type=[state | restype | datatype] without an enumerated value yields no count meaning (unnless somebody can think of one).

2. Remove duplicated attribute values in count-type: 

a.cstring, msglib (in datatype)

b.needs-translation, needs-review, signed-off (in state).

Not sure about Christian's new proposed list. They appear to be count-type in their own right. Comment?

3. Datatype, restype, and state attributes have additional values proposed, which I won't discussed here.

 

Note: the Mimetype value is yet to be defined from me and Christian. The mime type may require a similar solution as it has many attributes with different types of values.

 

Comments and suggestions welcome.

Thanks,
-Gérard
Gérard Cattin des Bois
Lead Program Manager, LocStudio Services
Windows Productivity Tools Team
gcatt@microsoft.com  (425) 706-1592
Symptom and sign of Inner Peace: An unmistakable ability to enjoy each moment...