RE: [xliff] cos-301 proposed changed text

["Estreen, Fredrik" <Fredrik.Estreen@lionbridge.com>]

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