Just a note on #5:
> 5/ "XLIFF 2.0 will be complete when _______"
> There are two camps for filling in the blank
>
> A. Set a calendar goal. All items that are complete and approved by the
> TC make it into XLIFF 2.0 - All others need to wait for the "next train,"
> i.e., XLIFF 2.X or XLIFF 3. Special care needs to be taken to define
> doneness and ensure no dependency issues between items.
> And "XLIFF 2.0 is complete on set date of *Month/Day/Year*"
>
> - or -
>
> B. Define a finite set of XLIFF 2.0 items. Set a cutoff date for adding items.
> The list of accepted items becomes our requirements document.
> And "XLIFF 2.0 is complete when items 1 through X are finished"
> (some in this camp see our current set of goals, as is, as that
> finite list)
Since I was not in the TC when these requirements were defined I don't feel I can guess which method is the best.
But I wanted to say that XLIFF is not a software. And we should be careful with releasing versions that do not have some specific features we know will ultimately end up there. Once out, files in that version build up a legacy that is not easy to "update" like versions of software. So I would be inclined to take more time if needed, to get maybe fewer versions but better ones. The same goes for any standard formats.
-ys
