RE: [xliff] Namespace in modules

[Yves Savourel <ysavourel@enlaso.com>]

I think we agree David: 

Private namespaces cannot be used in a module, they have to be moved under a standardization body (including XLIFF TC) before/when the TC adopt the module.

Your sentence:
 
"Namespaces of private custom extensions promoted to official XLIFF modules must be replaced by OASIS XLIFF TC namespaces."

Is too limitative. It seems to indicate that the *only* way to migrate a private namespace to a "standard" that is acceptable in a module is to go through the TC, it doesn't monition the indirect way of using a different standardization body.


I think the solution is simply to state that private namespaces cannot be part of a module and let the interested parties figure out how to move to a namespace that is acceptable.

The text for the specification should simply state what a module is. Most of the "how" to create a module should probably reside in a note or some other document that describes the steps to migrate an extension to a module.

The same goes for the IPR text. I think we should just state that the IPR/License of a proposed module must be compatible with the OASIS IPR/License requirements and define what it means somewhere else.

So I would propose:

==========

A module is an optional set of XML elements and attributes that stores information about a process applied to an XLIFF document and the data incorporated into the document as result of that process.

Each module is defined in a section of the XLIFF specification. The schemas of the XLIFF core or modules indicate where the elements and attributes of each module can be used. Modules can generally be placed in locations that are not extension points, with some restrictions, for example module elements are not allowed inside <source> or <target> elements.

Each version of XLIFF has a fix set of modules. Adding or removing one or more modules from the latest version of XLIFF requires to increment the version of XLIFF.

A module MUST use namespaces of only final specifications from OASIS (including the ones produced by the XLIFF TC) or from other established standardization bodies such as the World Wide Web Consortium (W3C), the European Telecommunications Standards Institute (ETSI), the International Standards Organization, or the Unicode Consortium. Private custom namespaces MUST NOT be used in modules.

The IPR and license of a proposed module MUST be compatible with the OASIS IPR and license requirements and policies.

==========

But we still have not resolved the general issue about versions and how adding/removing a module affect the specification (third paragraph of the proposal).

Regards,
-yves