Re: [xliff] Re-ordering of inline codes

[Yves Savourel <ysavourel@enlaso.com>]

Hi David, all,

I've implemented David's solution described in https://lists.oasis-open.org/archives/xliff/201311/msg00088.html to test it.

It's almost perfect, but there is one limitation that may problematic. 

Essentially the source or target unit's content can be seen as something like this:

[--Nnn-Nnn-Nn]

Where each '-' is a code marker with canReorder='yes' and 'n' is a code marker with canReorder='no' ('N' being the first marker of a
sequence).

A sequence is any number of consecutive markers with canReorder='no', with its boundaries being: the start or end of the content or
a marker with canReorder='yes'.

It is fairly easy to gather the sequences and compare a content before and after a change, or between source and target.

With one exception: when two sequences are re-ordered in a way they become adjacent. For example, imagine a tool working on the
target content.

Initially the content is the same as the source:

[Nn-Nn]

Then there is a first re-ordering that moves the middle marker at the end:

[NnNn-]

This change is valid because each sequence is still the same (no canReorder='yes' has been moved within a sequence of
canReorder='no'). We can also verify it is valid by comparing the initial target content with the new one.

Then there is another change. This time the ending marker is moved back at the middle:

[Nn-Nn]

The problem is that, while it is a valid move based on the source, it will not be detected as such if the comparison is done with
the previous state of the target, because the previous state is now seen as [Nnnn-].

A sequence should really be defined as: Any number of consecutive markers with canReorder='no', with its boundaries being: the
start, or end of the content, or a marker with canReorder='yes', **or a marker that was the start of a sequence in the source
content**.

In other words: Currently we can only compare the source and the different target states, not a previous target state with a new
one.

It is difficult to say if this is a major drawback or not. Most tools are likely to have access to the source content when
transforming the target, but the mechanism as it is prevents you to implement a tool to verify a change without access to the source
content too.

There are possible solutions for this:

A) It is to change canReorder='yes|no' to order='N' where each sequence of non-moveable codes starts with a code order='1', so we
have sequences like this: [--123-123-12] and therefore going from [1212-] to [12-12] is doable without referring to the source.

B) Add a new attribute that is used to denote a marker is the first of a sequence (i.e. set the 'N' explicitly). I don't like that
solution.

C) Add a new value to canReorder (e.g. "firstNo") that would allow to detect the first code of a sequence.

Solution A or C would both work.

Solution C) has a lot of advantages. In my opinion it's not a new re-ordering mechanism, just a different representation of the
current one that removes an ambiguity. It also add a feature: it allows you to define separate sequences that are adjacent in the
source. That could be quite useful. With UI strings being increasingly defined as mixed content of formatting markup and software
variables the more flexibility XLIFF will offer for allowing/preventing re-ordering will be good.

Note that any solution for this problem makes things a little bit more complex for the extractor agent, as now it has to know where
sequences starts too. But that is probably not a big issue.

I've added a few test files in the collection of invalid files[1] that illustrate the re-ordering cases.
The Web start for Lynx[2] and the toolkit[3] have also been updated.

[1]: http://okapi.opentag.com/snapshots/invalidXLIFF20Files.zip
[2]: http://okapi.opentag.com/webstart/lynx/
[3]: http://okapi.opentag.com/snapshots/okapi-xliffLib_all-platforms_0.21-SNAPSHOT.zip


Thoughts?
-yves