[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xliff] Extensions in segments / Extended attributes in mrk
> -----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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]