[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [xliff] Fw: Solution #6
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
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC