Hi David,
> The product developer would expect to get this translated
> file back after translation, which maps to the version
> of the XLIFF file which he sent out for translation.
> ...
> Are these realistic examples?
Not the last part in my opinion.
In you scenario it feels like there are two distinct file formats: one without <segment> that is fine for core-only tools, and one with <segment> that works only with tool that implement an optional the segmentation representation.
But core-only tools must be able to work even when optional modules are used in the document.
And it seems your scenario assume it's not the case: the product developer expects that the file to merge must have its segmentation representation removed to be able to work.
A realistic scenario, in my opinion, would be for the third file (translated and sentence-segmented) to come back to the product developer. And the merging tool should be able to work with it.
In that scenario you then have only two solutions:
A) <segment> is part of the core.
Or B) sentence-segmentation representation need to be coded completely differently so a tool that would not understand it would still work. But the example with the <source> sometime at the <unit> level and sometime at the <segment> level, is not really workable as Rodolfo pointed out. The only thing that could work for B would be something like in v1.2 where there is a copy of the content. And that would lead back to many of the issues we are trying hard to get rid of in 2.0.
I think for the many reasons already mentioned the solution A is vastly preferable.
Cheers,
-yves
