OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xliff-seg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Segmentation Structure

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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]