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

[Yves Savourel <ysavourel@enlaso.com>]

Hi David,

I see that your main argument is not a technical one: We should encourage people to treat custom extensions as second class citizens because they undermine the idea of normative modules.

But I think this is the wrong way to look at it:

Extensions do not undermine the whole idea of normative modules. They are part of the whole idea. Official modules are not going to be just appear out of thin air. They'll start as extensions, get tested, be improved, as they are used as extensions. Then they'll migrate to become official.

I don't think it would be good to see company XYZ come to the TC and say: "Here is a proposal for a module." And have the TC (which has very little bandwidth), have a quickly look at it and say "OK, let's add it". We need real feedback, real implementations, real users looking at and using the module. And the most natural way to have all that is through extensions.

In order to have such evolution, they need to have the same processing requirements as a module.

Some extensions may end up becoming modules without even changing their namespaces, as we want to promote re-use and interoperability. Parts of ITS are possible examples of this.

I'm OK with "SHOULD NOT be deleted" rather than a "MUST be preserved" (the 'must' come from the discussion the TC had not directly from me). But, regardless what the processing requirements end up being, they must apply to both modules and extensions. Otherwise XLIFF is detrimental to users who want to make their needs/solutions evolve into official modules.

Sure, not all extensions will become modules, but we can't control that. What we can control is the basic behavior that all tools should have when manipulating elements/attributes of namespaces they don't know.

Cheers,
-yves