RE: [xliff] cos-301 proposed changed text

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

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