RE: [xliff] XLIFF 2.0 example files for segmentation

[Yves Savourel <ysavourel@enlaso.com>]

> So the scenario I pulled from Dave's example, 
> file with <segment>s is refactored as file 
> with different <segments>s but has to be 
> restored to original <segments> is a chimera.

A bad dream indeed.


> ..then Dave's example would need to lose 
> snippets two and five. Is that right?

1 and 4, and 5 is not needed. But the merger should work with either 3 or 5.


> If segmentation is moved to the translation domain
> and adjusted at translation time, aren't we saying 
> that segmentation is really a function of the import 
> filter (and hence beyond the scope of XLIFF), 
> just as it would be for any other file format? 
> I don't need to indicate segmentation in Word or 
> IDML, so what makes XLIFF different in this regard?

Well the "re-" segmentation is moved out of the extraction tool domain. But there is a block-level segmentation too: You do use it in Word and IDML: paragraphs, footnotes, table cell, etc. 
Likewise that "block"-level segmentation is done by the extraction tool: <unit> hold a "block" which initially is stored in a single <segment>.

Why use both <unit> and <segment> initially? Why not just <unit> like in David's snippets 1 and 4?

Because it's just more efficient. Maybe forget about block/sentence and see it that way: until it (optionally) gets segmented further that content is the "segment" for that unit. So why shouldn't be in <segment>?

Think about Word and pages: your content is in a single page or several: you decide where the page breaks are. Even when there are no page break there is a page. A <segment> is similar to a page.


Cheers,
-ys