[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xliff] cos-301 proposed changed text
Hi Yves, All I was worried that that might be the case (the constraint). Perhaps we should put that on the backlog for 2.1 instead. The segment order does not make sense without such a constraint though. Would it be more acceptable to add a sentence to the end of the section describing the segment order. The section is normative so should technically be as important as a constraint, but perhaps adding a sentence
to that paragraph is less of a change than adding a new constraint. 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. A <source> element MUST never be related to more than one <target> element regardless of reordering. Regards, Fredrik Estreen From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org]
On Behalf Of Yves Savourel 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]
On Behalf Of Estreen, Fredrik 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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]