From the last meeting, I
had an action item to start a thread on the proposed segmentation
structure in XLIFF. Apologies this comes so late, but I'm in last
days (hours?) of a product release cycle.
At the last meeting and in the initial paper it has been suggested that
a new element be introduced to support segmentation: the
<segment> element, which is proposed to be a child of
<trans-unit>. I pointed out my opinion that introducing this new
element, and its additional hierarchy, did not substantively address
the stated objective to simplify & support the process of
re-assembling segments in their appropriate position via the skeleton
file during the building out process.
My arguments against the introduction of the new element:
- Presently, XLIFF's
<group> element along with <trans-unit>, and a number of
inline tags provides a hierarchy that can represent segments non
normatively. It's not clear how adding an additional hierarchical
layer with <segment> will simplify any aspect of the extraction
or build out process, since filter developers would have to reconcile
with the existing segmentation approach, and would have to logically
map content of trans-unit / segment hierarchy to appropriate token in
skeleton file. .
- The simplification of
resegmentaiton at the end-user level could be achieved using the
existing constructs mentioned. For example, it's not clear why an
additional <group> , somehow identified as a collection of
related segs, could not be as effective as a <trans-unit> with
<segment>. <group> permits most (and probably all the
useful ) attributes and elements as <trans-unit>..
- Language specific
segmentation rules are no better supported with a <segment>
hierarchy than without. In both cases, language specific
resegmentation of the content will probably require some modification
of the skeleton file.
- The TC has previously
agreed that the XLIFF format must remain backwards compatible across
revisions (and forwards compatible where possible). We can amend this
rule and deprecate but only if no other alternative exists. I'm
presently not at all convinced that this is the case with for
segmentation.
--
Tony Jewtushenko mailto:tony.jewtushenko@oracle.com
Principal Product Manager direct tel: +353.1.8039080
Oracle Corporation, Ireland
|