OASIS XML Localisation Interchange File Format (XLIFF) TC

I had another look and am now proposing the following solution [OLD] 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. [/OLD order definition] [NEW] 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 When order is not explicitly set, the  <target>  corresponds to the  <source>  of its parent element. Used in:   <target> . Constraints The explicit and implicit values of the  order  attribute MUST be unique within the enclosing  <unit>  element. See the  Segments Order  section for the normative usage description. [/NEW] [NEW adding a Warning before the example in  4.8.2 Segments Order ] 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 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 Fri, Jun 27, 2014 at 10:51 AM, Dr. David Filip < David.Filip@ul.ie > wrote: 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          

Hi all, this is now implemented in our current working draft: https://tools.oasis-open.org/version-control/browse/wsvn/xliff/trunk/xliff-20/xliff-core.pdf The dissent period will be over tomorrow NOON GMT DST, so feel free to comment. The solution as now implemented in the spec (with minuscule differences compared to the text proposed above). Cheers dF  [NEW, with new text highlighted yellow ] 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. Warning When  Writers  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>  element. For example, the following HTML documents have the same paragraph with three sentences in different order: ... ... 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, the  <target>   order  corresponds to its sibling  <source> , i.e. it is not being moved anywhere when composing target content of the enclosing  <unit>  and the implicit  order  value is of that position within the  <unit> . 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. [/NEW] 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 Fri, Jun 27, 2014 at 11:18 AM, Dr. David Filip < David.Filip@ul.ie > wrote: I had another look and am now proposing the following solution [OLD] 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. [/OLD order definition] [NEW] 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 When order is not explicitly set, the  <target>  corresponds to the  <source>  of its parent element. Used in:   <target> . Constraints The explicit and implicit values of the  order  attribute MUST be unique within the enclosing  <unit>  element. See the  Segments Order  section for the normative usage description. [/NEW] [NEW adding a Warning before the example in  4.8.2 Segments Order ] 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 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 Fri, Jun 27, 2014 at 10:51 AM, Dr. David Filip < David.Filip@ul.ie > wrote: 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          
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   >