[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.
-ys
From: Dr. David Filip [mailto:David.Filip@ul.ie]
Sent: Wednesday, November 20, 2013 9:39 AM
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..
Cheers
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
mailto: david.filip@ul.ie
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.
]]
Cheers,
-ys
---------------------------------------------------------------------
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]