Some feedback on implementation of current XLIFF

Hi all,

    

    I've gotten some fairly pointed feedback on the current XLIFF
    version from Andrew Pimlott (Welocalize), who has given me
    permission to send this on to the group. I hope it's useful since it
    does touch on some of the issues we have discussed, like the role of
    extensions, and some things that may be relevant to next-generation
    XLIFF. I'm sure Andrew (whom I have copied on this mail) would be
    happy to discuss any of these points.

    

    [Start Andrew's comments]

    It's easy to pick on XLIFF itself and its implementations, but I'm
    sure this audience has already heard the pot-shots, so I'll try to
    state a few high-level points in a constructive way.

    
      
Reading the spec, I get a general sense that the approach
        taken to designing XLIFF was, "how do we wedge in all the
        information people want to include?". I think a better starting
        point is, "how would an XLIFF document be transformed by
        XLIFF-compliant (app-independent) tools in use cases A, B, C,
        with a great user experience?". I have often thought of some tag
        or other, I can see why someone wanted to put this here, but
        what do I (as an XLIFF-compliant tool writer) do with it?

      
I think handling fewer use cases well is better than handling
        them all poorly. Do you have an answer for, "what is XLIFF
        really good at?"

      
Vagueness is an enemy of interoperability. It's too easy to
        find examples in XLIFF, but one I just ran across is the
        charclass attribute, whose value has absolutely no defined
        meaning. This has no place in a standard. [Note
            from Arle: I went and looked, and indeed there is no
            guidance for how the content is to be represented. There was
            some discussion nine years ago on the XLIFF list about the
            purpose, but I didn't find any concrete examples of how to
            use it.]

      
Vagueness can be avoided by asking, how would an
        XLIFF-compliant tool process this? If you can't answer that,
        leave it out! (A lot of XLIFF reminds me of the standardese gag,
        "This field is used to store your favorite bit.")

      
Complexity is another enemy of interoperability. Happily,
        removing vague features reduces complexity as well. An example
        is <group>, which complicates not only parsing and
        representation, but semantics as well, since some things are
        supposed to be inherited within a group. Yet the meaning of a
        group is left vague, and the details of inheritence are left
        out.

      
XML contributes significantly to complexity. I don't think XML
        is negotiable, but I think it's worth recognizing that to make
        XLIFF simple, you need to manage the complexity that XML brings.
        Some things that are tricky for an application are: transforming
        an XLIFF doc without accidentally changing existing meaning (eg.
        questions of when element order is significant); writing an
        efficient, easy-to-use streaming parser (large data can appear
        where you may not expected it); handling namespaces correctly.

      
Extensions should be acknowledged as part of any practical use
        of XLIFF, to make up for what XLIFF can't do well in a standard
        way. If something can't be specified precisely, it should left
        for an extension, with guidance on common extension use cases.
        The spec should also consider the tricky question of how a tool
        should handle extensions it doesn't understand.

      
Different uses of XLIFF should be acknowledged and called out
        explicitly. For example, the standard "strongly recommends" that
        XLIFF docs be bilingual. But that means nothing really. It's
        trying to call out a restricted form of XLIFF that is commonly
        useful. So maybe there should be a bilingual XLIFF "profile", so
        an app can say "I accept bilingual XLIFF" and everyone will know
        what that means, and a bilingual XLIFF doc that has multiple
        languages is non-compliant.

      
Give lots of examples. Developers are lazy, so make it easy
        for them to do the right thing. "If you're trying to achieve
        this, do it this way." "If you get this data, do this with it."

      
I'm a big fan of compliance checkers. I think it would be
        great to produce one along-side the standard. Makes it easy to
        say, "your implementation is wrong, here's proof, and you have
        no excuses!"

      

    
    

    Andrew Pimlott

    System Architect

    Welocalize

    San Francisco, CA

    [End Andrew's comments]

    

    I think these are worth considering as constructive feedback.

    

    Best,

    

    Arle