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: [no subject]


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
<mailto:tony.jewtushenko@oracle.com> 
Principal Product Manager      direct tel: +353.1.8039080
Oracle Corporation, Ireland

------_=_NextPart_001_01C42896.F7C38D50
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40";>

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">


<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]--><o:SmartTagType
 namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" =
name=3D"country-region"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:Palatino;
	panose-1:0 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";
	color:black;}
h1
	{margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:0in;
	page-break-after:avoid;
	font-size:16.0pt;
	font-family:Arial;}
h2
	{margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:0in;
	page-break-after:avoid;
	font-size:14.0pt;
	font-family:Arial;
	font-style:italic;}
h3
	{margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:0in;
	page-break-after:avoid;
	font-size:13.0pt;
	font-family:Arial;}
h4
	{margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:0in;
	page-break-after:avoid;
	font-size:14.0pt;
	font-family:"Times New Roman";}
h5
	{margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:0in;
	font-size:13.0pt;
	font-family:"Times New Roman";
	font-style:italic;}
h6
	{margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:0in;
	font-size:11.0pt;
	font-family:"Times New Roman";}
p.MsoListBullet, li.MsoListBullet, div.MsoListBullet
	{margin-top:0in;
	margin-right:0in;
	margin-bottom:6.0pt;
	margin-left:.5in;
	text-indent:-.25in;
	mso-list:l5 level1 lfo1;
	font-size:12.0pt;
	font-family:"Times New Roman";}
p.MsoListNumber, li.MsoListNumber, div.MsoListNumber
	{margin-top:0in;
	margin-right:0in;
	margin-bottom:6.0pt;
	margin-left:.75in;
	text-indent:-.25in;
	mso-list:l4 level1 lfo4;
	font-size:12.0pt;
	font-family:"Times New Roman";}
p.MsoListBullet2, li.MsoListBullet2, div.MsoListBullet2
	{margin-top:0in;
	margin-right:0in;
	margin-bottom:6.0pt;
	margin-left:1.0in;
	text-indent:-.25in;
	mso-list:l3 level1 lfo2;
	font-size:12.0pt;
	font-family:"Times New Roman";}
p.MsoListBullet3, li.MsoListBullet3, div.MsoListBullet3
	{margin-top:0in;
	margin-right:0in;
	margin-bottom:6.0pt;
	margin-left:.25in;
	text-indent:-.25in;
	mso-list:l2 level1 lfo3;
	font-size:12.0pt;
	font-family:"Times New Roman";}
p.MsoListNumber2, li.MsoListNumber2, div.MsoListNumber2
	{margin-top:0in;
	margin-right:0in;
	margin-bottom:6.0pt;
	margin-left:1.25in;
	text-indent:-.25in;
	mso-list:l1 level1 lfo5;
	font-size:12.0pt;
	font-family:"Times New Roman";}
p.MsoListNumber3, li.MsoListNumber3, div.MsoListNumber3
	{margin-top:0in;
	margin-right:0in;
	margin-bottom:6.0pt;
	margin-left:0in;
	text-indent:0in;
	mso-list:l0 level1 lfo6;
	font-size:12.0pt;
	font-family:"Times New Roman";}
p.MsoBodyText, li.MsoBodyText, div.MsoBodyText
	{margin-top:0in;
	margin-right:0in;
	margin-bottom:6.0pt;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
p.MsoListContinue, li.MsoListContinue, div.MsoListContinue
	{margin-top:0in;
	margin-right:0in;
	margin-bottom:6.0pt;
	margin-left:.25in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
p.MsoListContinue2, li.MsoListContinue2, div.MsoListContinue2
	{margin-top:0in;
	margin-right:0in;
	margin-bottom:6.0pt;
	margin-left:.5in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
p.MsoListContinue3, li.MsoListContinue3, div.MsoListContinue3
	{margin-top:0in;
	margin-right:0in;
	margin-bottom:6.0pt;
	margin-left:.75in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
p.MsoBlockText, li.MsoBlockText, div.MsoBlockText
	{margin-top:0in;
	margin-right:1.0in;
	margin-bottom:6.0pt;
	margin-left:1.0in;
	font-size:12.0pt;
	font-family:"Times New Roman";
	color:black;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
pre
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";
	color:black;}
p.Decision, li.Decision, div.Decision
	{margin-top:0in;
	margin-right:0in;
	margin-bottom:6.0pt;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";
	font-style:italic;}
span.ActionItem
	{font-weight:bold;}
span.Irrelevant
	{color:gray;}
p.TableHeading, li.TableHeading, div.TableHeading
	{margin-top:0in;
	margin-right:-22.5pt;
	margin-bottom:0in;
	margin-left:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:Palatino;
	color:white;
	font-weight:bold;}
span.EmailStyle33
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:-130;
	mso-list-type:simple;
	mso-list-template-ids:1625744462;}
@list l0:level1
	{mso-level-style-link:"List Number 3";
	mso-level-tab-stop:.75in;
	mso-level-number-position:left;
	margin-left:.75in;
	text-indent:-.25in;}
@list l1
	{mso-list-id:-129;
	mso-list-type:simple;
	mso-list-template-ids:-654043712;}
@list l1:level1
	{mso-level-style-link:"List Number 2";
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l2
	{mso-list-id:-126;
	mso-list-type:simple;
	mso-list-template-ids:1714176658;}
@list l2:level1
	{mso-level-number-format:bullet;
	mso-level-style-link:"List Bullet 3";
	mso-level-text:\F0B7;
	mso-level-tab-stop:.75in;
	mso-level-number-position:left;
	margin-left:.75in;
	text-indent:-.25in;
	font-family:Symbol;}
@list l3
	{mso-list-id:-125;
	mso-list-type:simple;
	mso-list-template-ids:1695963008;}
@list l3:level1
	{mso-level-number-format:bullet;
	mso-level-style-link:"List Bullet 2";
	mso-level-text:\F0B7;
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Symbol;}
@list l4
	{mso-list-id:-120;
	mso-list-type:simple;
	mso-list-template-ids:755638086;}
@list l4:level1
	{mso-level-style-link:"List Number";
	mso-level-tab-stop:.25in;
	mso-level-number-position:left;
	margin-left:.25in;
	text-indent:-.25in;}
@list l5
	{mso-list-id:-119;
	mso-list-type:simple;
	mso-list-template-ids:101851164;}
@list l5:level1
	{mso-level-number-format:bullet;
	mso-level-style-link:"List Bullet";
	mso-level-text:\F0B7;
	mso-level-tab-stop:.25in;
	mso-level-number-position:left;
	margin-left:.25in;
	text-indent:-.25in;
	font-family:Symbol;}
@list l6
	{mso-list-id:1057819233;
	mso-list-template-ids:-1595138620;}
@list l6:level1
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	text-indent:-.25in;
	mso-ansi-font-size:10.0pt;
	font-family:Symbol;}
@list l7
	{mso-list-id:1779133675;
	mso-list-type:hybrid;
	mso-list-template-ids:184969502 383303444 134807577 134807579 =
134807567 134807577 134807579 134807567 134807577 134807579;}
@list l7:level1
	{mso-level-text:"%1\)";
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body bgcolor=3Dwhite lang=3DEN-GB link=3Dblue vlink=3Dblue>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Hi =
Tony,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>=


<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Thanks for starting this =
thread.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>=


<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>In fact so far I have mainly tried =
to
focus the discussion on why segmentation support is needed (and what it =
is) and
consciously avoided discussions on how it should be implemented, until =
we have
reached a consensus that it is in fact needed. This discussion is still
ongoing, and before we have reached a conclusion there we should =
perhaps not
spend too much time and effort on discussing the actual implementation =
options.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>=


<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>The &lt;segment&gt; element I =
introduced
in the discussion document represents only one way of addressing the =
problem. I
chose this mechanism in the document because it clearly illustrates the
difference between normal XLIFF &lt;trans-unit&gt;s and the segments, =
which is
good for clearly explaining the issues. However there are of course =
many other possible
ways to accomplish this.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>=


<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Using &lt;trans-unit&gt; together =
with
special &lt;group&gt; elements is definitely an option we should look =
closer
into. However there are also a couple of drawbacks with such an =
implementation:<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:.5in;text-indent:-.25in;mso-list:l7 level1 =
lfo8'><![if !supportLists]><font
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'><span style=3D'mso-list:Ignore'>1)<font size=3D1 =
face=3D"Times New Roman"><span
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span></font></span></span></font><![endif]><font
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'>This would change the current functionality of =
&lt;trans-unit&gt;
and &lt;group&gt; from the way they work today. The introduction of new =
or
removal of some &lt;trans-unit&gt; elements and special &lt;group&gt;s =
(due to
segmentation changes) by tools processing the XLIFF file is likely to =
confuse a
filter. The filter must in that case be explicitly aware of the special =
&lt;group&gt;
and e.g. be able to treat the special &lt;group&gt; as if it were the =
original
&lt;trans-unit&gt; when merging the content with the skeleton. =
Basically the special
&lt;group&gt; has now taken on the role of the initial &lt;trans-unit&gt=
;. Would
it not be more logical and less confusing to keep the &lt;group&gt; and =
&lt;trans-unit&gt;
in their current role and meaning, and introduce a new mechanism =
explicitly for
segmentation instead?<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:.5in;text-indent:-.25in;mso-list:l7 level1 =
lfo8'><![if !supportLists]><font
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'><span style=3D'mso-list:Ignore'>2)<font size=3D1 =
face=3D"Times New Roman"><span
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span></font></span></span></font><![endif]><font
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'>If we want to allow &lt;alt-trans&gt; for the entire =
original
&lt;trans-unit&gt; that cannot be easily supported. There may be cases =
where it
could be useful to supply &lt;alt-trans&gt; both for the entire =
original &lt;trans-unit&gt;
(which could be a paragraph) and for individual segments (sentences =
inside the
paragraph). To support this we would need to allow &lt;alt-trans&gt; =
also for
&lt;group&gt;.<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:.5in;text-indent:-.25in;mso-list:l7 level1 =
lfo8'><![if !supportLists]><font
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'><span style=3D'mso-list:Ignore'>3)<font size=3D1 =
face=3D"Times New Roman"><span
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span></font></span></span></font><![endif]><font
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'>The functionality of the special &lt;group&gt; affects =
processing
of the file to such a large extent that it would make sense to =
introduce a new
element for this. Otherwise tool developers will too often need to do =
special
case processing for every &lt;group&gt; element to check for =
&#8220;special&#8221;
groups. <o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.25in'><font size=3D2 =
color=3Dnavy
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p=
></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>In any case we must to all =
possible extent
avoid that tools processing the XLIFF file (e.g. introducing =
segmentation) need
to know anything about the skeleton, since the skeleton usage is =
entirely optional
and undefined by the XLIFF standard.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>=


<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>For now I suggest we save our =
energy on the
discussion this topic until it has been concluded that we do need =
explicit segmentation
support in XLIFF.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>=


<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Cheers,<br>
Magnus<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>=


<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
color=3Dblack face=3D"Times New Roman"><span lang=3DEN-US =
style=3D'font-size:12.0pt;
color:windowtext'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 color=3Dblack =
face=3DTahoma><span lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Tahoma;color:windowtext;font-weigh=
t:bold'>From:</span></font></b><font
size=3D2 color=3Dblack face=3DTahoma><span lang=3DEN-US style=3D'font-si=
ze:10.0pt;
font-family:Tahoma;color:windowtext'> Tony Jewtushenko
[mailto:Tony.Jewtushenko@oracle.com] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Thursday, April =
15, 2004
8:02 AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> =
xliff-seg@lists.oasis-open.org<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> [xliff-seg] =
Segmentation
Structure</span></font><font color=3Dblack><span lang=3DEN-US =
style=3D'color:windowtext'><o:p></o:p></span></font></p>

</div>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial'>From the last meeting,&nbsp; I had an action =
item to
start a thread on the proposed segmentation structure in XLIFF.&nbsp; =
Apologies
this comes so late,&nbsp; but I'm in last days (hours?) of a product =
release
cycle.<br>
<br>
At the last meeting and in the initial paper it has been suggested that =
a new
element be introduced to support segmentation:&nbsp; the =
&lt;segment&gt;
element,&nbsp; which is proposed to be a child of =
&lt;trans-unit&gt;.&nbsp; I
pointed out my opinion that introducing this new element,&nbsp; and its
additional hierarchy,&nbsp; did not substantively address the stated =
objective
to simplify &amp; support the process of re-assembling segments in =
their
appropriate position via the skeleton file during the building out =
process.<br>
<br>
My arguments against the introduction of the new =
element:</span></font><o:p></o:p></p>

<ul type=3Ddisc>
 <li class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
     mso-list:l6 level1 lfo7'><font size=3D2 color=3Dblack =
face=3DArial><span
     style=3D'font-size:10.0pt;font-family:Arial'>Presently,&nbsp; =
XLIFF's
     &lt;group&gt; element along with &lt;trans-unit&gt;,&nbsp; and a =
number of
     inline tags provides a hierarchy that can represent segments non
     normatively.&nbsp; It's not clear how adding an additional =
hierarchical
     layer with &lt;segment&gt; will simplify any aspect of the
     extraction&nbsp; or build out process,&nbsp; since filter =
developers would
     have to reconcile with the existing segmentation approach,&nbsp; =
and would
     have to logically map content of trans-unit / segment hierarchy to
     appropriate token in skeleton file.&nbsp; =
.</span></font><o:p></o:p></li>
 <li class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
     mso-list:l6 level1 lfo7'><font size=3D2 color=3Dblack =
face=3DArial><span
     style=3D'font-size:10.0pt;font-family:Arial'>The simplification of
     resegmentaiton at the end-user level could be achieved using the =
existing
     constructs mentioned.&nbsp; For example,&nbsp; it's not clear why =
an
     additional &lt;group&gt; ,&nbsp; somehow identified as a =
collection of
     related segs,&nbsp; could not be as effective as a =
&lt;trans-unit&gt; with
     &lt;segment&gt;.&nbsp; &lt;group&gt; permits most (and probably =
all the
     useful ) attributes and elements as =
&lt;trans-unit&gt;..</span></font><o:p></o:p></li>
 <li class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
     mso-list:l6 level1 lfo7'><font size=3D2 color=3Dblack =
face=3DArial><span
     style=3D'font-size:10.0pt;font-family:Arial'>Language specific =
segmentation
     rules are no better supported with a &lt;segment&gt; hierarchy =
than
     without.&nbsp; In both cases,&nbsp; language specific =
resegmentation of
     the content will probably require some modification of the =
skeleton file.</span></font><o:p></o:p></li>
 <li class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
     mso-list:l6 level1 lfo7'><font size=3D2 color=3Dblack =
face=3DArial><span
     style=3D'font-size:10.0pt;font-family:Arial'>The TC has previously =
agreed
     that the XLIFF format must remain backwards compatible across =
revisions
     (and forwards compatible where possible).&nbsp; 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.</span></font><o:p></o:p></li>
</ul>

<pre cols=3D72><font size=3D2 color=3Dblack face=3D"Courier New"><span
style=3D'font-size:10.0pt'>-- <o:p></o:p></span></font></pre><pre><font =
size=3D2
color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>Tony =
Jewtushenko&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp; <a
href=3D"mailto:tony.jewtushenko@oracle.com";>mailto:tony.jewtushenko@orac=
le.com</a><o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>Principal Product =
Manager&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; direct tel: =
+353.1.8039080<o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>Oracle Corporation, <st1:country-region
w:st=3D"on"><st1:place =
w:st=3D"on">Ireland</st1:place></st1:country-region><o:p></o:p></span></=
font></pre></div>

</body>

</html>

------_=_NextPart_001_01C42896.F7C38D50--

--------------InterScan_NT_MIME_Boundary--



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