Re: [xliff] XLIFF 2.0 spec - dF Issue #01 - Extensibility and processing requirements

["Dr. David Filip" <David.Filip@ul.ie>]

Rodolfo, this is a good point that should be considered for a set of special PRs pertaining to matches overriding the general protection of modules.

While it makes sense to delete matches before merging, it does not make sense to delete them before translation. Even if you are reading the matches into an accompanying TMX, or sucking them into your proprietary TM, this should not be a valid reason for deleting the matches, as tools downstream including the merger/extractor might still need them, e.g. for review, engineering checks, editing distenace checks etc. 

We should say something like

Matches for a source element MUST NOT be trimmed until its target element is populated with translation.

Matches for a source element SHOULD NOT be trimmed until its target element is marked final.

If the merger wants to be able to delete matches before merging it should at least understand the above PRs.

It is quite common with corporate merging tools that they are checking status of targets before performing merge  and If they want to send an XLIFF failing final target critreia back to the service provider the matches will still be useful.

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

mailto: david.filip@ul.ie

On Tue, Nov 6, 2012 at 12:20 PM, Rodolfo M. Raya <rmraya@maxprograms.com> wrote:

Hi,

I tend to agree with Yves, it should be possible to discard non-core data.

Let me give you an example: an XLIFF file with 10,000 segments is not unusual these days; after being fully translated and populated with TM and MT matches the file may become 10 times larger than it was originally. Removing all matches before merging can reduce the size of the file to one third and improve merging speed considerably. TM and MT data is not required for merging and is useless after all translations are marked as final.  I recently saw a good case: original XLIFF (source only) had 1.5MB; full file (translations + TM data) was 27MB; trimmed file (source and target only) 2.5MB. Merging 2.5MB was much faster than merging 27MB.

Regards,
Rodolfo
--
Rodolfo M. Raya       rmraya@maxprograms.com
Maxprograms       http://www.maxprograms.com

> -----Original Message-----
> From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf
> Of Yves Savourel

> Sent: Tuesday, November 06, 2012 10:02 AM
> To: xliff@lists.oasis-open.org
> Subject: RE: [xliff] XLIFF 2.0 spec - dF Issue #01 - Extensibility and processing
> requirements
>

> Hi David, all,
>
> > - A user agent that does not support a given module element or
> > attribute MUST preserve it, except when a core processing requirement
> > specifies otherwise.
>
> It makes no sense to me that an optional module MUST be preserved. It's
> not optional anymore.
>
> Furthermore, if core-only tools cannot remove a module, I assume the tools
> aware of the module can. So we would have the absurd situation where a
> tool that doesn't support module ABC must preserve it, but the tool XYZ that
> supports that module can remove it.
>
> > Module data are not essential in the same way as core, but unlike
> > extensions they are the essential and only possible way how to cover
> > their specific functionality.
>
> That doesn't make them special. I want tools to be able to get rid of any non-
> core constructs if they see a need for it.
> The reason you listed for tools to get rid of the elements of a custom
> namespace are just as valid for the elements of a module.
>
> As the PRs I've posted earlier illustrate, you can treat all non-core elements
> exactly the same when doing for example re-segmentation. Why create an
> artificial difference (that would actually require more work)?
>
> The distinction between modules and custom namespaces exists:
>
> - modules always have a schema.
> - modules are documented and backed by the TC.
> - modules could exist in places extensions could not.
>
> Those are all incentives for tool vendors to migrate their extensions to
> modules.
>
> Regards,
> -yves
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: xliff-help@lists.oasis-open.org



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