Re: [xliff] Re-ordering of inline codes

[David Filip <davidf@davidf.org>]

Thanks, Yves, for investigating.. more inline..

On Nov 16, 2013 1:49 PM, "Yves Savourel" <ysavourel@enlaso.com> wrote:
>
> 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**.
I think that it is ok to fix the proposed definition like this.
>
> 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.
I do not think it is a drawback.
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.
I do not think this is an issue since source is REQUIRED.
Let us call this solution 0.
>
> 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.

In case the TC agrees that looking up source for solution 0 is a major drawback, which I believe it is not; I'd prefer C as the solution.
IMHO, the only important difference between 0 and C is the distribution of the burden of knowing the start of every sequence.
With 0, that burden is with Modifiers, but only in cases when a previously populated target had adjacent non-reorderable sequences.
The C solution forces Extractors to know always.
>
> 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.
I see that the 'firstNo' value allows Extractors to specify adjacent non-reorderable sequences and in this sense it is more expressive, not sure however if this bit of expressivity makes it better than 0, which is less demanding for Extractors..
>
> 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.
0 is a solution as well and does not imply this requirement
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
>
>
>
> ---------------------------------------------------------------------
> 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
>