Re: [xliff] Fragment Identification

Yves,

people can do to the XLIFF files what the specification allows to do, not to break the guaranteed interchange.

Of course, all sorts of other private things can be done with the XLIFF files.

However, If you do anything to the static structure of the document, you have to be able to roll it back. It is IMHO out of scope to describe this

We have the roundtrip requirement in the Conformance section and it has always been there.

e. XLIFF is a format explicitly designed for exchanging data among various Agents. Thus, a conformant XLIFF application MUST be able to accept XLIFF Documents it had written after those XLIFF Documents were Modified or Enriched by a different application, provided that:

The processed files are conformant XLIFF Documents,
in a state compliant with all relevant Processing Requirements.

The assumption is that an application must take back what it has previously created.

Currently this includes a possibly different dynamic or segment structure, codes or markers in the other equivalnet forms etc.

Changing file or groups structure is not defined ergo not allowed. It does not mean that you cannot in fact do it. but IF you do you have to undo it before continuing in the "public" roundtrip governed by the spec.

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: david.filip@ul.ie

On Mon, Dec 16, 2013 at 3:55 PM, Yves Savourel <ysavourel@enlaso.com> wrote:

Hi David,

> Yves, all allowed modifications are specified in the spec.

You can't possibly define all allowed operations in the specification.

Besides there is nothing in the specification that says "All allowed modifications are specified in this document", so I'm not going
to argue the point further.

> If someone wants to regroup files between xliff documents,
> it should be their private concern.

So is splitting one huge XLIFF documents into several ones to dispatch it to different translators (also a common operation). That's
not explicitly allowed in the specification either, but not being allowed to do it would be laughable.

My point is: Splitting or joining XLIFF documents is a relatively common operations that many tools support in 1.x. Why wouldn't
they be able to do the same with 2.0?

The requirement is that the merger need to get back its document.

The main issue with bundling is the identifier of the <file> element.
I'll answer Dave's email on that: UUIDs may not necessarily be the only solution.

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

xliff message