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] Re-ordering of inline codes

Hi David,


Both a note and a PR to indicate the change MAY be made would be fine.



From: Dr. David Filip [mailto:David.Filip@ul.ie]
Sent: Wednesday, November 20, 2013 9:39 AM
To: Yves Savourel
Cc: xliff@lists.oasis-open.org
Subject: Re: [xliff] Re-ordering of inline codes


Yves, I can see that this has very small impact in fact.

Nevertheless, it is confusing things. It allows to define a sequence of one (which is a theroretical nonsense) that has effectively the same semantic as canReoder="yes", which is much worse than just being theoretically wrong or ugly.


This said I am not against IFF we add a note explaining that sequence of one was allowed to simplify extraction and has actually no impact.


Alternatively, we could normatively allow Modifiers (add a PR) to clean up and kill sequences of one, replacing isolated "fisrtNo" with "yes" or deleting it since "yes" is the default I suppose..



Dr. David Filip



University of Limerick, Ireland

telephone: +353-6120-2781

cellphone: +353-86-0222-158

facsimile: +353-6120-2734


On Wed, Nov 20, 2013 at 3:51 PM, Yves Savourel <ysavourel@enlaso.com> wrote:

Hi all,

I've implemented the changes for the canReorder attribute and identify a possible small change that would make things a lot easier
for both extraction and validation:

Currently we define a "sequence" as this:

Inline codes re-ordering within a source or target content can be limited by defining no-reordereable sequences. Such sequence is
made of two or more consecutive inline elements where the first element has canReorder set to firstNo and the next elements have
canReorder set to no.


When extracting you may know that an inline code should not be reordered but based on our definition you should mark it so only if
there are two or more of them. This forces the extractor to do some look-ahead or back-writing. Allowing sequence made of a single
element would simplify things. Obviously such sequences would be moot, but they wouldn't hamper anything either.

So I would propose to amend the text above to:

Inline codes re-ordering within a source or target content can be limited by defining no-reorderable sequences. Such sequence is
made of a first inline element with canReorder set to firstNo and zero or more consecutive elements with canReorder set to no.


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:


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