[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [xliff] XLIFF Teleconference Details & Agenda - Tuesday, 26 Nov 2002
|
Dial-in Instructions: UK National Dial-In: 0870 550 3090
Agenda:
1/Roll Call (5 min) 2/Review all remaining Open Issues listed in the attached
tracking report. (20 minutes per item max = 80 min)
3/Schedule of remaining work (10 minutes) 4/Any New Business 5/Next meeting - Tues, 5 December 2002, 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 |
| 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 | |||||||||
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC