[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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 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 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.
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.
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.
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 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.
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]