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

["Rodolfo M. Raya" <rmraya@maxprograms.com>]

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