> -----Original Message-----
> From: [mailto:]
> On Behalf Of Yves Savourel
> Sent: Friday, November 02, 2012 9:08 AM
> To:
> 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
Maxprograms http://www.maxprograms.com