Subject: Re: [xliff] Re-ordering of inline codes
Hi David, all,
For option 0 the burden of referring to the source is always there: To know the previous target is [NnNn-] and not [nnnn-] or
> IMHO, the only important difference between 0 and C is the
> distribution of the burden of knowing the start of every
> With 0, that burden is with Modifiers, but only in cases when
> a previously populated target had adjacent non-reorderable
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
>> ...the mechanism as it is prevents you to implement a tool
>> 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.
>> to verify a change without access to the source content too.I think you are looking at the problem the wrong way.
> I do not think this is an issue since source is REQUIRED.
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
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
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.
- 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.
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: