[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Call for Dissent (CFD) Re: [xliff] cos-301 proposed changed text
target order - indicates the order, in which to compose the target content parts.
Value description: A positive integer.
Default value: undefined
Used in: <target>.
See the Segments Order section for the normative usage description.
[/OLD order definition]
[NEW]
target order - indicates the order, in which to compose the target content parts.
Value description: A positive integer.
Default value: implicit
When order is not explicitly set, the <target> corresponds to the <source> of its parent element.
Used in: <target>.
Constraints
See the Segments Order section for the normative usage description.
[/NEW]
[NEW adding a Warning before the example in
Warning:
When Agents set explicit order on <target> elements, they have to check for conflicts with implicit order, as <target> elements without explicit order correspond to their sibling <source> elements. Beware that moving one <target> element is likely to cause a renumbering domino effect throughout the enclosing <unit>.
[/NEW]
This is a Call for Dissent and will become the resolution unless I hear material objections by Tuesday, July 1, 2014, 12NOON GMT DST.
Cheers
dF
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 JulyCheersdFHowever, Fredrik's addition to theDr. David Filip=======================
LRC | CNGL | LT-Web | CSISUniversity of Limerick, Irelandtelephone: +353-6120-2781cellphone: +353-86-0222-158facsimile: +353-6120-2734mailto: david.filip@ul.ieOn 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:
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:
and the expected output:
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:
> 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:
> open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]