[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xliff] Extensions in segments / Extended attributes in mrk
Hi Rodolfo,
Yes we did.
> 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.
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>.
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.
> 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.
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
---------------------------------------------------------------------
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]