[xliff] Updated Issues

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

Attached as HTML file...  if the formatting is a problem,  can you 
please tell me what your system is, what browser you're using...


-- 
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

Active XLIFF TC Issues

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. 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	Assigned to Editor	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. 3 Dec - unanimous vote to remove from the spec. Further action requried:  remove from the spec.	John Reid	John Reid's Proposal	Mark Levins' Suggestion
3	Unassigned	1.1 Spec	Interoperability	Design	New elements "default" and "defaults"	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	Christian's Proposal	Christian's Amended Proposal without XPATH
4	Unassigned	1.1 Spec	Interoperability	Design	Phase names in Alt Trans	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"
6	Unassigned	1.1 Spec	Interoperability	Design	reformat Element revisited	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 Lovatt	Mat's Initial Proposal Mat's Revised Proposal	Mark's Comment
7	Unassigned	1.1 Spec	Interoperability	Design	Context-group "purpose" recommended values	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	Unassigned	1.1 Spec	nteroperability	Design	phase-name as optional <alt-trans> attribute	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

Resolved XLIFF TC Issues

ID	Status	Spec	Topic	Class	Title	Summary	Proposed By	Original Proposal	Subsequent Discussions
5	Closed	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. 3 Dec 2002 - Unanimously voted to leave this matter of editorial style to the discretion of the editor.  No further action required.	Bryan Schnabel

   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