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
|