RE: [xliff] Reference implementations for XLIFF 2.0

[Yves Savourel <ysavourel@enlaso.com>]

Hi Kevin, Bryan, David, all,

> 1. Only publish modules in 2.0 that have been proven 
> and implemented; anything not implemented would be cut 
> 2. Ask 3 implementers to supply simple proofs of their
> implementation of XLIFF 2.0 (loosely defined) – i.e. 
> meet the minimum requirements for OASIS 
> 3. Wait until all modules have been provable implemented 
> and delay XLIFF 2.0 publication until such time

With the flurry of changes I'm seeing after this first public review I think there is a need to ensure our specification is validated by some implementations.

The requirements set by OASIS are, in my opinion, rather weak: Letting the TC decide what constitutes an acceptable Statement Of Use is rather funny. It's like letting a student grad his own exam paper.

I would expect to have each conformance clause met by, at least, one implementation (and it could be different implementations).

Ideally I would really like to see each clause covered by, at least, two to prove/test interoperability. But one would be better than none.


> ...while Option 3 risks delaying XLIFF 2.0 significantly.
> For option 2, there is a risk that some implementation 
> detail in XLIFF 2.0 will not be caught prior to publication,
> but I believe that is better addressed in a future XLIFF
> 2.1 version.

There is option 4: Drop the module(s) that don't met the implementation requirements.
That won't delay XLIFF 2.0 at all.

Instead of risking the mess of having to fix implementations details in 2.1, 2.2, etc. why not get it right when it's implementation-tested?

The requirement would also include the core. But if we can't cover each conformance clause of the core by at least one implementation, we probably shouldn't be publishing 2.0 yet.

Just my 2 cents.
Cheers,
-yves