ID
|
Status
|
Spec
|
Topic
|
Class
|
Title
|
Summary
|
Proposed by
|
Original Proposal
|
Discussion History
|
1
|
Closed
|
1.1 Spec
|
Extensibility
|
Design
|
Extending Attribute Values
|
27 Jan 03 – Updated in
1.1 Draft 2d
10 December 2002 =
Unanimous vote to use the 'x-' mechanism for attribute value extension. .
Proposal for validation mechanism for XLIFF files that have been
customized. Three proposed alternatives are proposed for the schema:
1. From Yves uses the 'union'mechanism
2. a new proposal from Christian which uses the 'redefine' mechanism. The
argument in favor of the 'redefine' mechanism is that it provides a way of
validating customized values and is more flexible, The argument for the
'union' mechanism is that it is simple and more easily implemented.
3. Shigemichi's "x-" proposal: to use a TMX style
prefix for any custom attribute. Danger here is that custom
extensions for commonly named attributes ie, "x-button",
could result in ambiguity or worse - invalid identification. Sugestion to
extend with additional namespace identifier was not met with some
resistance.
|
Christian
Lieske
|
Christian's
Proposal
|
sec
2.4 in WIP 1.1 spec
|
2
|
Closed
|
1.1 Spec
|
Interoperability
|
Design
|
Context Group
|
27 Jan 03 – Updated in
1.1 Draft 2d
3 Dec - unanimous vote to
remove from the spec.
Original:
Further action requried: remove from the spec.
XLIFF 1.1 Working Draft, Section 2.3, paragraph 2 talks about the
context-group element. In that section it talks about the different
purposes for the context information, i.e. TMs, translators, etc. The final
sentence refers to using PIs to indicate the different purposes. However,
we are no longer specifying the use of PIs and we have never enumerated the
purposes of context information. .
|
John Reid
|
John
Reid's Proposal
|
Mark
Levins' Suggestion
|
3
|
Closed
|
1.1 Spec
|
Interoperability
|
Design
|
New elements
"default" and "defaults"
|
27 Jan 03 – Updated in
1.1 Draft 2d
21 Jan 2003 No further
attributes submitted at meeting – resolution stands as defined by John and
now update to specification required.
14 Jan 2003: This was accepted in a vote, but
additional default attributes might be added to the <group> element
at next week's meeting.
7 Jan 20003 Members of
the TC have been asked express opinions on this before next week when there
will be a vote.
19 Dec 2002: the proposal
is to add these attributes to group for the express purpose of setting
defaults for all child <trans-unit>s: charclass, maxbytes, maxheight,
maxwidth, minbytes, minheight, minwidth, size-unit, translate, reformat
The attributes of the <trans-unit> that have not been considered for
the <group> element are listed below: approved, phase-name, tu-state
(proposed)
17 Dec 2002: John Reid to draft proposal for extending <group> for
storing default attributes.
10 Dec 2002 : Mark raised John Reid's suggestion of using <group> to
store defaulted values and adding the defaultable attributes to the group
element. Tony suggested closing out on the original proposal and not using
XPath by replacing the default strategy with <group>. John Reid
volunteered to redefine the proposal around new attributes of <group>
for the next meeting.
Original:
Amended Requirements:
R.1 a mechanism to allow defaulting for XLIFF data categories
R.2 formal representation of data category is secondary (i.e. the mechanism
should be applicable to attributes and elements)
R.3 mechanism should work for all XLIFF data categories
R.4 location for defaulting information is secondary (i.e. default in
central location, default at specific attributes or elements, and default
at all attributes and elements is acceptable)
R.5 XPath should not be used to relate default settings to the elements or
attributes to which they pertain (let's call this 'target')These
requirements boil down to 3 questions:
Q.1 What is defaulted?
Q.2 How is it defaulted?
Q.3 Where is it defaulted?
Originally submitted proposal (which did not meet R.5), answered the
questions as follows:
P1.A1 allow defaulting for any XLIFF data category
P1.A2 use XPath to designate the targets for default settings
P1.A3 use a new central element 'defaults'
Amended proposals which take into account R.5 :
P1': like P1 but without XPath
The idea here is that each target explicitly names the defaults which
should be used for it. From my understanding, this is not really kosher,
since for example the way to identify relationships (or 'targets')is a
proprietary and not very efficient one. XPath is the standard for this.
Accordingly, I would ask the TC members to reconsider my original proposal.
P2: defaults are encoded at the level of the 'group' element (John's
proposal)
P3: defaults are encoded 'in the vicinity'of the XLIFF element to which
they pertain (Mark's proposal)
todo:
a)define defaultable data categories Q.1
b)design a representation for default settings (Q.2); this has include a
way to identify to which XLIFF data category a setting pertains
|
Christian Lieske
Amended by
John Reid
|
Christian's
Proposal
|
Christian's
Amended
Proposal without XPATH
(29
Dec) John Reid’s use of <group> attributes proposal
|
4
|
Closed
|
1.1 Spec
|
Interoperability
|
Design
|
Phase names
in Alt Trans
|
25 Feb 03: This is related to issue 20.
10 Dec 2002: John
outlined his most recent proposal which required very little changes to the
XLIFF specification on the basis that it already provided enough support
for tracking phases and histories. Tony motioned for voting on John's
proposal at the next meeting, giving everyone enough time to digest the
proposal and be happy with the suggested additional attribute values.
Proposal:
Since the current phase information can be retrieved from the
<target> attribute I think we don't need phase-name attribute in the
<trans-unit> element and my proposal is to remove it from there.
Mark's additional suggestion for "reason" attribute:
Provide another required attribute in <alt-trans>
"reason" to indicate the reason why a given <alt-trans> is
an alternate translation. A few suggested values for such an
attribute are 'TM Suggestion', 'MT Suggestion', 'Rejected-Inaccurate',
'Rejected-Spelling', 'Rejected-Grammar' and 'Rejected-Length'.
List would remain open, but with a list of suggeted values.
|
Mirek Driml
|
Mirek's
proposal
|
05
Dec- Mirek's Clarification
05 Dec - Mark's suggestion
adding "reason"
John
Reid's Proposal (10 Dec)
|
5 |
Closed
|
1.1 Spec
|
Editorial
|
Editorial
|
"Zero, One or More" Language
|
5 Dec 02 After a
vote it was unanimously agreed that this issue is at the discretion of the
specification editor and to leave spec unchanged.
Propose replacing
the phrase "zero, one or more" with the more precise "zero
or more." This should be done globally
|
Bryan Schnabel
|
|
|
6 |
Closed
|
1.1 Spec
|
Interoperability
|
Design
|
reformat Element revisited
|
25 Feb 03: Implemented in Draft 9,20 Feb 02
27 January Option 5 was selected in a vote.
The result details were: option 4, 1 vote; option
5, 11 votes; 1 abstain.
27 January 2003 – Vote will take place at 27
January 2003 meeting. Voting will
be limited to these 6 options:
Option 1: Siblings
Option 2: Restructure
Option 3: Embedded
Option 4: Combined
Option 5: Extended
Option 6: Do nothing - defer to future release
Chair recommends Option 5
24 Jan 2003
- Option 5, submitted by Doug
Extend the possible values for the 'reformat'
attribute to provide sufficient control. XLIFF 1.0 presently uses
";"-delimited lists within attribute values to store multiple values.
The 'coord' attribute is an example. It's value is actually four:
"x;y;cx;cy", where "#" can be used for 'don't care'.
So let's extend 'reformat' the same way. Of
course, we keep "yes" and "no" for compatibility.
"yes" = all format attributes may be
changed
"no" = no format attributes may be
changed
...or a
semicolon-delimited list of the following in any order. If an attribute is
listed, it means it may be reformatted.
coord = all 4 coords
coord-x
coord-y
coord-cx
coord-cy
font = all 3 font values
font-name
font-size
font-weight
css-style
style
exstyle
Example,
<trans-unit coord="#;#;183;272"
font="Arial;2;normal" reformat="coord-cx;font-name"
...>
<source>...</source>
<target coord="#;#;181;272"
font="System;2;normal">...</target>
<alt-trans
coord="#;#;183;272" font="Arial;2;normal">
<target coord="#;#;180;272" font="Arial
Bold;2;normal">...</target>
<target coord="#;#;185;272" font="Arial,
Helvetica;2;normal">...</target>
</alt-tran>
</trans-unit>
Parsing the reformat list is fairly easy, even
with XSLT, which has a limited set of string functions.
This option is 100% compatible, both forward and
backward. It does not affect the structure at all. The only problem I can
foresee an XLIFF 1.0 tool having is if an invalid value for reformat is
assumed to be "yes" instead of "no" and allows some
values to be changed that should. That is, an XLIFF 1.0 tool could
interpret a value of "coord-cx;font-name" as "no" and
not allow any of the format value to change. Of course, if it assumed
"no" instead of "yes" it would not allow any changes.
Since the default value for 'reformat' is "yes", I don't see
either of the possibilities as being too harmful.
21 Jan 2003 More discussion regarding the 4
options, but with informal “straw poll” indicating overwhelming support for
“Option 2 – Restructure”.
However, it was noted that
this option does not preserve backwards compatibility with 1.0.
14 Jan 2003 There was much discussion over the
benefits of each of Matt's proposals (in essence, sibling elements to
<source> and <target>, or child elements to <source> and
<target>) with various advantages of each option pointed out, from
backwards compatibility to neatness, to shortcomings with <alt-trans>
and workarounds for these. We will
discuss this for one more week and vote at the next meeting on whether to
accept this proposal in concept.
7 Jan 2003 Mat outlined his proposal (see
discussion history) This will be discussed on 14 Jan 2003
17 Dec 02: Mat to rewrite proposal in full as it would appear in the
specification, and group to respond with any questions or
issues. This will be done before the next meeting.
10 Dec 02: Matt tabled new suggestions for reformatting based on
previously sent email. Mark raised objections to instruction-based reformat
element that would require similar functionality to XPath and suggested
adding new specific elements for content that can be changed as part of the
translation process (e.g. font, coord, style etc) where these elements
could contain a boolean attribute to indicate whether they could be
altered. Matt agreed to further investigate this approach and create some
examples for the next meeting. Enda then raised the question of how this
would affect the 'default' discussion and Matt brought up the ability to
default a translation or translatable content. Matt agreed to try to factor
these two points into his investigation for the next meeting.
Simple, non-verbose, mechanisms to:
1. Indicate the translatability of any attribute/element, or XLIFF
standard values or extensions.
2. Store source and translated values for any structure marked as
translatable
Proposals
1) A closed list of XLIFF standard attributes and
elements that may be modified during translation. E.G state, target
text
2) Each member of the list will either have before/after
placeholders or will be simply updated without keeping previous values
3) No other attribute/element may be translated unless
specifically marked as translatable
4) Provide place holders for any modified element
|
|
Mat's
Initial Proposal
Mat's
Revised Proposal
Mat's
final proposal (7 Jan)
Mat’s
summary of Options 1 – 4; to be used in ballot (submitted 23 Jan 2003)
Doug’s
analysis and proposal (Option 5)
|
Mark's
Comment
|
7
|
Closed
|
1.1 Spec
|
Interoperability
|
Design
|
Context-group "purpose"
recommended values
|
27 Jan 03 – Updated in 1.1 Draft 2d
10 Dec 02 : The proposal was unanimously
approved.
Original Proposal:
Propose adding the following "purpose"
attribute values:
- location, The context-group is used to specify where the term was found
in the translatable source. Thus, it is not displayed.
- match, Specifies that the context information should be used during
translation memory lookups. Thus, it is not displayed.
- information, Specifies that the context is informational in nature,
indicating for example, how a term should be translated. Thus, should be
displayed to anyone editing the XLIFF.
Combinations of these values can be made via the standard mechanism of
XLIFF. Thus, purpose="location;match" would provide both location
and TM matching contextual information. The schemas for this are detailed
in the original suggestion URL
|
John Reid
|
John's
Proposal
|
|
8
|
Closed
|
1.1 Spec
|
Interoperability
|
Design
|
phase-name as optional
<alt-trans>
attribute
|
10 Dec 02: After the discussion on issue 4, this
item was deemed to be obsolete. Original Proposal: This was originally part
of issue 4, but was split out as its
own issue on 3 Dec. meeting.
It was observed by Yves that we had no
naming convention for phase-name. Phase name
would have at least 3 distict uses within alt
trans:
1. to identify a different suggestion from a TM,
2. to capture the evolution of translation during
the
translation process, and
3. identify rejected translations.
There is no way of distinguishing these
elements.
It was agreed that we look at phase-name attribute
in
relation to this observation.
Proposal:
Add the phase-name attribute to the alt-trans as
an
optional attribute. Following along with Yves's
original
thoughts on this, the phase-name could be placed
at the
<alt-trans> level for any <alt-trans>
that has a <source>.
It would be placed in the target of any
<alt-trans> that
does not have a <source>.
Example:
<trans-unit id="1" phase-name="5final">
<source>Cancel Report</source>
<target phase-name="4review">Annuler le
Rapport</target>
<alt-trans reason="Rejected-Inaccurate">
<target phase-name="3trans">Annuler le
rapport</target>
</alt-trans>
<alt-trans match-quality="50%"
reason="TM-Suggestion" phase-name="2pretrans">
<source>Cancel All</target>
<target>Annuler tout</target>
</alt-trans>
</trans-unit>
|
Yves / John Reid
|
Yves
observation
John
Reid's Proposal
|
|
9
|
Closed
|
1.1 Spec
|
Interoperability
|
Design
|
Attribute Enumerated Values
|
27 Jan 03 – Updated in 1.1 Draft 2d
7 Jan 2003 A motion from Doug was passed unanimously and
this stated all enumerated valued would be listed within the specification.
18 Dec 02: discussion is deadlocked
during XLIFF Teleconference. 17 Dec
02: Discussion on listing all enumerated values for attributes in the
specification (or not). At issue is whether these values are part of the
specification or part of an external schema.
|
Mark Levins
|
Mark's
proposal
|
|
10
|
Closed
|
1.1 Spec
|
Interoperability
|
Design
|
Whitespace / List item delimiters
|
27 Jan 03 – Updated in 1.1 Draft 2d
7 Jan 03
Mark’s proposal was agreed.
6 Jan 03:
Mark Levins submits revised text for the specification to be discussed at
the next teleconference:
D.2. Attribute Values
Attribute values are case sensitive. It is strongly recommended that
lower-case values are used. The specification recommends a number of values
for some attributes, these are all lower-case.
Where multiple attribute values are to be used in an XLIFF document, two
approaches are used:
For enumerated attributes (such as the 'purpose' attribute of
<context-group>) the separator must be a space.
For other textual attributes that are not validated, the specification
recommends the use of the semi-colon as a concatenation separator for
values, for example, multiple contacts may be listed for a <file>
with the attribute-value written thusly: contact-name="Frank
Sinatra;Sammy Davis Jnr;Dean Martin".
17 Dec 02:
Multiple attribute values (lists) and valid separators not certain if legal
to use ; or other delimiters, appears that whitespace is recommended by
W3C, but this does not
Preclude using or ,.
|
Mark Levins
|
Mark's
Initial Observation
Doug's
Suggestion
|
Mark’s
revised text for spec
|
11
|
Deferred
|
1.1 Spec
|
Interoperability
|
Design
|
TextContent Extensibility
|
14 Jan 03:
Gerard moved for a vote on deferring TextContent
Extensibility until the next revision of XLIFF, Matt seconded and the
motion was passed unanimously.
7 Jan 03
It was suggested at this meeting to defer discussion on this until after
Spec 1.1 is complete. This will be decided on the meeting at 14 Jan.
6 Jan 02: This issue was tabled after considerable discussion during
previous XLIFF teleconference. The discussion will continue at next
meeting (7 Jan). The main points from the discussion were:
1/XHTML can presently be handled within BPT and EPT inline tags
2/adding XHTML tags will create complexity and the requirement that all
XLIFF tools to be fully capable of interpreting XHTML tags.
17 Dec 02: Extensibility of the TextContent to allow non-XLIFF tags, for
example XHTML tags
|
Doug
|
Doug's
Proposal
|
Doug’s
Additional comments (17 Dec 02)
Doug’s
additional comments (24 Dec 02)
Yves’
Comments (24 Dec 02)
|
12
|
Closed
|
1.1 Spec
|
Specification Logistics
|
Specification Revision
|
Spec / Schema / DTD
|
27 Jan 03 – Updated in 1.1 Draft 2d
7 Jan 03 It was agreed that schema and specification changes
would be synchronized.
18 Dec 02: Spin-off from Issue 9. What is policy on relationship
between Specifications and Schemas / DTDs?
Do minor changes to the DTD and Schema require a revised
specification, and visa versa? John Reid / Mark Levins
Issue raised during Issue 9 discussion at XLIFF
teleconference
|
John Reid
/ Mark Levins
|
Issue
raised during Issue 9 discussion at XLIFF teleconference
|
|
13
|
Closed
|
1.1 Spec
|
Interoperability
|
Design
|
Add
phase-name attribute to <count>
|
27 Jan 03 – Updated in 1.1 Draft 2d
#7 Jan 03
This was agreed
Proposal: Add phase-name attribute to <count>
We already have a <phase> element that stores the tool-id used in
that phase. The phase-name attribute could be added to <count>. Thus,
when that count was produced and by what, could be ascertained by any
subsequent tool and a determination of it to use the count could be made.
|
John Reid
|
John’s
Proposal
|
|
14
|
Assigned
to Editor
|
1.1 Spec
|
Deliverables
|
Schema
|
Validation
of XLIFF 1.0 with 1.1 Schema
|
18 Feb 03: Doug suggested that we include a
section ‘helpful tips on how to migrate from 1.0 to 1.1. It will be stated in this section that
in order to have xliff 1.0 documents validated against the xliff 1.1
schema, the 1.1 namespace will have to be declared.
11 Feb 2003 Discuss and possibly vote on this
issue.
Keep the targetNamespace in the schema (as it
is now), and document that XLIFF 1.0 documents will
need to specify the XLIFF1.1 namespace in order to validate.
|
Doug
|
Doug's
proposal (31 Jan 03)
|
OASIS
Namespace Guideline
More
examples
|
15
|
Assigned
to Editor
|
1.1 Spec
|
Interoperability
|
Design
|
Bin Unit
size / coord
|
18 Feb 03:
Decision: A new attribute, 'xid', be added
to all inline elements which references the id in the trans-unit
and bin-unit.
Proposed by John and
seconded by David
This was carried by
11 votes for, 1 against and 1 abstention
John had sent a
proposal on the <bin-unit> issue which Enda commented on in a follow
up mail.
http://lists.oasis-open.org/archives/xliff/200302/msg00030.html (John's mail)
http://lists.oasis-open.org/archives/xliff/200302/msg00032.html (Enda's mail)
The issue of rid having
two different purposes depending on what element it was an attribute of was
raised.
It was proposed that
a new attribute, 'xid', be added to all inline elements
which references the id in the trans-unit and bin-unit. Proposed by John
and seconded by David
This was carried by
11 votes for, 1 against and 1 abstention
11 Feb 03 : John will formally write and suggest how we could
reference using tu-ref and a bu-ref attribute that allows trans-units and
bin-units to linked through their ids.
Original Proposal:
Where we have icons that are being localized, we
need to keep track of the change in size of the icon. However, the current
definition of <bin-unit> does not have that information. In the
<trans-unit> we have the coord attribute to store that info. Since we
are at a 1.0 implementation, we could use a <prop> to give us that
info but I prefer the <context> since we can codify it and make it
understandable to translators, provided that the tools understand it.
<bin-unit id="1" mime-type="image/gif"
translate="yes" reformat="yes">
<bin-source><external-file
href="btnadvanced.gif"/></bin-source>
<context-group name="translation">
<context
context-type="bin-coord">0;0;86;16</context>
</context-group>
</bin-unit>
The better solution would be to add coord as an
attribute of <bin-unit> and <bin-target>. After all, what does reformat control for
<bin-unit>? The only attributes that could be reformatted are mime-type,
restype, and resname. We may need the other following attributes:
coord
<bin-unit> and <bin-target>
size-unit
<bin-unit> only
maxheight
<bin-unit> only
minheight
<bin-unit> only
maxwidth
<bin-unit> only
minwidth
<bin-unit> only
The above could then be expressed as follows.
<bin-unit id="1" mime-type="image/gif"
translate="yes" reformat="yes"
coord="0;0;86;16">
<bin-source><external-file
href="btnadvanced.gif"/></bin-source>
</bin-unit>
If someone has come across this same problem and
found a different solution, I would appreciate the help. Otherwise, as much
as I don't want to delay the process, we may want to consider taking care
of this now. What do you think?
|
John Reid
|
John's
original proposal
|
Yves’
Follow Up
Doug’s
input
Yve’s
next follow up
Stephen
Holmes’ input
|
16
|
Assigned
to Editor
|
1.1 Spec
|
Interoperability
|
Design
|
Attribute
name Case guidelines
|
18 Feb 03: Outcome
1. Keep
lower case for the attribute names - no objections
2. Remove
the word 'strongly' from spec -
because where attribute definition is 'text', we can't verify – no objections
3. Allow
whitespace for attribute values - because if we change this then 1.0
documents containing white space in attribute values will fail 1.1
validation
Aside
Mark pointed out, as a related aside, that all
suggestions for attribute values so far in the spec doc need to be made
lower case.
These are still under discussion and need to be
agreed yet.
11 Feb 2003 Discuss and vote
Removing the guidelines about using lowercase
values for attributes. The first paragraph of section D.2. As it
is part of the 1.0 specification we need vote to
accept it.
|
Yves & Christian
|
Yves’
original mail
|
|
17
|
Assigned to Editor
|
1.1 Spec
|
Deliverables
|
Schema
|
Extension
Namespace
|
18 Feb 03:
Decision: change the
extension point from 'other' to 'any'. This would allow you to have XLIFF
as an extension proposed by Christian and seconded by Yves
This was carried by 5 votes for, 2 against and 3 abstentions
18 Feb 03
Shigamichi - would like to do some more research, he would
like to see an example of how people use this 'ANY'.
Christian & Yves will try to come up with examples and
make a recommendation for the next meeting.
Mark pointed out that this may not be a global discussion,
maybe we would need any sometimes and other in other times.
11 Feb 03:
One little (but important) point about
the extension points in the schema: They are currently set as '##other',
which means "Any well-formed XML that is not from the target namespace
of the type being defined" (thus, non XLIFF). Christian reminded me
that a while back, there was a discussion
about replacing this by '##any', which
means "Any well-formed XML from any namespace" (thus, including
XLIFF itself). The rational was that we may want give users a possiblity to
use XLIFF data categories in a non-standard context. See the W3C documents
for more information on namespaces at
http://www.w3.org/TR/xmlschema-0/#nsTable. Input on this would be welcome
|
Yves
|
Yves’
original mail
|
|
18
|
Assigned
to Mark / Yves
|
1.1 Spec
|
Interoperability
|
Design
|
context-type
|
18 Feb 03: Decision: context-type is
unchanged (only one value per instance).
Action Item: Mark will verify his
results and pass it on to Yves.
11 Feb 03: As per yesterday discussion
it seems that some of us assume the 'context-type' attribute can take several
values (like 'purpose'). There is no information about this is the current
specifications and the current
schema doesn't allow this. If it's the
case, the schema needs to be adapted and use a pattern like for 'purpose'.
When reading the specifications keep
in mind that if the description of the
attribute does not mention the values can be used in combination it means
the schema does not allow combination.
Let me know where else there is a
discripancy like for 'context-type'.
|
Yves
|
Yves’
original mail
|
|
19
|
Open
assigned to Bryan
|
1.1 Spec
|
Interoperability
|
Design
|
Consolidated
Attribute Values Lists
|
25 Feb 03: Bryan developed XSD solution which solved the problem by
defining count-type as a union of attribute values of
datatype+restype+state and pre-existing values list. This portion of the work is now
complete.
Last remaining issue is how to
validate mimetype value, since we
don’t want to list all known media/subtypes but only validate that value
consists of one of 8 valid media type and correct syntax per RFC . Bryan to investigate and propose
solution before the end of week.
18 Feb 03: John led a discussion on this topic, indicating that Option 1 is pretty much
what we have in the present proposal,
Option 2 is the preferred method but John was unable to implement, and Option 3 is what more or less what
Gerard suggested in his proposal.
The TC agreed that Option 2 is the best solution, and Bryan Schnabel agreed to research
and find the appropriate XSD If
this solution is not found, then it was agreed to fall back to Option 1.
18 Feb 03:
John opined that there are 3 options
for us: 1) enumerate the count-typs as we have done without reference to
datatype, restype, and state; 2) find a method in the schema to refer to
the attribute values of datatype, restype, and state in the definiion of
the count-type (e.g. datatypeValueList | restypeValueList | stateValueList");
3) find a method to actually refer to what is counted in the XLIFF via the
count-type. He thinks that it is too late to do #3 but would be worthwhile
to do #2.
John will try to
implement #2 option, above for the next meeting.
11 Feb 03:
The current proposals we have been
discussing for new values for this list of attributes raise the issues of
cross-pollination 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.
Solution:
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.
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 won't discussed here.
|
Gerard
|
Gerard’s
Original Proposal
|
|
20
|
Deferred
|
1.1 Spec
|
Interoperabilty
|
Design
|
Phases of
Alt Trans
|
25 Feb 03: No solution proposed – TC decides to defer this issue.
18 Feb 03: John to come up with proposal by next meeing or we will drop
the matter for 1.1
11 Feb 03: not covered in today’s meeting
Yves originally suggested using the
existence of the match-quality attribute to determine whether an alt-trans
was leveraged or change control. Match-quality is free text that can
contain a score or any arbitrary value based on the tool that generates the
<alt-trans>. Unfortunately this makes it difficult to rely on that
attribute.
Mark suggested adding a reason
attribute to the <alt-trans> with the values 'TM Suggestion', 'MT
Suggestion', 'Rejected-Inaccurate', 'Rejected-Spelling', 'Rejected-Grammar'
and 'Rejected-Length'. This would allow us to mark an alt-trans as being
leveraged ('TM Suggestion' and 'MT Suggestion') or change-control
('Rejected-Inaccurate', 'Rejected-Spelling', 'Rejected-Grammar' and
'Rejected-Length'). Thus, all <target>s in an <alt-trans> would
have to have the same reason. Or, rather, a new <alt-trans> would be
needed for each of the rejected reasons. This may create a lot of
<alt-trans> but only if someone (the translator?) is doing a poor
job. Likely there will only be very few of these.
I had suggested we use the origin
attribute of <alt-trans> with the value 'this-file' to indicate a
change-control. This would require enumerating that one value for origin
and making any other values to begin with an 'x-', to be consistent. That
just isn't very practical.
Maybe a combination Yves's and Mark's
suggestions are the answer. Enumerate match-quality with Mark's values and
allow extension.
I still stand by my suggestion of
adding a state attribute to <trans-unit> for the reasons outlined. I
also suggested to add Mark's reason values to state. However, I suggest
that we not do that.
|
John Reid
|
John’s
original proposal
More
discussion by John (21 Feb)
|
Doug’s
Comment
John’s
reply to Doug
|
21
|
Assigned
to Editor
|
1.1 Spec
|
Interoperabilty
|
Design
|
Attribute
Values List
|
25 Feb 03: TC modified and voted to
accept lists in principal for context-type, count-type, restype, datatype. A number of items were also moved to
state.
18 Feb 03: Tony to consolidate all
inputs and respond with updated list before next meeting.
Define the list of list of attribute
values.
|
|
Tony’s
consolidated list
Tony’s revised list
http://lists.oasis-open.org/archives/xliff/200302/msg00051.html
|
|
22
|
Deferred
|
1.1 Spec
|
Interoperability
|
Design
|
Inline
Tags
|
25 Feb 03: TC defers this item to post-1.1 timeframe.
20 Feb 03: Use of some of the inline
tags requires clarification, but
probably not for 1.1 timeframe.
Might be a documentation issue.
|
David Pooley
|
David's
original mail
|
Yves’s
reply & Observation
|