I noticed that my original proposal has been written in a very sloppy way omitting two important among other things two important negations..
Following the discussion we had with Yves, I am now providing two new versions, one for solution 0 [zero] and one for solution C.
0:
*Processing Requirements:*
If canReorder="yes" and canReorder="no" codes are mixed within a <segment> element's <source> child:
Modifiers MUST NOT break the corresponding sequences of codes set to canReoder="no" with codes set to canReorder="yes" in the sibling <target> element.
Modifiers MAY change the relative position of the non-reorderable sequences.
C:
*Processing Requirements:*
When specifying adjacent sequences of codes that MUST NOT be reordered, Writers MUST set the first code of each sequence to canReoder="firstNo".
[Please note that Extractors that make whole segments uniformly reorderable or not, do not need to bother about the third value.]
[Modifiers merging segments will need to introduce the third value if a mixed sequence is the result, this would need to be added or referenced from resegmentation PRs]
Modifiers MUST NOT break sequences of codes set to canReoder="no" starting with a code set to canReoder="firstNo" with codes set to canReorder="yes".
Modifiers MAY change the relative position of the non-reorderable sequences starting with codes set to canReorder="firstNo".
I think that we should decide in today's meeting, if we go with C or 0.
Rgds
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:
On Thu, Nov 14, 2013 at 3:30 PM, Dr. David Filip <> wrote:
There definitely is need for clarification. I would however advise against introducing a brand new code ordering mechanism.
My proposal how to make this unambiguous would be as follows:
If canReorder="yes" and canReorder="no" codes are mixed within a segment, any sequence of codes set to canReoder="no" MUST be broken with codes set to canReorder="yes"
As result, having no on a single isolated code would have practical impact. But this seems OK to me
Thoughts?
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:
On Mon, Nov 11, 2013 at 4:13 PM, Yves Savourel <> wrote:
Hi all,
While trying to implement validation for canReorder='no' I've run into a need for clarification:
Currently we define the re-ordering as:
[[
A code can be re-ordered: That is, a given code can be moved before or after another inline code.
]]
Imagine that we have three codes: two can be re-ordered, but not the last one.
"<1-canRO/> text <2-canRO/> text <3-cannotRO/>"
We cannot do this:
"<1-canRO/> text <3-cannotRO/> text <2-canRO/>"
And it seems we cannot do this either:
"<2-canRO/> text <3-cannotRO/> text <1-canRO/>"
In fact, it looks like if there is a single code that has the canReorder flag set to no in the unit, things you can move become very
limited. And I can think of examples where such limitations hamper what a translator should be able to do:
For example: "Can't find %s. Check %s. This is <b>important</b>."
In XLIFF:
<source>Can't find <ph id='1' canReorder='no' canDelete='no' canCopy='no'/>. Check <ph id='2' canReorder='no' canDelete='no'
canCopy='no'/>. This is <pc id='3'>important</pc>.</source>
It should be OK to do this:
<target> This is <pc id='3'>important</pc>. Can't find <ph id='1' canReorder='no' canDelete='no' canCopy='no'/>. Check <ph id='2'
canReorder='no' canDelete='no' canCopy='no'/>.</target>
But based on the current definition we cannot do that.
I see also issue with being able to addition or deletion of codes that should be allowed, and would not in the current rules.
Maybe we have a mechanism that is too simplistic: It seems the part that is missing is the information about in relation with which
other code one given code cannot be re-ordered. It looks like it's all or nothing.
A possibly more flexible way to allow/disallow code re-ordering would be to have a sequence defined for the codes that are related
and should be kept in the same order. For example:
<source>Can't find <ph id='1' order='1' canDelete='no' canCopy='no'/>. Check <ph id='2' order='2' canDelete='no' canCopy='no'/>.
This is <pc id='3'>important</pc>.</source>
That way we could state that the codes with a specified order must be kept in the given sequence, while any other code can be moved
around.
Thoughts?
Cheers,
-yves
---------------------------------------------------------------------
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
