RE: [xliff] Namespace in modules

[Yves Savourel <ysavourel@enlaso.com>]

Hi David, Fredrik, all,

I think option 3 is fine.
I would just possibly reword one part of it from:

> Namespaces of private custom extensions (member submissions) promoted 
> to official XLIFF modules must be replaced by OASIS XLIFF TC namespaces.

To: 

Namespaces of private custom extensions MUST be replaced by namespaces from OASIS or another standardization body to be promoted to a module.

The rational:

- I simply no idea what "member submission" means here and it doesn't seem to add much to the text.
- Owners of private namespaces may prefer to 'standardize' their proposed namespace elsewhere than OASIS for whatever reason (e.g. membership they have, politics, whatever, re-usability, etc.)

Adding something about the IP right is also a good idea. I think Rodolfo voiced that concern at the last call.
I'm not sure how to word that though. Maybe something like:

Namespaces used in a module MUST have IP rights compatible with the IP rights of the XLIFF specification.


This would give us the following:

========

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 be placed in locations that are not extension points.

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. Namespaces of private custom extensions MUST be replaced by namespaces from OASIS or another standardization body.

Namespaces used in a module MUST have IP rights compatible with the IP of the XLIFF specification. 

========


But I think we still have the 3rd paragraph to resolve. The wordings here reflect just what I currently think is the only way to add/remove module to the specification. But if there is another way that avoid publishing new version that would be great. I'm just not seeing other way.

Regards,
-yves



From: Estreen, Fredrik [mailto:Fredrik.Estreen@lionbridge.com] 
Sent: Thursday, November 08, 2012 4:42 AM
To: Dr. David Filip; Yves Savourel
Cc: xliff@lists.oasis-open.org
Subject: RE: [xliff] Namespace in modules

Hi David, 

I like your proposal 3. I do not think we should limit ourselves to a specific list, there are too many standards bodies out there. I see the requirement for final standard from recognized standards body as a guideline helping anyone wanting to create a module determine if it is likely the TC would accept such a module at least from the procedural / formal requirements point. And also as a guideline for the TC when reviewing a proposed module. As Yves has already pointed out in the original mail, acceptance of modules will still come down to a TC vote. But having clear guidelines on the non-technical parts should help the creation and review process. Without some agreed guidelines we are likely doomed to have the same discussion the next time the issue is raised.

One additional constraint I think we should consider, or at least discuss, for the modules is the IPR. I do not think it would be good, or possibly even allowed by OASIS, for us to accept external namespaces where the IP rights is incompatible with the IPR of OASIS and the XLIFF charter into an official module. It would probably make sense if the proposer include information on this with the module.

On the specific ITS usage, I do not see a problem using parts of ITS 2.0 once final in a module. 
 
Regards,
Fredrik Estreen

From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Dr. David Filip
Sent: den 7 november 2012 00:25
To: Yves Savourel
Cc: xliff@lists.oasis-open.org
Subject: Re: [xliff] Namespace in modules

Hi Yves, all, one alternative proposal 3 and a few comments inline..
Cheers
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 Tue, Nov 6, 2012 at 9:35 PM, Yves Savourel <ysavourel@enlaso.com> wrote:
Hi all,

I had the action item to specify a proposal regarding the namespace in modules:

=== first, some background:

Currently the part of the draft defining a module says this:

"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 official module defined for XLIFF 2.0 has its grammar defined in an independent XML Schema with a separate namespace."

Based on that:

-1 there is no restriction on what the namespace of the module is.
-2 It doesn't say you can use several namespaces, like we do with matches or glossary for example (where we use the XML and the core namespaces), so technically we could biker about the existing modules.
-3 it doesn't say any think about the version of the core and the modules
-4 it doesn't say anything about where modules could be set (so by default that could be anywhere).

The immediate concern I have is to make sure the ITS WG can map its metadata to XLIFF.
As it stands now, we cannot.

To be able to do it we would need either:

-A) That the <mrk> element allows extended attributes

-B) that we can for sure have a module allowing us to use ITS native markup in <mrk>

The solution A) is actually rather logical: <mrk> is where tools annotate the content, there is a limited mechanism in place that allows user-defined metadata to a certain extent, but it a bit like <metadata> for the element: it's not enough in several of our use cases.
The main problem with having extension at the segment level is about what to do with the data when re-segmenting. But in the case of <mrk> that problem does not occurs since it's an inline element.

But for various reason I think having a module instead is fine, and even probably better as it formalizes things a bit more.
I agree that module is better but the first step to that module should be anyway <mrk> and <note> extensibility. As any other new module that is not specified as module outright,  the modules will evolve from broadly adopted extensions.

So I want to make sure solution B) is doable. That in Dec-2013 when ITS 2.0 becomes a recommendation we can add a new module to XLIFF that simply uses the ITS native attributes.

The text we have currently is actually ok to achieve that, but as one could see this morning, that is not necessarily the opinion of everyone. So I want to make sure we have clear rules on how to add/remove modules in XLIFF.


=== A proposal:

So here is a possible text proposal for the section 1.1.3 entry "XLIFF Module". Maybe it should have a separate section, but that is not important:

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 be placed in locations that are not extension points.

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, even if no other part of the specification has changed.
I would remove ", even if no other part of the specification has changed" If nothing else the spec will need to specify place and order of the new module etc. 

-- Either 1: A module MUST use namespaces of only final specifications from OASIS (including the ones produced by the XLIFF TC), from the World Wide Web Consortium (W3C), from the European Telecommunications Standards Institute (ETSI), from ISO, or from the Unicode Consortium.

-- Or 2: A module MUST only use namespaces of final specifications. The owners of these namespaces MAY be OASIS or other organizations.
Alternative proposal 3:
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 Inetranational Standards Organization, or the Unicode Consortium. Namespaces of private custom extensions (member submissions) promoted to official XLIFF modules must be replaced by OASIS XLIFF TC namespaces.
 

=== and some comments on the proposal

- Adding a modules will require publishing a new version of XLIFF. Which is time consuming. I don't like that at all, but I don't see how otherwise make sure can modules evolve orderly. My concern is how much time will the TC take to add a new module.
This is also why I think both module and extensions have the same PRs for core-only tools: this allows time without preventing the extension-moving-to-modules to be impaired.
Any extension (including W3C ITS) should be protected by SHOULD rather than MUST until it becomes module, as only the committee process can ensure that it does not have harmful impact, and unlike module it can compete for functionality with other extensions. 

- I understand Fredrik's concern about not allowing "any" namespace as possibly used in extensions, but at the same time having a list is limitative: why only those organizations (whichever they end up being) have that privilege?
I'm really wondering if this restriction (the first option) is necessary: the TC is in charge of accepting or not the new modules, so it can refuse anything, including modules namespaces from those organizations.

What is important IMO is to state that one cannot refuse a namespace on the ground that only TC-defined namespaces are allowed. I've tried to capture this in the second option.
I made an alternative proposal that IMHO addresses Fredrik's, Yves' and hopefully also Rodolfo's concerns

I made the list of allowed standards bodies exemplary rather than enumerative. Yet I clearly stated that private namespaces must be replaced by TC defined namespaces when promoting an private extension (member submission) to module.


Regards,
-yves




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