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

[Yves Savourel <ysavourel@enlaso.com>]

Hi Rodolfo,

> 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.

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>.


> I don't want to see custom extensions inside translatable text.
> The information that the ITS group needs can be stored outside <segment> 
> and linked to the appropriate content referencing "id" attributes 
> or by some other mechanism.

ITS has tried very hard to work around the limitation of <mrk> in 2.0, using such referencing mechanism, providing stand-off annotations and pointers to map the features.

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>.

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.

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.

Regards,
-yves