The big question of XLIFF scope: Was: Re: [xliff] Element simpleNote

[Arle Lommel <alommel@gala-global.org>]

After seeing Helena’s mail, I must confess that it brings up an area of some concern for me in the potential direction of XLIFF. I know there is at least some support for adding optional modules to deal with segmentation, translation memory, and terminology management (I'm not certain of this list is complete) in order to make XLIFF more self-contained. There is also a proposal to allow XLIFF files to be multilingual (n ≥ 2) rather than strictly bilingual (n = 2).

I understand that the goal of the first proposal is to lessen XLIFF’s dependence on custom extensions that impede interoperability, but I am concerned that this course of action may have considerable negative consequences, whatever technical merits it may have. In particular, I have the following concerns:

1. More modules makes XLIFF more complex. I keep running into the perception in the community that XLIFF already tries to do too much and that the lack of a single flavor of XLIFF that works with all tools is a big problem. If we add more features (even if they are optional), it will only exacerbate the problem. Declaring the modules to be optional seems, on the surface, like a good way to deal with this issue, but what happens if a major vendor starts producing XLIFF files that rely on these extensions to be usable? Are they then really optional anymore if interoperability is the goal? If not, then interoperability it harmed by these features. While we might say that this won't happen—because our design skills will result in something that can be processed without using those modules or because we will provide guidelines on how to avoid problems—we already know that implementers do not follow the standard properly as it exists today. Adding more modules (and the semi-exponential increase in complexity that might arise from the potential interactions between them) would have a tendency to make this problem of inconsistent implementations worse.
2. Competing XLIFF modules vs. stand-alone standards. If we build in these modules and they differ from other standards (TMX, TBX, SRX) in philosophy or functionality, we then create two ways to do the same thing: the XLIFF way and the non-XLIFF way. This shift will only increase standards fragmentation. This is not just a problem in that it might force developers to choose between two different approaches, but it also would stand in the way of interoperability in heterogeneous supply chains. If, for example, a production chain uses TMX at one point for TM purposes but another point uses XLIFF and the TMX and XLIFF TM modules differ in some way, will this cause interoperability problems because the data assumed/generated at each point is different? Again, we might assume that we can work our way around any such problem, but how will we know that we have before it is too late? Given the huge number of potential interactions between tools, I would actually suggest that we cannot actually know that our decisions will not cause problems.
3. Massive expansion of XLIFF scope. Including these module would mean a significant change in scope for XLIFF. I realize that the recent XLIFF survey was designed to gauge support for such a move, but the survey also provided no way for respondents to understand what those courses of action mean in practical terms. So if we do expand the scope, I think this needs to be brought to the attention of the community in more detail. This is not something that can be reduced to a poll question since most people would not know, from the poll question, what the implications (pro and con) are. While polls are valuable, they are only as good as the knowledge of those responding. It may be that expanding the scope of XLIFF is a good idea in the abstract, but it is the practical details that will make it sink or float.

My preference for how to handle the need for these modules would be to look at using namespaces and references to other, independent, standards. I realize that there may be issues with those standards that right now make them unsuitable for XLIFF’s purposes, but I think the proper approach is to try to influence those standards (send feedback to ETSI, or have OASIS propose to create a TC for one or more of the standards in cooperation with ETSI) for future versions or to define compatible subsets (you could define an XLIFF-compatible XCS file for TBX, for instance). Doing so would ensure that we don’t end up splintering the standards environment and would help unify the current situation.

By contrast, the second proposal, to allow XLIFF to be multilingual, would have my full support. I think it makes sense to allow for that to happen. I realize that this change moves XLIFF more in the direction of TM, but it also fits entirely with what I see as the core functions of XLIFF.

I think it's obvious that I am skeptical (at the least) of the increase in scope and additional of modules, but I have to always admit that I may be wrong. However, I think these issues are so crucial that we need to bring them up explicitly to the broader community, not just to XLIFF insiders. 

As a result, I would like to invite someone from the committee who is in favor of the expanse in scope to outline the argument in favor of making these changes and I would volunteer to help push that message out to the broader community, paired with my concerns, to try to foster an open dialogue about some issues. The more the broader community is aware of such issues (fleshed out, not reduced to a poll question), the more likely we are to get good feedback that hits the core issues. Lest anyone think that I would be trying to control the process too much, I would invite the dialogue about the precise message (my part and the arguments in favor) to take place on this list until we reach consensus before I send it out to the mailing lists I have access to.

Best,

Arle

On Jul 19, 2011, at 07:48 , Helena S Chapman wrote:

I second Christian. If XLIFF was to be complete on its own without reference to any other standards, it will never be pragmatic enough for anyone to adopt it.