OASIS XML Localisation Interchange File Format (XLIFF) TC

Hi,   Here is my attempt at wording for the default value of the ’order’ attribute on <target> elements. The change makes the default behavior easy to understand and also adds a constraint that enforces that order must be set on multiple targets when reordering. It is however not necessary to specify it on all targets all the time, for example when swapping the order of two targets other targets may be left at the undefined state.   ----- New Wording ----- 4.3.1.24 order target order - indicates the order, in which to compose the target content parts. Value description: A positive integer.   Default value: undefined When order is undefined the <target> corresponds to the <source> of its parent element.   Used in: <target> .   Constraints • The value of the order attribute MUST be unique within the enclosing <unit> element unless left undefined. • When order is specified on one <target> , it MUST also be specified on other <target> s in the <unit> such that each <source>  has at most one corresponding <target> after resolving the order for all <target> s in the <unit> .   See the Segments Order section for the normative usage description.   ----- Current wording -----   4.3.1.24 order target order - indicates the order, in which to compose the target content parts. Value description: A positive integer.   Default value: undefined   Used in: <target> .   Constraints • The value of the order attribute MUST be unique within the enclosing <unit> element. See the Segments Order section for the normative usage description.   ----- end -----   Regards, Fredrik Estreen

Hi everyone,   I think Fredrik’s additional sentence for the default value is quite good and clear.   For the additional constraint however, I’m not sure we can/want do this at this stage. Adding a constraint is likely to be seen as a major change rather than just editorial one.   Cheers, -yves   From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Estreen, Fredrik Sent: Tuesday, June 17, 2014 2:34 AM To: xliff@lists.oasis-open.org Subject: [xliff] cos-301 proposed changed text   Hi,   Here is my attempt at wording for the default value of the ’order’ attribute on <target> elements. The change makes the default behavior easy to understand and also adds a constraint that enforces that order must be set on multiple targets when reordering. It is however not necessary to specify it on all targets all the time, for example when swapping the order of two targets other targets may be left at the undefined state.   ----- New Wording ----- 4.3.1.24 order target order - indicates the order, in which to compose the target content parts. Value description: A positive integer.   Default value: undefined When order is undefined the <target> corresponds to the <source> of its parent element.   Used in: <target> .   Constraints • The value of the order attribute MUST be unique within the enclosing <unit> element unless left undefined. • When order is specified on one <target> , it MUST also be specified on other <target> s in the <unit> such that each <source>  has at most one corresponding <target> after resolving the order for all <target> s in the <unit> .   See the Segments Order section for the normative usage description.   ----- Current wording -----   4.3.1.24 order target order - indicates the order, in which to compose the target content parts. Value description: A positive integer.   Default value: undefined   Used in: <target> .   Constraints • The value of the order attribute MUST be unique within the enclosing <unit> element. See the Segments Order section for the normative usage description.   ----- end -----   Regards, Fredrik Estreen

Hi Yves, All   I was worried that that might be the case (the constraint). Perhaps we should put that on the backlog for 2.1 instead. The segment order does not make sense without such a constraint though.   Would it be more acceptable to add a sentence to the end of the section describing the segment order. The section is normative so should technically be as important as a constraint, but perhaps adding a sentence to that paragraph is less of a change than adding a new constraint.   4.8.2 Segments Order Some Agents (e.g. aligner tools) can segment content, so that the target segments are not in the same order as the source segments. To be able to map order differences, the <target> element has an OPTIONAL order attribute that indicates its position in the sequence of segments (and inter-segments). Its value is an integer from 1 to N, where N is the sum of the numbers of the <segment> and <ignorable> elements within the given enclosing <unit> element. A <source> element MUST never be related to more than one <target> element regardless of reordering.     Regards, Fredrik Estreen From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Yves Savourel Sent: den 17 juni 2014 15:13 To: xliff@lists.oasis-open.org Subject: RE: [xliff] cos-301 proposed changed text   Hi everyone,   I think Fredrik’s additional sentence for the default value is quite good and clear.   For the additional constraint however, I’m not sure we can/want do this at this stage. Adding a constraint is likely to be seen as a major change rather than just editorial one.   Cheers, -yves   From: xliff@lists.oasis-open.org [ mailto:xliff@lists.oasis-open.org ] On Behalf Of Estreen, Fredrik Sent: Tuesday, June 17, 2014 2:34 AM To: xliff@lists.oasis-open.org Subject: [xliff] cos-301 proposed changed text   Hi,   Here is my attempt at wording for the default value of the ’order’ attribute on <target> elements. The change makes the default behavior easy to understand and also adds a constraint that enforces that order must be set on multiple targets when reordering. It is however not necessary to specify it on all targets all the time, for example when swapping the order of two targets other targets may be left at the undefined state.   ----- New Wording ----- 4.3.1.24 order target order - indicates the order, in which to compose the target content parts. Value description: A positive integer.   Default value: undefined When order is undefined the <target> corresponds to the <source> of its parent element.   Used in: <target> .   Constraints • The value of the order attribute MUST be unique within the enclosing <unit> element unless left undefined. • When order is specified on one <target> , it MUST also be specified on other <target> s in the <unit> such that each <source>  has at most one corresponding <target> after resolving the order for all <target> s in the <unit> .   See the Segments Order section for the normative usage description.   ----- Current wording -----   4.3.1.24 order target order - indicates the order, in which to compose the target content parts. Value description: A positive integer.   Default value: undefined   Used in: <target> .   Constraints • The value of the order attribute MUST be unique within the enclosing <unit> element. See the Segments Order section for the normative usage description.   ----- end -----   Regards, Fredrik Estreen

I agree with Yves assessment,  we cannot afford to insert a new constraint. We could insert a warning. But the former part seems fine. It actually leaves the default undefined but gives a clear hint how to determine missing values. We can slate such a constraint for 2.1 or errata. I will tentatively implement an editorial solution based on this later this week and will call for dissent. Cheers dF dF is AFK, so please bear with the typos and call me at +353860222158 if my answer seems insufficient.. On Jun 17, 2014 2:12 PM, "Yves Savourel" < ysavourel@enlaso.com > wrote: Hi everyone,   I think Fredrik’s additional sentence for the default value is quite good and clear.   For the additional constraint however, I’m not sure we can/want do this at this stage. Adding a constraint is likely to be seen as a major change rather than just editorial one.   Cheers, -yves   From: xliff@lists.oasis-open.org [mailto: xliff@lists.oasis-open.org ] On Behalf Of Estreen, Fredrik Sent: Tuesday, June 17, 2014 2:34 AM To: xliff@lists.oasis-open.org Subject: [xliff] cos-301 proposed changed text   Hi,   Here is my attempt at wording for the default value of the ’order’ attribute on <target> elements. The change makes the default behavior easy to understand and also adds a constraint that enforces that order must be set on multiple targets when reordering. It is however not necessary to specify it on all targets all the time, for example when swapping the order of two targets other targets may be left at the undefined state.   ----- New Wording ----- 4.3.1.24 order target order - indicates the order, in which to compose the target content parts. Value description: A positive integer.   Default value: undefined When order is undefined the <target> corresponds to the <source> of its parent element.   Used in: <target> .   Constraints • The value of the order attribute MUST be unique within the enclosing <unit> element unless left undefined. • When order is specified on one <target> , it MUST also be specified on other <target> s in the <unit> such that each <source>  has at most one corresponding <target> after resolving the order for all <target> s in the <unit> .   See the Segments Order section for the normative usage description.   ----- Current wording -----   4.3.1.24 order target order - indicates the order, in which to compose the target content parts. Value description: A positive integer.   Default value: undefined   Used in: <target> .   Constraints • The value of the order attribute MUST be unique within the enclosing <unit> element. See the Segments Order section for the normative usage description.   ----- end -----   Regards, Fredrik Estreen

+1
 
From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org]
On Behalf Of David Filip
Sent: Tuesday, June 17, 2014 6:48 AM
To: Yves Savourel
Cc: xliff@lists.oasis-open.org
Subject: RE: [xliff] cos-301 proposed changed text
 
I agree with Yves assessment,  we cannot afford to insert a new constraint. We could insert a warning. But the former part seems fine.
It actually leaves the default undefined but gives a clear hint how to determine missing values.

We can slate such a constraint for 2.1 or errata.
I will tentatively implement an editorial solution based on this later this week and will call for dissent.

Cheers
dF
dF is AFK, so please bear with the typos and call me at +353860222158 if my answer seems insufficient..

On Jun 17, 2014 2:12 PM, "Yves Savourel" < ysavourel@enlaso.com > wrote:


Hi everyone,
 
I think Fredrik’s additional sentence for the default value is quite good and clear.
 
For the additional constraint however, I’m not sure we can/want do this at this stage.
Adding a constraint is likely to be seen as a major change rather than just editorial one.
 
Cheers,
-yves
 


From:
xliff@lists.oasis-open.org [mailto: xliff@lists.oasis-open.org ]
On Behalf Of Estreen, Fredrik
Sent: Tuesday, June 17, 2014 2:34 AM
To: xliff@lists.oasis-open.org
Subject: [xliff] cos-301 proposed changed text


 
Hi,
 
Here is my attempt at wording for the default value of the ’order’ attribute on <target> elements. The change makes the default behavior easy to understand and also adds a constraint
that enforces that order must be set on multiple targets when reordering. It is however not necessary to specify it on all targets all the time, for example when swapping the order of two targets other targets may be left at the undefined state.
 
----- New Wording -----

4.3.1.24 order

target order - indicates the order, in which to compose the target content parts.

Value description: A positive integer.

 

Default value: undefined

When order is undefined the
<target>
corresponds to the
<source> of its parent element.

 

Used in:
<target> .

 

Constraints

• The value of the
order
attribute MUST be unique within the enclosing
<unit>
element unless left undefined.

• When
order is specified on one
<target> , it MUST also be specified on other
<target> s in the
<unit> such that each
<source>  has at most one corresponding
<target>
after resolving the order for all
<target> s in the
<unit> .

 
See the
Segments Order
section for the normative usage description.
 
----- Current wording
-----
 

4.3.1.24 order

target order - indicates the order, in which to compose the target content parts.

Value description: A positive integer.

 

Default value: undefined

 

Used in:
<target> .

 

Constraints

• The value of the
order
attribute MUST be unique within the enclosing
<unit>
element.
See the
Segments Order
section for the normative usage description.
 
----- end
-----
 
Regards,
Fredrik Estreen

Hi everyone, I was attempting to implement an editorial solution to this as promised. However, I see only now that Fredrik's proposal actually changes the current behavior. Let me summarize the mechanics of the intended behavior as I understand it. I believe that currently it is possible to explicitly set order only on some targets. I see that Fredrik's additional Constraint aimed to prohibit this.  While it might have been generally a good design idea. I do not think that we can introduce it now. Currently I believe it is possible to specify order as follows <unit>  <segment>   <source>source1</source>   <target>target1</target>  </segment>  <segment>   <source>source2</source>   <target>target2</target>  </segment>  <segment>   <source>source3</source>   <target order="1">target3</target>  </segment> </unit> In the above target3 corresponds to source1 , target1 to source2, and target2 to source3. This would be illegal after the change proposed by Fredrik. I believe that we must base the solution on the constraints and other normative text that currently is in the cos01 not endanger the progression to cos02 and finally os01. The Constraint on the order attribute itself requires uniqueness of the order attribute values within a unit. The normative usage description ( 4.8.2 Segments Order)  says that the value must be between 1 and N, where N is the summary number of segments and ingnorables within the unit. From the above it follows that there must be bidirectional mapping between all sources and all targets. So there is no other reason than convenience (which would have been valid were we not in the cos01 stage) to REQUIRE that all targets have the order value set explicitly once one of the targets has it set. If all agree with the above interpretation of the current state and intent of the cos01 text. I believe that the editorial solution should be as follows: ----- New Wording ----- 4.3.1.24 order target order - indicates the order, in which to compose the target content parts. Value description: A positive integer.   Default value: implicit, see below When order is not  explicitly  set on any of the  <target>  elements of the enclosing <unit> element, each <target> element corresponds to the  <source>  element of its parent element. When at at least one <target> element has the order attribute value set explicitly, all <target> elements with set order values correspond to the <source> elements whose order is naturally designated by the set order values. The remaining implicit values (if any) correspond to implicit ordinals of the remaining (if any) <source> elements, i.e. those that have had no <target> elements assigned by explicit order attribute values.  [I am fully aware that the above language is awkward and complicated, so improvement ideas are welcome.]  Example: [a valid example similar to the pseudo-code above, showing how tragets are shifted along the remaining free values] Used in:  <target> .   Constraints • The explicit values of the  order  attribute MUST be unique within the enclosing  <unit>  element.   See the  Segments Order  section for the normative usage description.   -----  Current wording  -----   4.3.1.24 order target order - indicates the order, in which to compose the target content parts. Value description: A positive integer.   Default value: undefined   Used in:  <target> .   Constraints • The value of the  order  attribute MUST be unique within the enclosing  <unit>  element. See the  Segments Order  section for the normative usage description.   -----  end  ----- I am not making a CFD at this point as the above does not seem stable. Improvement ideas welcome dF Dr. David Filip ======================= LRC CNGL LT-Web CSIS University of Limerick, Ireland telephone: +353-6120-2781 cellphone: +353-86-0222-158 facsimile: +353-6120-2734 http://www.cngl.ie/profile/?i=452 mailto: david.filip@ul.ie On Tue, Jun 17, 2014 at 6:35 PM, Schnabel, Bryan S < bryan.s.schnabel@tektronix.com > wrote: +1   From: xliff@lists.oasis-open.org [mailto: xliff@lists.oasis-open.org ] On Behalf Of David Filip Sent: Tuesday, June 17, 2014 6:48 AM To: Yves Savourel Cc: xliff@lists.oasis-open.org Subject: RE: [xliff] cos-301 proposed changed text   I agree with Yves assessment,  we cannot afford to insert a new constraint. We could insert a warning. But the former part seems fine. It actually leaves the default undefined but gives a clear hint how to determine missing values. We can slate such a constraint for 2.1 or errata. I will tentatively implement an editorial solution based on this later this week and will call for dissent. Cheers dF dF is AFK, so please bear with the typos and call me at +353860222158 if my answer seems insufficient.. On Jun 17, 2014 2:12 PM, "Yves Savourel" < ysavourel@enlaso.com > wrote: Hi everyone,   I think Fredrik’s additional sentence for the default value is quite good and clear.   For the additional constraint however, I’m not sure we can/want do this at this stage. Adding a constraint is likely to be seen as a major change rather than just editorial one.   Cheers, -yves   From: xliff@lists.oasis-open.org [mailto: xliff@lists.oasis-open.org ] On Behalf Of Estreen, Fredrik Sent: Tuesday, June 17, 2014 2:34 AM To: xliff@lists.oasis-open.org Subject: [xliff] cos-301 proposed changed text   Hi,   Here is my attempt at wording for the default value of the ’order’ attribute on <target> elements. The change makes the default behavior easy to understand and also adds a constraint that enforces that order must be set on multiple targets when reordering. It is however not necessary to specify it on all targets all the time, for example when swapping the order of two targets other targets may be left at the undefined state.   ----- New Wording ----- 4.3.1.24 order target order - indicates the order, in which to compose the target content parts. Value description: A positive integer.   Default value: undefined When order is undefined the <target> corresponds to the <source> of its parent element.   Used in: <target> .   Constraints • The value of the order attribute MUST be unique within the enclosing <unit> element unless left undefined. • When order is specified on one <target> , it MUST also be specified on other <target> s in the <unit> such that each <source>  has at most one corresponding <target> after resolving the order for all <target> s in the <unit> .   See the Segments Order section for the normative usage description.   ----- Current wording -----   4.3.1.24 order target order - indicates the order, in which to compose the target content parts. Value description: A positive integer.   Default value: undefined   Used in: <target> .   Constraints • The value of the order attribute MUST be unique within the enclosing <unit> element. See the Segments Order section for the normative usage description.   ----- end -----   Regards, Fredrik Estreen

I am in agreement. One note regarding timing, we are precious few weeks away from the ballot. If anyone has a suggestion to clarify the wording the time is now to please make your comment. I think we can take suggestions until the end of the week at the very latest. But I would prefer to close on this sooner. We must come to stability well ahead of the opening of the ballot in early July. Thanks, Bryan ________________________________ From: Dr. David Filip [David.Filip@ul.ie] Sent: Tuesday, June 24, 2014 6:11 AM To: Schnabel, Bryan S; Yves Savourel; xliff@lists.oasis-open.org; Estreen, Fredrik Subject: Re: [xliff] cos-301 proposed changed text Hi everyone, I was attempting to implement an editorial solution to this as promised. However, I see only now that Fredrik's proposal actually changes the current behavior. Let me summarize the mechanics of the intended behavior as I understand it. I believe that currently it is possible to explicitly set order only on some targets. I see that Fredrik's additional Constraint aimed to prohibit this. While it might have been generally a good design idea. I do not think that we can introduce it now. Currently I believe it is possible to specify order as follows <unit> <segment> <source>source1</source> <target>target1</target> </segment> <segment> <source>source2</source> <target>target2</target> </segment> <segment> <source>source3</source> <target order="1">target3</target> </segment> </unit> In the above target3 corresponds to source1 , target1 to source2, and target2 to source3. This would be illegal after the change proposed by Fredrik. I believe that we must base the solution on the constraints and other normative text that currently is in the cos01 not endanger the progression to cos02 and finally os01. The Constraint on the order attribute itself requires uniqueness of the order attribute values within a unit. The normative usage description (4.8.2 Segments Order) says that the value must be between 1 and N, where N is the summary number of segments and ingnorables within the unit. From the above it follows that there must be bidirectional mapping between all sources and all targets. So there is no other reason than convenience (which would have been valid were we not in the cos01 stage) to REQUIRE that all targets have the order value set explicitly once one of the targets has it set. If all agree with the above interpretation of the current state and intent of the cos01 text. I believe that the editorial solution should be as follows: ----- New Wording ----- 4.3.1.24 order target order - indicates the order, in which to compose the target content parts. Value description: A positive integer. Default value: implicit, see below When order is not explicitly set on any of the <target> elements of the enclosing <unit> element, each <target> element corresponds to the <source> element of its parent element. When at at least one <target> element has the order attribute value set explicitly, all <target> elements with set order values correspond to the <source> elements whose order is naturally designated by the set order values. The remaining implicit values (if any) correspond to implicit ordinals of the remaining (if any) <source> elements, i.e. those that have had no <target> elements assigned by explicit order attribute values. [I am fully aware that the above language is awkward and complicated, so improvement ideas are welcome.] Example: [a valid example similar to the pseudo-code above, showing how tragets are shifted along the remaining free values] Used in: <target>. Constraints • The explicit values of the order attribute MUST be unique within the enclosing <unit> element. See the Segments Order section for the normative usage description. ----- Current wording ----- 4.3.1.24 order target order - indicates the order, in which to compose the target content parts. Value description: A positive integer. Default value: undefined Used in: <target>. Constraints • The value of the order attribute MUST be unique within the enclosing <unit> element. See the Segments Order section for the normative usage description. ----- end ----- I am not making a CFD at this point as the above does not seem stable. Improvement ideas welcome dF Dr. David Filip ======================= LRC CNGL LT-Web CSIS University of Limerick, Ireland telephone: +353-6120-2781 cellphone: +353-86-0222-158 facsimile: +353-6120-2734 http://www.cngl.ie/profile/?i=452 mailto: david.filip@ul.ie< mailto:david.filip@ul.ie > On Tue, Jun 17, 2014 at 6:35 PM, Schnabel, Bryan S <bryan.s.schnabel@tektronix.com< mailto:bryan.s.schnabel@tektronix.com >> wrote: +1 From: xliff@lists.oasis-open.org< mailto:xliff@lists.oasis-open.org > [ mailto:xliff@lists.oasis-open.org < mailto:xliff@lists.oasis-open.org >] On Behalf Of David Filip Sent: Tuesday, June 17, 2014 6:48 AM To: Yves Savourel Cc: xliff@lists.oasis-open.org< mailto:xliff@lists.oasis-open.org > Subject: RE: [xliff] cos-301 proposed changed text I agree with Yves assessment, we cannot afford to insert a new constraint. We could insert a warning. But the former part seems fine. It actually leaves the default undefined but gives a clear hint how to determine missing values. We can slate such a constraint for 2.1 or errata. I will tentatively implement an editorial solution based on this later this week and will call for dissent. Cheers dF dF is AFK, so please bear with the typos and call me at +353860222158<tel:%2B353860222158> if my answer seems insufficient.. On Jun 17, 2014 2:12 PM, "Yves Savourel" <ysavourel@enlaso.com< mailto:ysavourel@enlaso.com >> wrote: Hi everyone, I think Fredrik’s additional sentence for the default value is quite good and clear. For the additional constraint however, I’m not sure we can/want do this at this stage. Adding a constraint is likely to be seen as a major change rather than just editorial one. Cheers, -yves From: xliff@lists.oasis-open.org< mailto:xliff@lists.oasis-open.org > [ mailto:xliff@lists.oasis-open.org < mailto:xliff@lists.oasis-open.org >] On Behalf Of Estreen, Fredrik Sent: Tuesday, June 17, 2014 2:34 AM To: xliff@lists.oasis-open.org< mailto:xliff@lists.oasis-open.org > Subject: [xliff] cos-301 proposed changed text Hi, Here is my attempt at wording for the default value of the ’order’ attribute on <target> elements. The change makes the default behavior easy to understand and also adds a constraint that enforces that order must be set on multiple targets when reordering. It is however not necessary to specify it on all targets all the time, for example when swapping the order of two targets other targets may be left at the undefined state. ----- New Wording ----- 4.3.1.24 order target order - indicates the order, in which to compose the target content parts. Value description: A positive integer. Default value: undefined When order is undefined the <target> corresponds to the <source> of its parent element. Used in: <target>. Constraints • The value of the order attribute MUST be unique within the enclosing <unit> element unless left undefined. • When order is specified on one <target>, it MUST also be specified on other <target>s in the <unit> such that each <source> has at most one corresponding <target> after resolving the order for all <target>s in the <unit>. See the Segments Order section for the normative usage description. ----- Current wording ----- 4.3.1.24 order target order - indicates the order, in which to compose the target content parts. Value description: A positive integer. Default value: undefined Used in: <target>. Constraints • The value of the order attribute MUST be unique within the enclosing <unit> element. See the Segments Order section for the normative usage description. ----- end ----- Regards, Fredrik Estreen

Hi Bryan, David, I think if we cannot have the semantics of my original wording we will need to go for a more complex description of the default value, there is probably no easy way to explain it. It will also not be something we can fix in 2.x but rather how things will be for the 2 series of XLIFF. Changing it would materially impact the interpretation of documents so a no go for a minor version. Here is a cut at alternative wording that should mean the same thing as the wording David provided. But breaking out the special case of no order attributes at all into a note. Value description: A positive integer Default value: Form a consecutive series of integers starting at one and ending at inclusively at the total number of <segment> and <ignorable> elements in the <unit>. Next for each target with an explicit order attribute remove the corresponding integer from the series obtained in the previous step. Last iterate over all <segment> and <ignorable> elements in the unit and if it has no target or a target without explicit order remove the first number in the series, if the element has a <target> element without an order attribute this number is the implicit default value for that <target> elements order attribute. Note on default value: If no <target> in a unit has an explicit order attribute the calculation of order can be skipped as each <target> appears in the same order as the <source> of its parent element. Regards, Fredrik Estreen >
Original Message----- > From: xliff@lists.oasis-open.org [ mailto:xliff@lists.oasis-open.org ] On Behalf > Of Schnabel, Bryan S > Sent: den 24 juni 2014 15:53 > To: Dr. David Filip; Yves Savourel; xliff@lists.oasis-open.org; Estreen, Fredrik > Subject: RE: [xliff] cos-301 proposed changed text > > I am in agreement. > > One note regarding timing, we are precious few weeks away from the ballot. > If anyone has a suggestion to clarify the wording the time is now to please > make your comment. I think we can take suggestions until the end of the > week at the very latest. But I would prefer to close on this sooner. We must > come to stability well ahead of the opening of the ballot in early July. > > Thanks, > > Bryan > ________________________________ > From: Dr. David Filip [David.Filip@ul.ie] > Sent: Tuesday, June 24, 2014 6:11 AM > To: Schnabel, Bryan S; Yves Savourel; xliff@lists.oasis-open.org; Estreen, > Fredrik > Subject: Re: [xliff] cos-301 proposed changed text > > Hi everyone, I was attempting to implement an editorial solution to this as > promised. > However, I see only now that Fredrik's proposal actually changes the current > behavior. > > Let me summarize the mechanics of the intended behavior as I understand > it. > > I believe that currently it is possible to explicitly set order only on some > targets. > > I see that Fredrik's additional Constraint aimed to prohibit this. > > While it might have been generally a good design idea. I do not think that we > can introduce it now. > > Currently I believe it is possible to specify order as follows > > <unit> > <segment> > <source>source1</source> > <target>target1</target> > </segment> > <segment> > <source>source2</source> > <target>target2</target> > </segment> > <segment> > <source>source3</source> > <target order="1">target3</target> > </segment> > </unit> > > In the above > target3 corresponds to source1 , target1 to source2, and target2 to source3. > > This would be illegal after the change proposed by Fredrik. > > > I believe that we must base the solution on the constraints and other > normative text that currently is in the cos01 not endanger the progression to > cos02 and finally os01. > > > The Constraint on the order attribute itself requires uniqueness of the order > attribute values within a unit. > > The normative usage description (4.8.2 Segments Order) > > says that the value must be between 1 and N, where N is the summary > number of segments and ingnorables within the unit. > > From the above it follows that there must be bidirectional mapping between > all sources and all targets. > > So there is no other reason than convenience (which would have been valid > were we not in the cos01 stage) to REQUIRE that all targets have the order > value set explicitly once one of the targets has it set. > > If all agree with the above interpretation of the current state and intent of > the cos01 text. > > I believe that the editorial solution should be as follows: > > ----- New Wording ----- > 4.3.1.24 order > target order - indicates the order, in which to compose the target content > parts. > Value description: A positive integer. > > Default value: implicit, see below > When order is not explicitly set on any of the <target> elements of the > enclosing <unit> element, each <target> element corresponds to the > <source> element of its parent element. > When at at least one <target> element has the order attribute value set > explicitly, all <target> elements with set order values correspond to the > <source> elements whose order is naturally designated by the set order > values. The remaining implicit values (if any) correspond to implicit ordinals of > the remaining (if any) <source> elements, i.e. those that have had no > <target> elements assigned by explicit order attribute values. > > [I am fully aware that the above language is awkward and complicated, so > improvement ideas are welcome.] > > Example: > [a valid example similar to the pseudo-code above, showing how tragets are > shifted along the remaining free values] > > Used in: <target>. > > Constraints > * The explicit values of the order attribute MUST be unique within the > enclosing <unit> element. > > See the Segments Order section for the normative usage description. > > ----- Current wording ----- > > 4.3.1.24 order > target order - indicates the order, in which to compose the target content > parts. > Value description: A positive integer. > > Default value: undefined > > Used in: <target>. > > Constraints > * The value of the order attribute MUST be unique within the enclosing > <unit> element. > See the Segments Order section for the normative usage description. > > ----- end ----- > > I am not making a CFD at this point as the above does not seem stable. > > Improvement ideas welcome > dF > > > Dr. David Filip > ======================= > LRC CNGL LT-Web CSIS > University of Limerick, Ireland > telephone: +353-6120-2781 > cellphone: +353-86-0222-158 > facsimile: +353-6120-2734 > http://www.cngl.ie/profile/?i=452 > mailto: david.filip@ul.ie< mailto:david.filip@ul.ie > > > > On Tue, Jun 17, 2014 at 6:35 PM, Schnabel, Bryan S > <bryan.s.schnabel@tektronix.com< mailto:bryan.s.schnabel@tektronix.com > > > wrote: > +1 > > From: xliff@lists.oasis-open.org< mailto:xliff@lists.oasis-open.org > > [ mailto:xliff@lists.oasis-open.org < mailto:xliff@lists.oasis-open.org >] On > Behalf Of David Filip > Sent: Tuesday, June 17, 2014 6:48 AM > To: Yves Savourel > Cc: xliff@lists.oasis-open.org< mailto:xliff@lists.oasis-open.org > > Subject: RE: [xliff] cos-301 proposed changed text > > > I agree with Yves assessment, we cannot afford to insert a new constraint. > We could insert a warning. But the former part seems fine. > It actually leaves the default undefined but gives a clear hint how to > determine missing values. > We can slate such a constraint for 2.1 or errata. > I will tentatively implement an editorial solution based on this later this week > and will call for dissent. > Cheers > dF > > dF is AFK, so please bear with the typos and call me at > +353860222158<tel:%2B353860222158> if my answer seems insufficient.. > On Jun 17, 2014 2:12 PM, "Yves Savourel" > <ysavourel@enlaso.com< mailto:ysavourel@enlaso.com >> wrote: > Hi everyone, > > I think Fredrik's additional sentence for the default value is quite good and > clear. > > For the additional constraint however, I'm not sure we can/want do this at > this stage. > Adding a constraint is likely to be seen as a major change rather than just > editorial one. > > Cheers, > -yves > > From: xliff@lists.oasis-open.org< mailto:xliff@lists.oasis-open.org > > [ mailto:xliff@lists.oasis-open.org < mailto:xliff@lists.oasis-open.org >] On > Behalf Of Estreen, Fredrik > Sent: Tuesday, June 17, 2014 2:34 AM > To: xliff@lists.oasis-open.org< mailto:xliff@lists.oasis-open.org > > Subject: [xliff] cos-301 proposed changed text > > Hi, > > Here is my attempt at wording for the default value of the 'order' attribute > on <target> elements. The change makes the default behavior easy to > understand and also adds a constraint that enforces that order must be set > on multiple targets when reordering. It is however not necessary to specify it > on all targets all the time, for example when swapping the order of two > targets other targets may be left at the undefined state. > > ----- New Wording ----- > 4.3.1.24 order > target order - indicates the order, in which to compose the target content > parts. > Value description: A positive integer. > > Default value: undefined > When order is undefined the <target> corresponds to the <source> of its > parent element. > > Used in: <target>. > > Constraints > * The value of the order attribute MUST be unique within the enclosing > <unit> element unless left undefined. > * When order is specified on one <target>, it MUST also be specified on > other <target>s in the <unit> such that each <source> has at most one > corresponding <target> after resolving the order for all <target>s in the > <unit>. > > See the Segments Order section for the normative usage description. > > ----- Current wording ----- > > 4.3.1.24 order > target order - indicates the order, in which to compose the target content > parts. > Value description: A positive integer. > > Default value: undefined > > Used in: <target>. > > Constraints > * The value of the order attribute MUST be unique within the enclosing > <unit> element. > See the Segments Order section for the normative usage description. > > ----- end ----- > > Regards, > Fredrik Estreen > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis- > open.org/apps/org/workgroup/portal/my_workgroups.php

Thanks, Fredrik, I can see that we agree what is the current semantics and that it cannot be changed. This is good for cos01 and cos2->os01. You are most probably right that we cannot introduce the tighter interpretation you proposed even in another minor version. Anyways, this might be discussed later on during work on 2.1 Actually the cases with *all* order attributes set and *no* set are just special cases of the general semantics. So if there was a strong industry drive for the special cases and removing the generalized option, it might be a valid minor version change after all. Now I see that what you propose is an algorithm but does not seem clearer to me. This said, I can see the advantage of having the simplified special case handled in a note. I will try and create another version with the special case broken out. Despite the difficulties with properly describing the implicit value behavior I believe that the semantics is sound and workable. I hope that we will have a CFD stable text by the end of this week as Bryan suggested. Would someone please volunteer and make a valid example of that behavior so that I can add it to the spec along with the new description. Thanks for your attention and cheers dF Dr. David Filip ======================= LRC CNGL LT-Web CSIS University of Limerick, Ireland telephone: +353-6120-2781 cellphone: +353-86-0222-158 facsimile: +353-6120-2734 http://www.cngl.ie/profile/?i=452 mailto: david.filip@ul.ie On Tue, Jun 24, 2014 at 4:49 PM, Estreen, Fredrik < Fredrik.Estreen@lionbridge.com > wrote: Hi Bryan, David, I think if we cannot have the semantics of my original wording we will need to go for a more complex description of the default value, there is probably no easy way to explain it. It will also not be something we can fix in 2.x but rather how things will be for the 2 series of XLIFF. Changing it would materially impact the interpretation of documents so a no go for a minor version. Here is a cut at alternative wording that should mean the same thing as the wording David provided. But breaking out the special case of no order attributes at all into a note. Value description: A positive integer Default value: Form a consecutive series of integers starting at one and ending at inclusively at the total number of <segment> and <ignorable> elements in the <unit>. Next for each target with an explicit order attribute remove the corresponding integer from the series obtained in the previous step. Last iterate over all <segment> and <ignorable> elements in the unit and if it has no target or a target without explicit order remove the first number in the series, if the element has a <target> element without an order attribute this number is the implicit default value for that <target> elements order attribute. Note on default value: If no <target> in a unit has an explicit order attribute the calculation of order can be skipped as each <target> appears in the same order as the <source> of its parent element. Regards, Fredrik Estreen >
Original Message----- > From: xliff@lists.oasis-open.org [mailto: xliff@lists.oasis-open.org ] On Behalf > Of Schnabel, Bryan S > Sent: den 24 juni 2014 15:53 > To: Dr. David Filip; Yves Savourel; xliff@lists.oasis-open.org ; Estreen, Fredrik > Subject: RE: [xliff] cos-301 proposed changed text > > I am in agreement. > > One note regarding timing, we are precious few weeks away from the ballot. > If anyone has a suggestion to clarify the wording the time is now to please > make your comment. I think we can take suggestions until the end of the > week at the very latest. But I would prefer to close on this sooner. We must > come to stability well ahead of the opening of the ballot in early July. > > Thanks, > > Bryan > ________________________________ > From: Dr. David Filip [ David.Filip@ul.ie ] > Sent: Tuesday, June 24, 2014 6:11 AM > To: Schnabel, Bryan S; Yves Savourel; xliff@lists.oasis-open.org ; Estreen, > Fredrik > Subject: Re: [xliff] cos-301 proposed changed text > > Hi everyone, I was attempting to implement an editorial solution to this as > promised. > However, I see only now that Fredrik's proposal actually changes the current > behavior. > > Let me summarize the mechanics of the intended behavior as I understand > it. > > I believe that currently it is possible to explicitly set order only on some > targets. > > I see that Fredrik's additional Constraint aimed to prohibit this. > > While it might have been generally a good design idea. I do not think that we > can introduce it now. > > Currently I believe it is possible to specify order as follows > > <unit> >  <segment> >   <source>source1</source> >   <target>target1</target> >  </segment> >  <segment> >   <source>source2</source> >   <target>target2</target> >  </segment> >  <segment> >   <source>source3</source> >   <target order="1">target3</target> >  </segment> > </unit> > > In the above > target3 corresponds to source1 , target1 to source2, and target2 to source3. > > This would be illegal after the change proposed by Fredrik. > > > I believe that we must base the solution on the constraints and other > normative text that currently is in the cos01 not endanger the progression to > cos02 and finally os01. > > > The Constraint on the order attribute itself requires uniqueness of the order > attribute values within a unit. > > The normative usage description (4.8.2 Segments Order) > > says that the value must be between 1 and N, where N is the summary > number of segments and ingnorables within the unit. > > From the above it follows that there must be bidirectional mapping between > all sources and all targets. > > So there is no other reason than convenience (which would have been valid > were we not in the cos01 stage) to REQUIRE that all targets have the order > value set explicitly once one of the targets has it set. > > If all agree with the above interpretation of the current state and intent of > the cos01 text. > > I believe that the editorial solution should be as follows: > > ----- New Wording ----- > 4.3.1.24 order > target order - indicates the order, in which to compose the target content > parts. > Value description: A positive integer. > > Default value: implicit, see below > When order is not explicitly set on any of the <target> elements of the > enclosing <unit> element, each <target> element corresponds to the > <source> element of its parent element. > When at at least one <target> element has the order attribute value set > explicitly, all <target> elements with set order values correspond to the > <source> elements whose order is naturally designated by the set order > values. The remaining implicit values (if any) correspond to implicit ordinals of > the remaining (if any) <source> elements, i.e. those that have had no > <target> elements assigned by explicit order attribute values. > > [I am fully aware that the above language is awkward and complicated, so > improvement ideas are welcome.] > > Example: > [a valid example similar to the pseudo-code above, showing how tragets are > shifted along the remaining free values] > > Used in: <target>. > > Constraints > * The explicit values of the order attribute MUST be unique within the > enclosing <unit> element. > > See the Segments Order section for the normative usage description. > > ----- Current wording ----- > > 4.3.1.24 order > target order - indicates the order, in which to compose the target content > parts. > Value description: A positive integer. > > Default value: undefined > > Used in: <target>. > > Constraints > * The value of the order attribute MUST be unique within the enclosing > <unit> element. > See the Segments Order section for the normative usage description. > > ----- end ----- > > I am not making a CFD at this point as the above does not seem stable. > > Improvement ideas welcome > dF > > > Dr. David Filip > ======================= > LRC CNGL LT-Web CSIS > University of Limerick, Ireland > telephone: +353-6120-2781 > cellphone: +353-86-0222-158 > facsimile: +353-6120-2734 > http://www.cngl.ie/profile/?i=452 > mailto: david.filip@ul.ie <mailto: david.filip@ul.ie > > > > On Tue, Jun 17, 2014 at 6:35 PM, Schnabel, Bryan S > < bryan.s.schnabel@tektronix.com <mailto: bryan.s.schnabel@tektronix.com > > > wrote: > +1 > > From: xliff@lists.oasis-open.org <mailto: xliff@lists.oasis-open.org > > [mailto: xliff@lists.oasis-open.org <mailto: xliff@lists.oasis-open.org >] On > Behalf Of David Filip > Sent: Tuesday, June 17, 2014 6:48 AM > To: Yves Savourel > Cc: xliff@lists.oasis-open.org <mailto: xliff@lists.oasis-open.org > > Subject: RE: [xliff] cos-301 proposed changed text > > > I agree with Yves assessment,  we cannot afford to insert a new constraint. > We could insert a warning. But the former part seems fine. > It actually leaves the default undefined but gives a clear hint how to > determine missing values. > We can slate such a constraint for 2.1 or errata. > I will tentatively implement an editorial solution based on this later this week > and will call for dissent. > Cheers > dF > > dF is AFK, so please bear with the typos and call me at > +353860222158 <tel:%2B353860222158> if my answer seems insufficient.. > On Jun 17, 2014 2:12 PM, "Yves Savourel" > < ysavourel@enlaso.com <mailto: ysavourel@enlaso.com >> wrote: > Hi everyone, > > I think Fredrik's additional sentence for the default value is quite good and > clear. > > For the additional constraint however, I'm not sure we can/want do this at > this stage. > Adding a constraint is likely to be seen as a major change rather than just > editorial one. > > Cheers, > -yves > > From: xliff@lists.oasis-open.org <mailto: xliff@lists.oasis-open.org > > [mailto: xliff@lists.oasis-open.org <mailto: xliff@lists.oasis-open.org >] On > Behalf Of Estreen, Fredrik > Sent: Tuesday, June 17, 2014 2:34 AM > To: xliff@lists.oasis-open.org <mailto: xliff@lists.oasis-open.org > > Subject: [xliff] cos-301 proposed changed text > > Hi, > > Here is my attempt at wording for the default value of the 'order' attribute > on <target> elements. The change makes the default behavior easy to > understand and also adds a constraint that enforces that order must be set > on multiple targets when reordering. It is however not necessary to specify it > on all targets all the time, for example when swapping the order of two > targets other targets may be left at the undefined state. > > ----- New Wording ----- > 4.3.1.24 order > target order - indicates the order, in which to compose the target content > parts. > Value description: A positive integer. > > Default value: undefined > When order is undefined the <target> corresponds to the <source> of its > parent element. > > Used in: <target>. > > Constraints > * The value of the order attribute MUST be unique within the enclosing > <unit> element unless left undefined. > * When order is specified on one <target>, it MUST also be specified on > other <target>s in the <unit> such that each <source>  has at most one > corresponding <target> after resolving the order for all <target>s in the > <unit>. > > See the Segments Order section for the normative usage description. > > ----- Current wording ----- > > 4.3.1.24 order > target order - indicates the order, in which to compose the target content > parts. > Value description: A positive integer. > > Default value: undefined > > Used in: <target>. > > Constraints > * The value of the order attribute MUST be unique within the enclosing > <unit> element. > See the Segments Order section for the normative usage description. > > ----- end ----- > > Regards, > Fredrik Estreen > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail.  Follow this link to all your TCs in OASIS at: > https://www.oasis- > open.org/apps/org/workgroup/portal/my_workgroups.php --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

Hi David, all, Just a note so I’m sure we have all the same interpretation: When you said: > Currently I believe it is possible to specify order as follows > <unit> > <segment> > <source>source1</source> > <target>target1</target> > </segment> > <segment> > <source>source2</source> > <target>target2</target> > </segment> > <segment> > <source>source3</source> > <target order="1">target3</target> > </segment> > </unit> That markup is incorrect because the implicit order of target1 is the same as the explicit order of target3. And also: > In the above > target3 corresponds to source1 , target1 to source2, and target2 to source3. It depends what you mean by 'corresponds': target3 still 'corresponds' to source3 not source1 (i.e. target3 is still the translation of source3). The order attribute only changes how the sequence of the targets is arranged. That is, when you merge you paragraph that was: "source1 source2 source3" the translated paragraph will show as "target3 target2 target1" (assuming you fixed the markup and added order='3' to target1. > I believe that currently it is possible to explicitly set > order only on some targets. Yes. In the example above target2 would have no explicite order. > I see that Fredrik's additional Constraint aimed > to prohibit this. No, it aims at making sure an implicit order and an explicit order don't have the same value. I hope that helps, Cheers, -ys

Yves, I am afraid that your interpretation is different. AFAIK and IMHO, Fredrik's algorithm that he posted in reaction to my proposal will pair the sources and targets as shown in my example. The explicitly set targets take positions first, the remaining targets fill the gaps in the natural order. I am unable to see how else this could work.. Can you please formulate the algorithm you have in mind? Thanks and cheers dF dF is AFK, so please bear with the typos and call me at +353860222158 if my answer seems insufficient.. On Jun 24, 2014 9:01 PM, "Yves Savourel" < ysavourel@enlaso.com > wrote: Hi David, all, Just a note so I’m sure we have all the same interpretation: When you said: > Currently I believe it is possible to specify order as follows > <unit> > <segment> >  <source>source1</source> >  <target>target1</target> > </segment> >  <segment> >  <source>source2</source> >  <target>target2</target> > </segment> > <segment> >  <source>source3</source> >  <target order="1">target3</target> > </segment> > </unit> That markup is incorrect because the implicit order of target1 is the same as the explicit order of target3. And also: > In the above > target3 corresponds to source1 , target1 to source2, and target2 to source3. It depends what you mean by 'corresponds': target3 still 'corresponds' to source3 not source1 (i.e. target3 is still the translation of source3). The order attribute only changes how the sequence of the targets is arranged. That is, when you merge you paragraph that was: "source1 source2 source3" the translated paragraph will show as "target3 target2 target1" (assuming you fixed the markup and added order='3' to target1. > I believe that currently it is possible to explicitly set > order only on some targets. Yes. In the example above target2 would have no explicite order. > I see that Fredrik's additional Constraint aimed > to prohibit this. No, it aims at making sure an implicit order and an explicit order don't have the same value. I hope that helps, Cheers, -ys --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

Hi David, all, You are correct: My initial reading of Fredrik’s new wording seems to indicate a different result than the one would expect. From you example you would end up with "target3 target1 target2" (ifI understand correctly), while my interpretation would be that your code is invalid because the order=1 is set implicitly for target1 and explicitly for target3, and that can't be. This said, looking at your initial proposal: > When order is not explicitly set on any of the <target> elements of the > enclosing <unit> element, each <target> element corresponds to the > <source> element of its parent element. > When at at least one <target> element has the order attribute value set > explicitly, all <target> elements with set order values correspond to the > <source> elements whose order is naturally designated by the set order > values. The remaining implicit values (if any) correspond to implicit ordinals of > the remaining (if any) <source> elements, i.e. those that have had no > <target> elements assigned by explicit order attribute values. It seems that it corresponds to my interpretation: In you example, "The remaining implicit values (if any) correspond to implicit ordinals of the remaining (if any) <source> elements" means target1 (which has no set order) has 1 as its implicit value, and target2 has 2. Therefore both target1 and target3 have their order set to 1. So, we clearly need to have a single interpretation. If I understand correctly, Fredrik's algorithm let the implicit values 'shift'. But I'm not sure this is easy to implement. It means the default value cannot be known by itself: you have to know the whole sequence of segments/ignorables to come up with the value. I think it's a lot simpler to just assume the default value is always the ordinal of the segment/ignorable position. Another aspect I'd like to be sure we in agreement for is that the order mechanism is about changing the sequence of the target entries when processed as a whole, it's not about making a given target3 the translation of a source1. It's about moving the position of target3 (which remains the translation of source3) at the first position. Cheers, -yves From: David Filip [ mailto:davidf@davidf.org ] Sent: Tuesday, June 24, 2014 4:17 PM To: Yves Savourel Cc: xliff@lists.oasis-open.org Subject: RE: [xliff] cos-301 proposed changed text Yves, I am afraid that your interpretation is different. AFAIK and IMHO, Fredrik's algorithm that he posted in reaction to my proposal will pair the sources and targets as shown in my example. The explicitly set targets take positions first, the remaining targets fill the gaps in the natural order. I am unable to see how else this could work.. Can you please formulate the algorithm you have in mind? Thanks and cheers dF dF is AFK, so please bear with the typos and call me at +353860222158 if my answer seems insufficient.. On Jun 24, 2014 9:01 PM, "Yves Savourel" <ysavourel@enlaso.com> wrote: Hi David, all, Just a note so I’m sure we have all the same interpretation: When you said: > Currently I believe it is possible to specify order as follows > <unit> > <segment> > <source>source1</source> > <target>target1</target> > </segment> > <segment> > <source>source2</source> > <target>target2</target> > </segment> > <segment> > <source>source3</source> > <target order="1">target3</target> > </segment> > </unit> That markup is incorrect because the implicit order of target1 is the same as the explicit order of target3. And also: > In the above > target3 corresponds to source1 , target1 to source2, and target2 to source3. It depends what you mean by 'corresponds': target3 still 'corresponds' to source3 not source1 (i.e. target3 is still the translation of source3). The order attribute only changes how the sequence of the targets is arranged. That is, when you merge you paragraph that was: "source1 source2 source3" the translated paragraph will show as "target3 target2 target1" (assuming you fixed the markup and added order='3' to target1. > I believe that currently it is possible to explicitly set > order only on some targets. Yes. In the example above target2 would have no explicite order. > I see that Fredrik's additional Constraint aimed > to prohibit this. No, it aims at making sure an implicit order and an explicit order don't have the same value. I hope that helps, Cheers, -ys --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

Hi Yves, I think David's interpretation is the same as the one described by my algorithm. The first source is no longer "available" once the target with order="1" has claimed that spot, hence no target without an explicit order attribute could have an implicit order of 1. I agree that it makes it impossible to determine the implicit order without looking at the full unit and that changes at the end of the unit may affect the implicit value of things appearing earlier. I don't like that at all and my original proposal was based on the interpretation that you have and which I also had before this discussion. That having one target with explicit order and the target of the source at that index not having an order attribute would be illegal as we would now have two target at the same index. But I can see David's point and that would lead to the shifting of things. If your interpretation is the right one (which I would like) my original text should be ok as it only formalize something that was already illegal. Regards, Fredrik Estreen >
Original Message----- > From: xliff@lists.oasis-open.org [ mailto:xliff@lists.oasis-open.org ] On Behalf > Of Yves Savourel > Sent: den 25 juni 2014 05:18 > To: xliff@lists.oasis-open.org > Subject: RE: [xliff] cos-301 proposed changed text > > Hi David, all, > > You are correct: My initial reading of Fredrik’s new wording seems to indicate > a different result than the one would expect. > From you example you would end up with "target3 target1 target2" (ifI > understand correctly), while my interpretation would be that your code is > invalid because the order=1 is set implicitly for target1 and explicitly for > target3, and that can't be. > > This said, looking at your initial proposal: > > > When order is not explicitly set on any of the <target> elements of > > the enclosing <unit> element, each <target> element corresponds to the > > <source> element of its parent element. > > When at at least one <target> element has the order attribute value > > set explicitly, all <target> elements with set order values correspond > > to the <source> elements whose order is naturally designated by the > > set order values. The remaining implicit values (if any) correspond to > > implicit ordinals of the remaining (if any) <source> elements, i.e. > > those that have had no <target> elements assigned by explicit order > attribute values. > > It seems that it corresponds to my interpretation: > In you example, "The remaining implicit values (if any) correspond to implicit > ordinals of the remaining (if any) <source> elements" means target1 (which > has no set order) has 1 as its implicit value, and target2 has 2. Therefore both > target1 and target3 have their order set to 1. > > So, we clearly need to have a single interpretation. > > If I understand correctly, Fredrik's algorithm let the implicit values 'shift'. But > I'm not sure this is easy to implement. It means the default value cannot be > known by itself: you have to know the whole sequence of > segments/ignorables to come up with the value. > I think it's a lot simpler to just assume the default value is always the ordinal > of the segment/ignorable position. > > > Another aspect I'd like to be sure we in agreement for is that the order > mechanism is about changing the sequence of the target entries when > processed as a whole, it's not about making a given target3 the translation of > a source1. It's about moving the position of target3 (which remains the > translation of source3) at the first position. > > Cheers, > -yves > > > > > From: David Filip [ mailto:davidf@davidf.org ] > Sent: Tuesday, June 24, 2014 4:17 PM > To: Yves Savourel > Cc: xliff@lists.oasis-open.org > Subject: RE: [xliff] cos-301 proposed changed text > > Yves, I am afraid that your interpretation is different. > AFAIK and IMHO, Fredrik's algorithm that he posted in reaction to my > proposal will pair the sources and targets as shown in my example. > The explicitly set targets take positions first, the remaining targets fill the > gaps in the natural order. > I am unable to see how else this could work.. > Can you please formulate the algorithm you have in mind? > Thanks and cheers > dF > dF is AFK, so please bear with the typos and call me at +353860222158 if my > answer seems insufficient.. > On Jun 24, 2014 9:01 PM, "Yves Savourel" <ysavourel@enlaso.com> wrote: > Hi David, all, > > Just a note so I’m sure we have all the same interpretation: > When you said: > > > Currently I believe it is possible to specify order as follows <unit> > > <segment> <source>source1</source> <target>target1</target> > > </segment> <segment> <source>source2</source> > > <target>target2</target> </segment> <segment> > > <source>source3</source> <target order="1">target3</target> > > </segment> </unit> > > That markup is incorrect because the implicit order of target1 is the same as > the explicit order of target3. > > And also: > > > In the above > > target3 corresponds to source1 , target1 to source2, and target2 to source3. > > It depends what you mean by 'corresponds': target3 still 'corresponds' to > source3 not source1 (i.e. target3 is still the translation of source3). The order > attribute only changes how the sequence of the targets is arranged. That is, > when you merge you paragraph that was: "source1 source2 source3" the > translated paragraph will show as "target3 target2 target1" (assuming you > fixed the markup and added order='3' to target1. > > > > I believe that currently it is possible to explicitly set order only > > on some targets. > > Yes. In the example above target2 would have no explicite order. > > > I see that Fredrik's additional Constraint aimed to prohibit this. > > No, it aims at making sure an implicit order and an explicit order don't have > the same value. > > > I hope that helps, > Cheers, > -ys > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis- > open.org/apps/org/workgroup/portal/my_workgroups.php > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis- > open.org/apps/org/workgroup/portal/my_workgroups.php

Hi Fredrik, David, all,   > ...But I can see David's point and that would lead to the > shifting of things. If your interpretation is the right one (which I > would like) my original text should be ok as it only formalize > something that was already illegal.   I think if we use Fredrik’s re-worded text for the default definition as it is here: https://lists.oasis-open.org/archives/xliff/201406/msg00049.html   [[ Default value: undefined When order is undefined the <target> corresponds to the <source> of its parent element. ]]   And use his solution of moving the text of the ‘constraint’ to the Segment Order section: https://lists.oasis-open.org/archives/xliff/201406/msg00053.html   The result would be fine. And it would not be a major change as it simply clarify the behavior we are already expecting.   And we can demonstrate that it is the expected behavior through this test case: https://tools.oasis-open.org/version-control/browse/wsvn/xliff/trunk/xliff-20/test-suite/core/invalid/bad_OrderNotUnique2.xlf   This example of invalid file illustrate how an implicit value clash with an explicit one. It has been in our test suite for a while and part of both Bryan and my tests suite. While it's obviously not normative, I think it shows how implementers have interpreted the default values for now.   There is also this input: https://tools.oasis-open.org/version-control/browse/wsvn/xliff/trunk/xliff-20/test-suite/core/in-out/toJoin4_in.xlf and the expected output: https://tools.oasis-open.org/version-control/browse/wsvn/xliff/trunk/xliff-20/test-suite/core/in-out/toJoin4_out.xlf that has implicit and explicit order values and may help in seeing how it is interpreted.     Cheers, -yves          
Original Message----- From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Estreen, Fredrik Sent: Wednesday, June 25, 2014 3:40 AM To: Yves Savourel; xliff@lists.oasis-open.org Subject: RE: [xliff] cos-301 proposed changed text   Hi Yves,   I think David's interpretation is the same as the one described by my algorithm. The first source is no longer "available" once the target with order="1" has claimed that spot, hence no target without an explicit order attribute could have an implicit order of 1.   I agree that it makes it impossible to determine the implicit order without looking at the full unit and that changes at the end of the unit may affect the implicit value of things appearing earlier.   I don't like that at all and my original proposal was based on the interpretation that you have and which I also had before this discussion. That having one target with explicit order and the target of the source at that index not having an order attribute would be illegal as we would now have two target at the same index. But I can see David's point and that would lead to the shifting of things. If your interpretation is the right one (which I would like) my original text should be ok as it only formalize something that was already illegal.   Regards, Fredrik Estreen   >
Original Message----- > From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] > On Behalf Of Yves Savourel > Sent: den 25 juni 2014 05:18 > To: xliff@lists.oasis-open.org > Subject: RE: [xliff] cos-301 proposed changed text > > Hi David, all, > > You are correct: My initial reading of Fredrik’s new wording seems to > indicate a different result than the one would expect. > From you example you would end up with "target3 target1 target2" (ifI > understand correctly), while my interpretation would be that your code > is invalid because the order=1 is set implicitly for target1 and > explicitly for target3, and that can't be. > > This said, looking at your initial proposal: > > > When order is not explicitly set on any of the <target> elements of > > the enclosing <unit> element, each <target> element corresponds to > > the <source> element of its parent element. > > When at at least one <target> element has the order attribute value > > set explicitly, all <target> elements with set order values > > correspond to the <source> elements whose order is naturally > > designated by the set order values. The remaining implicit values > > (if any) correspond to implicit ordinals of the remaining (if any) <source> elements, i.e. > > those that have had no <target> elements assigned by explicit order > attribute values. > > It seems that it corresponds to my interpretation: > In you example, "The remaining implicit values (if any) correspond to > implicit ordinals of the remaining (if any) <source> elements" means > target1 (which has no set order) has 1 as its implicit value, and > target2 has 2. Therefore both > target1 and target3 have their order set to 1. > > So, we clearly need to have a single interpretation. > > If I understand correctly, Fredrik's algorithm let the implicit values > 'shift'. But I'm not sure this is easy to implement. It means the > default value cannot be known by itself: you have to know the whole > sequence of segments/ignorables to come up with the value. > I think it's a lot simpler to just assume the default value is always > the ordinal of the segment/ignorable position. > > > Another aspect I'd like to be sure we in agreement for is that the > order mechanism is about changing the sequence of the target entries > when processed as a whole, it's not about making a given target3 the > translation of a source1. It's about moving the position of target3 > (which remains the translation of source3) at the first position. > > Cheers, > -yves > > > > > From: David Filip [mailto:davidf@davidf.org] > Sent: Tuesday, June 24, 2014 4:17 PM > To: Yves Savourel > Cc: xliff@lists.oasis-open.org > Subject: RE: [xliff] cos-301 proposed changed text > > Yves, I am afraid that your interpretation is different. > AFAIK and IMHO, Fredrik's algorithm that he posted in reaction to my > proposal will pair the sources and targets as shown in my example. > The explicitly set targets take positions first, the remaining targets > fill the gaps in the natural order. > I am unable to see how else this could work.. > Can you please formulate the algorithm you have in mind? > Thanks and cheers > dF > dF is AFK, so please bear with the typos and call me at +353860222158 > if my answer seems insufficient.. > On Jun 24, 2014 9:01 PM, "Yves Savourel" <ysavourel@enlaso.com> wrote: > Hi David, all, > > Just a note so I’m sure we have all the same interpretation: > When you said: > > > Currently I believe it is possible to specify order as follows > > <unit> <segment>  <source>source1</source>  <target>target1</target> > > </segment>  <segment>  <source>source2</source> > > <target>target2</target> </segment> <segment> > > <source>source3</source>  <target order="1">target3</target> > > </segment> </unit> > > That markup is incorrect because the implicit order of target1 is the > same as the explicit order of target3. > > And also: > > > In the above > > target3 corresponds to source1 , target1 to source2, and target2 to source3. > > It depends what you mean by 'corresponds': target3 still 'corresponds' > to > source3 not source1 (i.e. target3 is still the translation of > source3). The order attribute only changes how the sequence of the > targets is arranged. That is, when you merge you paragraph that was: > "source1 source2 source3" the translated paragraph will show as > "target3 target2 target1" (assuming you fixed the markup and added order='3' to target1. > > > > I believe that currently it is possible to explicitly set order only > > on some targets. > > Yes. In the example above target2 would have no explicite order. > > > I see that Fredrik's additional Constraint aimed to prohibit this. > > No, it aims at making sure an implicit order and an explicit order > don't have the same value. > > > I hope that helps, > Cheers, > -ys > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail.  Follow this link to all your TCs in OASIS at: > https://www.oasis- > open.org/apps/org/workgroup/portal/my_workgroups.php > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail.  Follow this link to all your TCs in OASIS at: > https://www.oasis- > open.org/apps/org/workgroup/portal/my_workgroups.php  

Yves, I can see your point with the test case and I am sympathetic to making your described behavior the one clearly and unequivocally described in the spec. I also agree that the clarification should be done in the normative usage description that is referenced from the attribute definition, has the example and is a natural place to elaborate how the implicit values work. This said the added text Fredrik proposed [A <source> element MUST never be related to more than one <target> element regardless of reordering.] still does not exclude the "sliding" interpretation. When explicitly set values become unavailable as in the algorithm described by Fredrik which is equivalent with my interpretation and my former proposal, there is still bidirectional mapping between sources and targets and the MUST statement above is NOT violated. So we need something clearer than that to exclude the sliding interpretation. I will make a stab on it later today. This is just to nudge the list to also think of a viable formulation, as we definitely need to make a CFD today to have all comments resolved by 5th July Cheers dF However, Fredrik's addition to the  Dr. David Filip ======================= LRC CNGL LT-Web CSIS University of Limerick, Ireland telephone: +353-6120-2781 cellphone: +353-86-0222-158 facsimile: +353-6120-2734 http://www.cngl.ie/profile/?i=452 mailto: david.filip@ul.ie On Wed, Jun 25, 2014 at 12:19 PM, Yves Savourel < ysavourel@enlaso.com > wrote: Hi Fredrik, David, all,   > ...But I can see David's point and that would lead to the > shifting of things. If your interpretation is the right one (which I > would like) my original text should be ok as it only formalize > something that was already illegal.   I think if we use Fredrik’s re-worded text for the default definition as it is here: https://lists.oasis-open.org/archives/xliff/201406/msg00049.html   [[ Default value: undefined When order is undefined the <target> corresponds to the <source> of its parent element. ]]   And use his solution of moving the text of the ‘constraint’ to the Segment Order section: https://lists.oasis-open.org/archives/xliff/201406/msg00053.html   The result would be fine. And it would not be a major change as it simply clarify the behavior we are already expecting.   And we can demonstrate that it is the expected behavior through this test case: https://tools.oasis-open.org/version-control/browse/wsvn/xliff/trunk/xliff-20/test-suite/core/invalid/bad_OrderNotUnique2.xlf   This example of invalid file illustrate how an implicit value clash with an explicit one. It has been in our test suite for a while and part of both Bryan and my tests suite. While it's obviously not normative, I think it shows how implementers have interpreted the default values for now.   There is also this input: https://tools.oasis-open.org/version-control/browse/wsvn/xliff/trunk/xliff-20/test-suite/core/in-out/toJoin4_in.xlf and the expected output: https://tools.oasis-open.org/version-control/browse/wsvn/xliff/trunk/xliff-20/test-suite/core/in-out/toJoin4_out.xlf that has implicit and explicit order values and may help in seeing how it is interpreted.     Cheers, -yves