| ID |
Status |
Spec |
Topic |
Class |
Title |
Summary |
Proposed By |
Original
Proposal |
Subsequent
Discussions |
| 1 |
Unassigned |
1.1 Spec |
Extensibility |
Design |
Extending
Attribute Values |
Proposal
for validation mechanism for XLIFF files that have been customized. Two
proposed alternatives are proposed for the schema:� 1. From Yves uses the 'union'mechanism and 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.�
|
Christian Lieske |
Christian's
Proposal |
sec
2.4 in WIP 1.1 spec |
| 2 |
Unassigned |
1.1 Spec |
Interoperability |
Design |
Context Group |
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. It is proposed that we add a "purpose"
attribute to the context-group element that would contain the enumerated
purposes of context information. Additional suggestions are:� 1/"purpose" is optional;� 2/also support the following attribute
values: "location" - The context-group is used to specify where the
term was found in the translatable source ,�
"location-match" specifies where the term was found and that
the context information should also be used during translation memory
lookups,� and "information"
- Specifies that the context is informational in nature, indicating for
example, how a term should be translated |
John Reid |
John
Reid's Proposal |
Mark Levins' Suggestion |
| 3 |
Unassigned |
1.1 Spec |
Interoperability |
Design |
New elements "default" and "defaults" |
Add an element 'default' to XLIFF. Furthermore, add an element
'defaults' which holds one or more 'default' elements. The mandatory 'item'
attribute for 'default' designates the object(s) to which a default applies
(the designator is an Xpath expression). The default setting itself is the
content of the 'default' element. The semantics and use of the 'default'
element are as follows:� The intent
declared with 'default' is considered to apply to all objects designated by
the 'item' attribute, unless overridden at the object itself. The element may
appear as a child of both 'xliff' and 'header'. XLIFF processors may use the
information in the 'default' element. |
Christian Lieske |
Christian's
Proposal |
|
| 4 |
Unassigned |
1.1 Spec |
Interoperability |
Design |
Phase names in Alt Trans |
Original
proposal from Mirek was to remove phase-name attributes from alt-trans,� since it didn't seem to be necessary to
track changes to alt-trans (suggested translations or pretranslation).� However, 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. |
Mirek Driml |
Mirek's
proposal |
Yves
observation |
| 5 |
Unassigned |
1.1 Spec |
Editorial |
Editorial |
�"Zero,� One or More" Language |
Propose replacing the phrase "zero, one or more" with
the more precise "zero or more." This should be done globally
throughout the specification |
Bryan Schnabel |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| id |
|
|
|
|
|
|
|
|
|
| Issue number |
|
|
|
|
|
|
|
|
| Title |
|
|
|
|
|
|
|
|
|
| Short title/name of the issue |
|
|
|
|
|
|
| Spec |
|
|
|
|
|
|
|
|
| Document referred to in issue (1.1 = XLIFF 1.1 specification) |
|
|
|
|
| Description |
|
|
|
|
|
|
|
|
| Short
description of issue, possibly including link to origin of issue |
|
|
|
|
| Req |
|
|
|
|
|
|
|
|
|
| Link to XML
Protocol Requirement that motivated this issue |
|
|
|
|
| Topic |
|
|
|
|
|
|
|
|
| Rough topic
categorisation, one of: Formal Extensibility,� Embedded XLIFF,�
Interoperability,� Schema
Design,� Migration,� Customisation |
|
|
|
| Class |
|
|
|
|
|
|
|
|
| Design or
Editorial |
|
|
|
|
|
|
|
| Status |
|
|
|
|
|
|
|
|
| One of:
Unassigned, Active, Closed, Postponed |
|
|
|
|
|
| Proposal |
|
|
|
|
|
|
|
|
| Current
proposal for resolution of issue, possibly including link to further text |
|
|
|
|
| Resolution |
|
|
|
|
|
|
|
|
| Short
description of resolution, possibly including link to a more elaborate
description |
|
|
|
|
| Raised by |
|
|
|
|
|
|
|
|
| Person who
raised the issue |
|
|
|
|
|
|
| Owner |
|
|
|
|
|
|
|
|
| XML Protocol
WG Member responsible for the issue |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|