OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

[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
Sent: den 17 juni 2014 15:13
To: xliff@lists.oasis-open.org
Subject: RE: [xliff] cos-301 proposed changed text

 

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
Sent: Tuesday, June 17, 2014 2:34 AM
To: 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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]