RE: [xliff] Re-ordering of inline codes

[Yves Savourel <ysavourel@enlaso.com>]

Hi David, all,

> 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.

For option 0 the burden of referring to the source is always there: To know the previous target is [NnNn-] and not [nnnn-] or
vice-versa, you have to look at the source.
For option C the extractor's burden of setting the start of each sequence is minimal since you have access to all information in the
original format. 


>> 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. 
>> ...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.

I think you are looking at the problem the wrong way. 

The problem is not whether or not the source is available to do a comparison. It is that the validation is done through a
comparison. A tool should be able to validate the re-ordering of the codes in a given content based solely on information in that
content. XLIFF is just an exchange format: we shouldn't force tool requirements such as a dependency to the source to validate a
target re-ordering when it can be avoided.

In addition, having a required source in the XLIFF unit doesn't solve the missing feature of allowing two adjacent separate
sequences of non-reordereable codes in the source.

One can look at this from the tools' viewpoint: A tool XYZ can create localizable content with information about re-ordering
permissions for the inline codes. XYZ has no restriction on the features it can implement and may offer allowing the move of
adjacent fixed sequences.

Now XYZ offers also a way to export/import XLIFF 2.0 documents. Currently such tool has no way to store all the metadata it needs in
that XLIFF file. Its solution: use a custom extension to indicate which canReordered='no' is first of a sequence... Do we really
want that?

Maybe for once we could try to apply the tools requirements to XLIFF rather than find a way for XLIFF to foist upon the tools some
limitations. :)

We cannot possibly think about all the localization process requirements. But I think should try to accommodate the ones we know
about that are inexpensive to make provision for.

Option C:
- is a very small change to the current specification.
- ask very little extra from the extractors
- offers true self-contained validation vs. comparison.
- simplifies greatly the implementation of the modifiers (no more dependency on source).
- ensures a more complete set of functionalities for re-ordering (adjacent sequences)

Do we really want to keep option 0?


> ...it is more expressive, not sure however if this bit of expressivity 
> makes it better than 0, which is less demanding for Extractors..

In my experience the extractor is always the easiest part.

Cheers,
-yves