RE: [xliff] Extensions in segments / Extended attributes in mrk

["Rodolfo M. Raya" <rmraya@maxprograms.com>]

> -----Original Message-----
> From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] 
> On Behalf Of Yves Savourel
> Sent: Friday, November 02, 2012 9:08 AM
> To: xliff@lists.oasis-open.org
> Subject: RE: [xliff] Extensions in segments / Extended attributes in 
> mrk

Hi Yves,

> > If I'm not wrong, during the face to face meeting we agreed on not 
> > allowing extensions at segment level. To me, that includes not 
> > allowing extension in <mrk> as well.
> 
> Yes we did.

Good, so I would like to respect that agreement.

> But the state of ITS has changed since. Now it is not possible to use 
> an ITS data category that has several information (e.g. several 
> attributes working
> together) without placing it in <mrk>.

That change happened outside XLIFF and outside OASIS. We are not tied to it.
 
> But at this time XLIFF 2.0 is the only use case for a number of 
> attributes that were a massive bloat for ITS. Such mapping cannot be 
> done using referencing and stand-off markup any more, as I was 
> explaining in my initial email on this thread. Hence, the request for providing extension in <mrk>.

The ITS group should find other mechanisms. 
 
> An alternative would be to have a module now for ITS that puts those 
> attribute in <mrk>. That would solve the ITS cases. I'm just not sure 
> that can be done within the timeframe set at Redmond.

If that's an official XLIFF module, I'll shut up and accept it. A module with proper schema and processing requirements is much better than a custom extension of whatever origin.

> Beyond ITS itself, this case also illustrate a problem of how 2.0 can 
> evolve: if we don't have extensions in <mrk> (a very logical place to 
> have user-defined metadata), there is no way to evolve from an extension to a module.

Custom extensions can evolve and become modules as long as they don't contradict the spirit of XLIFF 2.0 and don't re-implement things already defined by the standard. We said we won't allow custom extensions inside segments so thinking on putting extensions there may be a bad start. 

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