OASIS XML Localisation Interchange File Format (XLIFF) TC

[xliff] Open issues Tracking document

  • 1.  [xliff] Open issues Tracking document

    Posted 01-09-2003 04:23
     MHonArc v2.5.2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    xliff message

    [Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


    Subject: [xliff] Open issues Tracking document


    Hi all,
     
    I have edited Tony's Open Issues Tracking Doc and attached it.
     
    My understanding is that the only open issue for Spec 1.1 is the reformat proposal. If I am wrong in thinking this could someone please correct me.
     
    Thanks,
     
    Peter.

    Peter Reynolds, Software Development Manager
    Bowne Global Solutions, formerly Berlitz GlobalNET
    3, West Pier Business Campus, Dun Laoghaire, Co. Dublin, Ireland
    Tel: +353-1-202-1280
    Fax: +353-1- 202-1299
    peter.Reynolds@bowneglobal.ie
    Web Site: http//www.bowneglobal.com
    http//www.berlitzIT.com

     
    Title: [xliff] Updated XLIFF Open Issues

    XLIFF Open Issues Report � Updated 9 Jan 03

    Key:

    Open � Unassigned

    Assigned - further action required

    Assigned to Editor

    Closed � no further action required

    Deferred until after Spec 1.1 is released

     

    ID

    Status

    Spec

    Topic

    Class

    Title

    ����������� Summary�����

    Proposed by

    Original Proposal

    Discussion History

    1

    Assigned to Editor

    1.1 Spec

    Extensibility

    Design

    Extending Attribute Values

    10 December 2002 = Unanimous vote to use the 'x-' mechanism for attribute value extension. .

    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

    3 Dec - unanimous vote to remove from the spec.

    Original:

    Further action requried:  remove from the spec.

    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.

    John Reid

    John Reid's Proposal

    Mark Levins' Suggestion

    3

    Assigned to John Reid

    1.1 Spec

    Interoperability

    Design

    New elements "default" and "defaults"

    19 Dec 2002: the proposal is to add these attributes to group for the express purpose of setting defaults for all child <trans-unit>s: charclass, maxbytes, maxheight, maxwidth, minbytes, minheight, minwidth, size-unit, translate, reformat
    The attributes of the <trans-unit> that have not been considered for the <group> element are listed below: approved, phase-name, tu-state (proposed)

    17 Dec 2002: John Reid to draft proposal for extending <group> for storing default attributes.

    10 Dec 2002 : Mark raised John Reid's suggestion of using <group> to store defaulted values and adding the defaultable attributes to the group element. Tony suggested closing out on the original proposal and not using XPath by replacing the default strategy with <group>. John Reid volunteered to redefine the proposal around new attributes of <group> for the next meeting.

    Original:

    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
     
    7 Jan 20003 � Members of the TC have been asked express opinions on this before next week when there will be a vote.

    Christian Lieske

    Amended by John Reid

    Christian's Proposal

    Christian's Amended
    Proposal without XPATH

    (29 Dec) John Reid�s use of <group> attributes proposal

    4

    Assigned to Editor

    1.1 Spec

    Interoperability

    Design

    Phase names in Alt Trans

    10 Dec 2002: John outlined his most recent proposal which required very little changes to the XLIFF specification on the basis that it already provided enough support for tracking phases and histories. Tony motioned for voting on John's proposal at the next meeting, giving everyone enough time to digest the proposal and be happy with the suggested additional attribute values.

    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"

    John Reid's Proposal (10 Dec)

    6

    Assigned to Mat Lovatt

    1.1 Spec

    Interoperability

    Design

    reformat Element revisited

    7 Jan 2003 Mat outlined his proposal (see discussion history) This will be discussed on 14 Jan 2003

    17 Dec 02: Mat to rewrite proposal in full as it would appear in the specification,and group to respond with any questions or issues.This will be done before the next meeting.

    10 Dec 02:Matt tabled new suggestions for reformatting based on previously sent email. Mark raised objections to instruction-based reformat element that would require similar functionality to XPath and suggested adding new specific elements for content that can be changed as part of the translation process (e.g. font, coord, style etc) where these elements could contain a boolean attribute to indicate whether they could be altered. Matt agreed to further investigate this approach and create some examples for the next meeting. Enda then raised the question of how this would affect the 'default' discussion and Matt brought up the ability to default a translation or translatable content. Matt agreed to try to factor these two points into his investigation for the next meeting.

    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

    Mat's proposal

    7

    Assigned to Editor

    1.1 Spec

    Interoperability

    Design

    Context-group "purpose"
    recommended values

    10 Dec 02 :The proposal was unanimously approved.
    Original Proposal:
    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

     

    9

    Assigned to Editor

    1.1 Spec

    Interoperability

    Design

    Attribute Enumerated Values

    7 Jan 2003 � A motion from Doug was passed unanimously and this stated all enumerated valued would be listed within the specification.
     
    18 Dec 02:discussion is deadlocked during XLIFF Teleconference.
     
    17 Dec 02: 
    Discussion on listing all enumerated values for attributes in the specification (or not). At issue is whether these values are part of the specification or part of an external schema. 

    Mark Levins

    Mark's proposal

     

    10

    Assigned to Editor

    1.1 Spec

    Interoperability

    Design

    Whitespace / List item delimiters

    7 Jan 03
    Mark�s proposal was agreed.
     
    6 Jan 03:
    Mark Levins submits revised text for the specification � to be discussed at the next teleconference:
     
    D.2. Attribute Values

    ��� 
    ����Attribute values are case sensitive. It is strongly recommended that lower-case values are used. The specification recommends a number of values for some attributes, these are all lower-case. 
    ����Where multiple attribute values are to be used in an XLIFF document, two approaches are used:

    ��� 
    ����
            For enumerated attributes (such as the 'purpose' attribute of <context-group>) the separator must be a space. 

    ��� 
    ����
            For other textual attributes that are not validated, the specification recommends the use of the semi-colon as a concatenation separator for values, for example, multiple contacts may be listed for a <file> with the attribute-value written thusly: contact-name="Frank Sinatra;Sammy Davis Jnr;Dean Martin".
     
    17 Dec 02: 
    Multiple attribute values (lists) and valid separators � not certain if legal to use ; or other delimiters, appears that   whitespace is recommended by W3C, but this does not
    Preclude using ; or ,.

    Mark Levins

    Mark's Initial Observation

    Doug's Suggestion

     

    Mark�s revised text for spec

    11

    Assigned for discussion after Spec 1.1

    Spec following 1.1

    Interoperability

    Design

    TextContent Extensibility

    7 Jan 03
    It was agreed at this meeting to defer discussion on this until after Spec 1.1 is complete.
    6 Jan 02: This issue was tabled after considerable discussion during previous XLIFF teleconference.The discussion will continue at next meeting (7 Jan).The main points from the discussion were:
    1/XHTML can presently be handled within BPT and EPT inline tags
    2/adding XHTML tags will create complexity and the requirement that all XLIFF tools to be fully capable of interpreting XHTML tags.
     
    17 Dec 02: Extensibility of the TextContent to allow non-XLIFF tags, for example XHTML tags

    Doug

    Doug's Proposal

    Doug�s Additional comments (17 Dec 02)

     

    Doug�s additional comments(24 Dec 02)

     

    Yves� Comments (24 Dec 02)

    12

    Closed

    1.1 Spec

    Specification Logistics

    Specification Revision

    Spec / Schema / DTD

    7 Jan 03
    It was agreed that schema and specification changes would be synchronized.
    18 Dec 02: Spin-off from Issue 9.�� What is policy on relationship between Specifications and Schemas / DTDs?Do minor changes to the DTD and Schema require a revised specification, and visa versa?

    John Reid / Mark Levins

    Issue raised during Issue 9 discussion at XLIFF teleconference

     

    13

    Assigned to Editor

    1.1 Spec

    Interoperability

    Design

    Add phase-name attribute to <count>

    7 Jan 03
    This was agreed
     
    Proposal: Add phase-name 
    attribute to <count> 
     
    We already have a <phase> element that stores the tool-id used in that phase. The phase-name attribute could be added to <count>. Thus, when that count was produced and by what, could be ascertained by any subsequent tool and a determination of it to use the count could be made.
     

    John Reid

    John�s Proposal

     



    [Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


    Powered by eList eXpress LLC