RE: [xliff] cos-301 proposed changed text

["Schnabel, Bryan S" <bryan.s.schnabel@tektronix.com>]

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