Re: [xliff] Namespace in modules

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

Rodolfo, while I agree that some of this stuff should be reflected in the TC Charter (and in a working program charter if we had one), I believe that the current proposed wording (by Yves, including my IPR clarification) (re-pasted below) is the minimum on future modules that should be included in the spec itself.

People should find relevant information in one place and not be forced to search multiple documents to figure vital info about modules. Also it is useful as a reminder for any future maintainers of the spec. This module conception is key for 2.x versions backwards compatibility, as it will become very difficult to change (by design) as part of an OASIS standard. If this stuff was detailed in a note, which is not normative, or a working charter only (which is even not an official document), it is dead easy to change. If we on the other hand put too much into the TC Charter, we might inadvertently trigger rechartering..

I propose an electronic ballot on including the current final text developed in this conversation as the future modules provision in the 2.0 spec.

Looking for a second.

Ballot should go: Include the following (re-pasted below) text in spec (YES|NO) Comment prohibited 

Cheers

dF

==========

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 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.

==========

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 8:38 PM, Rodolfo M. Raya <rmraya@maxprograms.com> wrote:

Hi,

The third paragraph doesn't belong to the specification document. It describes a TC policy, best suited for our working charter, not the specification.

Fourth and last paragraphs should go to the main charter. They don't prescribe how to use the XLIFF format but are relevant for the charter to let outsiders know how to collaborate with the TC.

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: Friday, November 09, 2012 5:49 PM
> To: xliff@lists.oasis-open.org
> Subject: RE: [xliff] Namespace in modules
>

> Hi David,
>
> No problem with your text on IPR.
> So the latest updated text would be:
>
> ==========
>
> 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 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.
>
> ==========
>
> Like you I currently don't see how we could update the XLIFF schema to
> add/remove modules without changing the version. Using a note as Rodolfo
> seem not possible.
>
> But incrementing the version and republishing seems to be quite a
> complicated process too.
> I wonder if anyone else has ideas about that.
>
> -yves
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: xliff-help@lists.oasis-open.org



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