Re: [xliff-promotion] RE: <group> overloaded in XLIFF 1.2

On Tue, Feb 7, 2012 at 21:18, Yves Savourel <ysavourel@enlaso.com> wrote:

Hi David,

> when I was referring to the overload of <group> in 1.2 spec
> I had this attribute in mind
> http://docs.oasis-open.org/xliff/v1.2/os/xliff-core.html#merged-trans

To me, this attribute (and equiv-trans) let you "fix" some bad structure of the initial extraction (for example a title that is broken down in two "paragraphs"), but it's not a way to deal with segmentation in general.

> This is also what IN! are using for merging <trans-unit>s if segmentation does not fit.

I don't think so. There is no reference to merged-trans (or equiv-trans) in XLIFF:doc. The definition of <group> in XLIFF:doc also specify that it has no attributes (mandatory or optional).

> So if one of the uses of group is for merging trans-units,
> they cannot be blamed IMHO if they choose to use it with this semantics only.
> Group is an optional element that is potentially recursive
> but no guidance and/or processing requirements are given
> in the 1.2 spec, so they should be fine I guess in using
> it for just merging management..

In any case using <trans-unit> for segmentation is not interoperable:

a) simply because the segmentation representation is clearly defined in 1.2 and uses <seg-source>, not <group> and <trans-unit>.

b) if you need to split a content (i.e. add a segment) you cannot: adding <trans-unit> elements won't work when merging things back (regardless of the usage of <group>)

XLIFF:doc could use <seg-source>: the two only pure XLIFF attributes used in XLIFF:doc for <trans-unit> are id and translate. They could be mapped to mid and one extended attribute on <mrk> (and all extended attributes of <trans-unit> moved to <mrk>) This would provide the same functionality AND be interoperable.

The problem I have with XLIFF:doc is that interoperability with a normal XLIFF tool is lost without a valid reason. All the features provided could be done without losing interoperability with the standard XLIFF.

The argument of IN then will be: "But we don't care about interoperability with normal XLIFF because XLIFF:doc is meant to be used only with XLIFF:doc-enable tools" (there are many complex processing expectations). If that is the case then XLIFF:doc should not be promoted as an XLIFF solution.

There is a very easy solution to leave XLIFF:doc as it is today (and even simplify it): make it a non-XLIFF document. Change the namespace. As a tool developer I see XLIFF and XLIFF:doc as two different formats: the processing expectations are vastly more complex and strict for XLIFF:doc, so it's easier to just treat it as a separate format anyway.

Note also that regardless of the good intent of IN to develop this for a close set of tools, I know that one of those day I'll get an XLIFF:doc file and will have to send it to a translator that does not use MemoQ, GlobalSight or XTM, and some customer is going to say... but it's an XLIFF file why can't you work with it! And I'll be trying to explain him why it's not interoperable, and he'll summarize this as "Oh, so XLIFF is not really working then...".

I could go on and on on the dangers of developing concurrent similar formats, but I have no time for that.

The real long term solution for everybody is to make sure those XLIFF:doc features (most are excellent) are taken into account in 2.0 either in the core or as modules. And at some point XLIFF:doc v2 could be just a few additions on top of XLIFF 2.0. We might have been already close to that stage if all the energy spent on XLIFF:doc had been put on 2.0...

Cheers,
-yves

---------------------------------------------------------------------
To unsubscribe, e-mail: xliff-promotion-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: xliff-promotion-help@lists.oasis-open.org

xliff message