xliff message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: [xliff] Proposal for consolidated attribute value list for xliff 1.1
- From: Gerard Cattin des Bois <gcatt@windows.microsoft.com>
- To: "Reynolds, Peter" <Peter.Reynolds@bowneglobal.ie>,xliff@lists.oasis-open.org
- Date: Fri, 07 Feb 2003 09:37:37 -0800
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...
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC