OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

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

Subject: RE: [xliff] Some feedback on implementation of current XLIFF

Hi Arle and Andrew,


Thanks for bringing this feedback to the group. Getting input from people in the community helps the TC tremendously. Andrew, at first read your points seem clear and understandable. Several of the points you make resonate as commonly heard feedback, and will almost certainly show up as corrections/improvements we make in XLIFF 2.0. And the points you make that are somewhat new (to me) will certainly be seriously evaluated.


Though not represented on the XLIFF TC, your company has a history of helping and advising, and I personally appreciate that. In fact, in conversations I've had with Derek, I don't think it's too far into the realm of impossibility that someone from your company could join us. Therein lies one of our challenges. We are a small, but motivated group. Any help we could get, in the form of TC participation would help us to get a better spec into the community sooner (I'll bet my, ehem,  subtle request (straight out of the TC chair handbook) does not come as a complete shock to you ;-)






From: Arle Lommel [mailto:arle.lommel.lisa@gmail.com] On Behalf Of Arle Lommel
Sent: Thursday, February 17, 2011 9:36 AM
To: xliff@lists.oasis-open.org; andrew.pimlott@welocalize.com
Subject: [xliff] 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
San Francisco, CA
[End Andrew's comments]

I think these are worth considering as constructive feedback.



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