MHonArc v2.5.2 -->
xliff message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: [xliff] Re: XLIFF Teleconference Details & Agenda - Tuesday, 3 Dec 2002
|
The tracking report is attached to this
email.
----- Original Message -----
Sent: Monday, December 02, 2002 3:50
PM
Subject: XLIFF Teleconference Details
& Agenda - Tuesday, 3 Dec 2002
Dial-in Instructions:
When: Tues, 3 Dec 2002, 04:00PM
Europe/London/Dublin / 08:00 AM PST
UK National Dial-In: 0870 550 3090
International Dial-In: +44 118 924 0290
Meeting ID: 30543
*NOTE: Last Tuesday's meeting was cancelled due to lack
of quorum. Please make every attempt to attend tomorrow's meeting - it
is within our grasp to close down 1.1 requirements work with just one
more meeting.
Agenda:
1/Roll Call (5
min)
2/Review all remaining Open Issues listed in the attached
tracking report. (15 minutes per item max = 90 min)
3/Schedule of remaining work (10
minutes)
4/Any New Business
5/Next meeting - Tues, 10 Dec, 04:00PM
Europe/London/Dublin / 08:00 AM PST
Tony
Jewtushenko
mailto:tony.jewtushenko@oracle.com
Sr.
Tools Program Manager direct tel: +353.1.8039080
Product
Management - Tools Technology Team
Oracle Corporation,
Ireland
|
Title: XLIFF TC Issues Tracking
XLIFF
TC Issues Tracking
| 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
26 Nov 2002 - discussed informally by group while waiting for quarum. �Discussion
result is that the language in question, �although somewhat awkward, �is
correct as per similar types of specifications, �and should be kept as is.
|
Bryan Schnabel |
� |
� |
| 6 |
Unassigned
|
1.1 Spec
|
Interoperability
|
Design
|
reformat Element revisited
|
Proposal that any structure that may be translated
is enclosed within a reformat� element. �Example:
<reformat>
��� <sourceval>
�������� x-value="xxx"
��� <\sourceval>
<\reformat>
is translated to
�
<reformat>
��� <sourceval>
�������� x-value="xxx"
��� <\sourceval>
����� <transval>
�������� x-value="zzz"
��� <\transval>
<\reformat>
Any structure not enclosed within a reformat element
may not be changed during translation, except state etc.
An advantage is that any structure can be controlled
in this way,� regardless of being XLIFF standard
or an extension.
|
Mat Lovatt
|
Mat's
Proposal
|
Mark's
Comment
|
ID = Issue number
Title = Short title/name of the issue
Spec = Document referred
to in issue (1.1 = XLIFF 1.1 specificati
Description = Short description
of issue, possibly including link to origin of issue
Original Proposal - Link to XLIFF TC 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
Summary Current proposal for resolution
of issue, possibly including link to further text
Proposed by �Person who raised the issue
Owner XLIFF TC Member responsible for the issue
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC