[xliff] Re: XLIFF Teleconference Details & Agenda - Tuesday, 3 Dec 2002

[Tony Jewtushenko <Tony.Jewtushenko@oracle.com>]

The tracking report is attached to this email.

 

----- Original Message -----

From: Tony Jewtushenko

To: xliff@lists.oasis-open.org

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