Re: [xliff] Fw: Solution #6

[John Reid <JREID@novell.com>]

Yves makes very good points about which version we are to release, all of which I agree with. However, I'm not sure I agree with the conclusion. Nor am I even happy with the direction of the debate.

 

When an XLIFF solution was proposed to my company, the first question was, "Is this an industry standard?" My answer to them was "Not yet but it will be shortly." That was over a year ago and we are no closer to a standard that **developers can rely on** than we were then. Novell has implemented XLIFF 1.0. We definitely want 1.0 supported because that is what we are delivering. That cannot be changed. At least not until a subsequent release. We also cannot change that with each release because of a constantly changing XLIFF. The TC continually talks of the next version. With that, will 1.1 be put forth as an OASIS standard? It doesn't sound likely.

 

Although solution #2 may seem to be the most desirable of the reformat solutions, does it really meet all the requirements we should have? Have we even defined the requirements? Chomsky revolutionalized linguistics theory (my background coming through) by requiring a "scientific method" approach. This meant that in order to propose a solution it had to

1. solve the stated problem

2. fit within the rules of the generalized theory (re: backward compatibility)

3. possibly extend a solution to other problems

We need to define these requirements for us, analyze the solutions to date asking these questions, and adjust accordingly. New suggestions should be analyzed with the same regularity. This allows for solutions to be regular and thus easier to implement. If solutions are allowed to be ad hoc, implementation is more difficult. One of our goals must be to ease implementation.

 

The various named groups of XLIFF are an ideal example of adhering to the above criteria. In the case of phase, it solved the problem, it fit in with other XLIFF contructs (prop) and with xml (using phase-name as a reference), and we were able to extend this construct to provide solutions for counts and contexts and, by further extension, the tool information.

 

Because the TC is trying to create a format that works for a wide variety of content producers and localizers there will need to be some compromises. However, because we are creating a standard, that format, by definition, cannot be an ever changing target. Just look at what happened to HTML, an SGML vocabulary that was allowed to change rapidly and by every implementor until it no longer was recognizable as an SGML implementation. All our solutions may not be the most elegant nor aesthetically pleasing but they must meet the above requirements.

 

-john