OASIS XML Localisation Interchange File Format (XLIFF) TC

 View Only

Re: [xliff] XLIFF 1.0 issues

  • 1.  Re: [xliff] XLIFF 1.0 issues

    Posted 04-11-2002 18:49
     MHonArc v2.5.2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    xliff message

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


    Subject: Re: [xliff] XLIFF 1.0 issues


    On point 1, I'd just make the comment that the value of adding the tool
    that created the wordcount as an attribute is of relatively little use
    if you take a situation where, for example, "Tool X" generates the data,
    but "Tool Y" reads it for processing and has different ideas about what
    consitutes a word count.
    
    It's an age old problem in localisation - "Who has the correct word
    count?".  As tools may be completely proprietary, even if based on XLIFF
    containers, I see no reason in complicating the attribute qualifiers. 
    This may become the topic of a subcommitte...
    
    On point 3 - bear in mind that localisatin/language tools that aspire to
    be network-based will find base64 encoded content to be monumentally
    large to transfer.  Europe, remember, is still predominantly 56K and we
    all remember the hassle involved in FedEx'ing CD's to China - business
    reality supercedes specification.
    
    Cheers
    Steve.
    
    
    
    S  t  e  p  h  e  n     H  o  l  m  e  s
    Localisation Development Manager 
    International Product Development
    
    Voice:  +353 (1) 241 5732
    Fax:     +353 (1) 241 5749
    
    Novell, Inc., THE leading provider of Net business solutions
    http://www.novell.com
    >>> John Reid <JREID@novell.com> 04/11/02 19:02 PM >>>
    Hi All,
    
    My comments follow Mark's, between <jr>...</jr> tags. 
    
    >>> Mark Levins <mark_levins@ie.ibm.com> 4/5/02 5:59:53 AM >>>
    
    1. <note> as a child of <count>
    Currently the <count> element is very ambiguous, a note as a child
    element 
    could be used to indicate what was being counted, what was considered a
    
    word etc.
    
    <jr>The <count-group> and <count> elements can be very problematic. A
    <note> element within the <count> element may help in the customized
    support required by these elements but that is a human readable approach
    and probably would need to be defined even more to be truly useful. A
    stronger definition of the count element may do more for us. 
    <count> has the 'unit' attribute which has recommended values of word,
    page, trans-unit, bin-unit, and item. The latter three are defined
    according to elements within the spec but the former two must be defined
    by the tool creating the count. I suggest that we include the tool as an
    attribute to the count-group. This would be the same attribute used in
    <file>, <phase>, and <alt-trans>. Further refinement of the 'unit'
    attribute may alo be necessary.</jr>
    
    
    2. The <count-group>, <prop-group> and <context-group> elements can be
    
    used within a <group> without any other relevant child elements
    The 1.0 specification allows that a <group> element can contain (for 
    example) a <count-group> without containing anything to count. I think
    the 
    <group> element should be changed to contain at least one of <group>, 
    <trans-unit> or <bin-unit>.
    
    <jr>Shouldn't this requirement be placed on the <body> also?</jr>
    
    
    3. Binary elements & <internal-file>
    This is kind of a big one. At the moment the specification does not
    define 
    the form of the content of the <internal-file> element (although there
    is 
    an optional 'form' attribute). The problem is see with this is that the
    
    specification allows users place binary data directly as content - this
    
    binary content may contain the reserved XML characters < > etc which
    will 
    cause parsers to choke.
    The CDATA section approach is also not good enough to provide a
    solution.
    My suggestion is that the content of the <internal-file> be restricted
    to 
    Base64 or at least stated so.
    Also, the description in the spec for the <internal-file> element reads
    
    "The <internal-file> element will contain the data for the skeleton
    file." 
    which is technically wrong, it may also contain data for an
    <bin-source> 
    or <bin-target> element.
    
    <jr>How does CDATA fail this purpose? I wouldn't want to restrict this
    to just Base64; thus, requiring a conversion for both the producer and
    any subsequent processor that may be able to handle the original format
    without a problem. Additionally, wouldn't we need an attribute such as
    'original-format' if we forced your conversion?</jr>
    
    
    4. mime-type attribute of <bin-source>
    How come this attribute is omitted from the <bin-source> element? Note
    
    that it is an attribute of <bin-target>
    
    <jr>We generally put attributes for <source> and <bin-source> in the
    parent, <trans-unt> and <bin-unit>, respectively. The 'mime-type'
    attribute of the target allows a different mime-type for the target in
    cases where it differs from that specified from the <bin-unit>'s.
    Otherwise, the mime-type of the target is unnecessary.</jr>
    
    Cheers,
    john
    
    ----------------------------------------------------------------
    To subscribe or unsubscribe from this elist use the subscription
    manager: <http://lists.oasis-open.org/ob/adm.pl>
    
    


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


    Powered by eList eXpress LLC