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

The tracking report is attached to this 
email.

 

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

  
From: 
  Tony Jewtushenko 

  
To:  

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