Yves, I want to make sure I understand
your view point. Based on what you suggested, it is possible for one to
have an entire chapter or book as a single *part* when pass it around in
an XLIFF file? If so, why call it a segment?
<unit id='1'>
<part>
<source>Sentence one. Sentence two. Sentence three. .... Sentence
two thousand and forty five.</source>
</part>
</unit>
Best regards,
Helena Shih Chapman
Globalization Technologies and Architecture
+1-720-396-6323 or T/L 938-6323
Waltham, Massachusetts
From:
Yves Savourel <>
To:
<>
Date:
11/01/2011 04:56 PM
Subject:
[xliff] Segmentation
as core or not
Sent by:
<>
Hi all,
To continue on the discussion whether the "segmentation" feature
is core or not:
I think Dave has an obviously valid point when saying that segmentation
is not necessarily done at the time of the extraction, and therefore we
could have un-segmented XLIFF.
But to me a "segment" is not necessarily the result of a segmentation
process it can be a "block" extracted from the original format
(as our definition states: http://wiki.oasis-open.org/xliff/OneContentModel#Definitions.2BAC8-Terminology).
So each un-segmented entry is, by nature a segment, that simply contains
potentially several sentences.
Maybe things would more clear if we think about the element <segment>
as a "part" rather than a "segment"? The Segmentation
representation addresses how to organize and manipulate such parts.
<unit id='1'>
<part>
<source>Sentence one. Sentence two.</source>
</part>
</unit>
<unit id='1'>
<part>
<source>Sentence one. </source>
</part>
<part>
<source> Sentence two.</source>
</part>
</unit>
Maybe, viewed from that angle it's more clear that such element needs to
be part of the core?
Cheers,
-ys
---------------------------------------------------------------------
To unsubscribe, e-mail:
For additional commands, e-mail:
