Re: [xliff] Fw: Solution #6

[Shigemichi Yazawa <yazawa@globalsight.com>]

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

I think we need to clearly define what kind of compatibility to the
prior version is necessary for the minor release.

o Backward compatibility - A tool implemented for a new version
                           without a knowledge of its prior version
                           can read and understand XLIFF documents
                           created for the prior version.

o Forward compatibility -  A tool implemented for a prior version
                           can read and understand XLIFF documents
                           created for a new version.

If we add new elements or attributes to the new version, even if they
are optional, it's not forward compatible. 1.1 already is not forward
compatible. I think that the forward compatibility is too strict even
for minor release.

However, the Migration Policy states that:

As a guideline, "Minor" releases:

   1. Shall be comprised of small changes that would not require
      re-qualification of supporting tools or technologies

I'm not sure what re-qualification means, but I hope that the
statement doesn't mean the forward compatibility.

I think it is fair to expect the backward compatibility in a minor
release. With a guarantee of the backward compatibility, tool
developers don't need to study all minor releases but the latest one.

After these thoughts, I have changed my mind. #2 - Restructure isn't
my choice anymore. If we all can agree to defer the reformat issue
until 2.0, Yve's #6 is a valid choice. If not, I will choose #4 -
Combined. This option allows both the backward compatibility and the
clean representation of text and meta info. Going forward a little
bit, how about deprecating <source> and <target>? So we can remove
them in 2.0 if we want.

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

Good point. To do so, the constraint on version attribute in <xliff>
must be changed to allow 1.x as well.

<xsd:attribute name="version" type="xsd:string" use="required" fixed="1.1"/>

-------------------
Shigemichi Yazawa
yazawa@globalsight.com