Hi Yves, I am not strongly against C.
In my opinion 0 and C are the only two viable solutions with minimum impact.
Re your arguments, you will always need to look at source until target is first populated, so I would not take that one.
I admitted that C has the advantage of being able to specify adjacent non-reorderable sequences in source.
I also said I am not sure if this advantage is big enough to make C superior. I believe we need more TC members's input as to which of 0 or C they like..
As to background motivations, I wanted to go easy on extractors to drive adoption. I'd like to hear Microsoft's, Oracle's and IBM's position, whether they want the third value ("firstNo") for their extractors.
Cheers
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 Sun, Nov 17, 2013 at 6:01 AM, Yves Savourel <> wrote:
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
---------------------------------------------------------------------
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
