OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [xliff] Metadata extensibility ballot

> -----Original Message-----
> From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] 
> On Behalf Of Yves Savourel
> Sent: Thursday, June 14, 2012 9:34 AM
> To: xliff@lists.oasis-open.org
> Subject: RE: [xliff] Metadata extensibility ballot
> I would argue that the case for a future-ready 2.0 is stronger than a 
> very- safe-but-very-limited 2.0. We need to define a 2.0 that will be 
> in full use 5-10 years from now. And namespaces are part of that picture.

A strong XLIFF 2.0 based on XLIFF defined elements only can be enhanced at any time in the future by publishing new modules as we see fit. 

If we allow third party namespaces, we lose control on XLIFF. If we control XLIFF, interested parties could come to us with proposals for new modules at any time. 

New modules don't need to be released as OASIS standards. If the TC accepts them, the can be released in a short cycle as TC specification or as TC note.

An XLIFF 2.0 that doesn't allow third party namespaces could be in full use in 5-10 years from now. There is no real need for allowing third party namespaces at the risk of huge interoperability problems like we see today due to bad implementations.

It is much better to have a controlled XLIFF 2.0 that we can enhance at any time than to have a standard that is born weak and dependent on third parties.

Rodolfo M. Raya       rmraya@maxprograms.com
Maxprograms       http://www.maxprograms.com

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]