[xliff] Fw: Solution #6

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

FYI:  forwarded from Yves


----- Original Message -----
From: "Yves Savourel" <ysavourel@translate.com>
To: "Tony Jewtushenko" <tony.jewtushenko@oracle.com>
Sent: Wednesday, January 22, 2003 6:30 PM
Subject: FW: Solution #6


> Hi Tony,
>
> I'm still off the main xliff eList (still trying to register back). I
could
> post this in the xliff-comments list, but it really belong in the main
list:
> Could you please post this for me? Many thanks.
>
> -yves
>
>
> -----Original Message-----
> From: Yves Savourel [mailto:ysavourel@translate.com]
> Sent: Wed, January 22, 2003 10:35 AM
> To: XLIFF list
> Subject: Solution #6
>
>
> Hi everyone,
>
> After some more thinking on the reformat issue, I came to the conclusion
> that the question is not which solution is best for coord/font/reformat
> (It's solution #2, I think we will all agree with this if we see the
> backward compatibility as a moot point). The real question is: are we now
> working on 1.1 or 2.0?
>
> For the last eight months we have been working with the assumption this
was
> a minor revision (at least I have) and now, a few weeks from our release
> goal for publication, we would decide to make it a major revision. Maybe
we
> should twice before crossing that line. I can see two main reasons against
> such move:
>
> 1- Some of the choices we made during this past months might have been
> different if we knew to be working on a major revision. This, in my mind,
> would jeopardizes what 2.0 'should have been'.
>
> 2- I would think we need to work on profiles (how to represent RC,
> properties, HTML, etc. in XLIFF) before moving to a 2.0 version because it
> is arguable that some of our findings there could lead to structural
changes
> as well.
>
> To me, these two reasons seem enough not go to a 2.0 revision.
>
> Hence, if we are indeed working on 1.1, then the changes we make should be
> backward compatible. That is a 1.1 tool should be able to cope with a 1.0
> file. One good way to ensure this is to be able to validate a 1.0 document
> with the 1.1 XSD.
>
> The solution #2 (which I see as the best solution as well) breaks that
> compatibility. This would leave us with solution #1, #3, or #4. In my
> opinion none of them is good: either too awkward or making it too
burdening
> for tool by having to support a major construct two different ways.
>
> Therefore, I have a solution #6, that I think Gérard almost hinted at, two
> meetings ago:
>
> Let's not change coord/font/reformat in 1.1. The best solution is #2 and
> belongs to 2.0.
>
> I do realize some of us are looking forward for having coord/font/reformat
> changed, but I would beg them to look at the problem with in mind the two
> reasons not to go to a major revision today. Which choice is more costly:
> Having to support a temporary solution for reformat or the 'damages' we
> would do to 2.0 down the line?
>
> I'm not trying to block anything or being a pest :) but just trying to
look
> ahead. It seems to me we have already achieved quite a lot in 1.1. Among
the
> major improvements are: the move to XSD, the cleaning up of attribute
lists,
> and the addition of extensibility (something that might help solving
> temporarily the reformat question).
>
> Such 1.1 should give new-users a good base to start and make déjà-users
> happy as well. This would also give us some time to do a very solid 2.0
> that, hopefully, would be 'final'. Most unforseen issues with 1.1 could
> probably be solved through extensibility, and the TC could learn from the
> various experiences of tool implementers, and come up built-in solutions
in
> 2.0.
>
> One last note: I thing that there is another changed we have made that
> breaks backward compatibility: we introduced a forced order of the
elements
> <header>, <group>, <trans-unit>, <alt-trans> and <bin-unit>, where no
order
> were enforced before. If we still go to 1.1, it's a mistake and it should
be
> corrected (i.e. postponed to 2.0). Hopefully, that correction would not be
> not too much of a problem for anyone.
>
> Kenavo,
> -yves
>
>
>
>