Re: [xliff] Fw: Solution #6

[Tony Jewtushenko <Tony.Jewtushenko@oracle.com>]

Hi John,  Yves,  etc.

 

Thanks for your contributions to this lively discussion.

 

I disagree with Yves about leaving the reformat issue unresolved to some future,  unknown,  unplanned release.  Doing so sends an unambiguous message to anyone considering implementing XLIFF that it may be best to wait for a subsequent release which may never come.  The reformat issue is a very real problem that affects anyone who uses XLIFF when attempting to leverage (reuse) previous translations that require change to trans-unit metadata.  If we don't address the problem now,  then the only way to work around this problem is to extend the trans-unit via private namespace and add the required elements and attributes as per Mat's proposal.  Some might argue that custom extensions were designed precisely for this purpose,  but the problem directly affects each and every XLIFF implementer that intends to reuse existing translations,  meaning that each must implement their own custom,  non-standard extension.  Custom namespace extensions shouldn't be the workaround to limitations that affect everyone.

 

Now,  of the 4 solutions presented last week,  we all agreed that Option 2 was best choice architecturally.  However,  as I had assumed would be the case,  John Reid raised the issue that we had as a TC previously agreed to maintain data compatibility with 1.0 in this release,  and migration would create a serious problem for him.  Oracle has implemented 1.0,  but we have found that the reformat issue is serious enough that it is worth the pain of migration.  So I propose that we have a serious look at Option 4 - as proposed by Doug - which provides all the elegance of the Option 2 solution while maintaining full data compatibility with 1.0.  I believe this option was initially not taken seriously because it was thought to be too awkward to implement,  but I can think of no reason or scenario where this would be the case - can anyone educate me please?

 

Option 4 gives us what we need to fix the reformat problem while remaining firmly in the 1.1 space.  I strongly recommend adopting this option as well as continuing to call this work "XLIFF 1.1" rather than 2.0,  since backwards compatibility is maintained.  Please chime in with your opinions - and be prepared to vote on this matter on Tuesday.

 

Finally,  we're nearly finished with our present 1.1 work,  we're behind schedule and a bit tired but I urge you all to keep the faith for just a bit longer.  There's a lot of great work in this spec - it's a vast improvement over 1.0,  and we should all be proud of our contributions to the effort. And once we resolve this final open issue,  clean up the spec and write up our 1.1 collateral,  this revision represents work that is certainly at a standards quality level.  However,  if you're aware of any specific reason why the TC should hesitate with submitting this work to OASIS as a standards candidate then I urge you to communicate your concerns as soon as possible.

 

Regards,

Tony

 

 

----- Original Message -----

From: John Reid

To: xliff@lists.oasis-open.org

Sent: Wednesday, January 22, 2003 10:57 PM

Subject: Re: [xliff] Fw: Solution #6

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