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


In line with Rodolfo's point here, is there any reason why the TC cannot consider adopting the ITS recommendations wholesale as a standard module in the future? If we expect ITS to produce standard guidelines, then why opt for the custom namespace integration angle, which offers no guarantee of interoperability?


-----Original Message-----
From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Rodolfo M. Raya
Sent: Thursday, June 14, 2012 5:55 AM
To: xliff@lists.oasis-open.org
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.

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


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






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