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

[Yves Savourel <ysavourel@enlaso.com>]

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