Re: [xliff] Namespace in modules

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

Yves, you are right that details such as the essential claims declaration would be best covered with a committee note. I am fine with the general statement re private namespaces.

Regarding the 3rd paragraph, I am fine with the wording. It seems clear that modules require a full spec increment, as a note would not be enough to modify the standard.

Notes might be eventually used to clarify and detail stuff mentioned in the spec. I would suggest to start work on a modules and profiles note early next year.

I would still suggest one small change.

The IPR mode and license of a proposed module MUST be compatible with the OASIS XLIFF TC IPR mode (RF on RAND terms) and conform to relevant OASIS license requirements and policies.

The reason for this rephrasing is that OASIS allows its committees to have several different and eventually incompatible IPR modes, so even the general text in the specification needs to be more specific. By requesting compatibility with *any* OASIS IPR mode, we would actually violate our charter that specifically states RF on RAND.

Cheers and weekend

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 Fri, Nov 9, 2012 at 6:08 PM, Yves Savourel <ysavourel@enlaso.com> wrote:

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



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