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:
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
