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

David,

We already have a bad experience of interoperability problems due to custom extensions. I don’t want to leave the door open to more problems.

As we agreed, we should not allow custom extensions inside segments. If that blocks custom extensions in inline elements, that’s fine for me.

XLIFF inline elements can be improved as needed to support all or most use cases. Add whatever attributes you think are important for the <mark> element and properly document them in our specification. Keeping custom extensions away from translatable parts may help reduce compatibility problems.

Regards,

Rodolfo

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

From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Dr. David Filip
Sent: Friday, November 02, 2012 9:58 AM
To: xliff@lists.oasis-open.org
Subject: Re: [xliff] Extensions in segments / Extended attributes in mrk

Rodolfo, all

while the urgency of this matter is partially connected to ITS 2.0 heading towards feature freeze [last call in W3C speak], the importance of the problem is generic.

ITS is just an example of annotations that will need the markers to extend.

As Yves points out, not allowing extensions on mrk prevents evolution of annotation modules.

I want to stress that we do not propose to allow custom elements within segment, we just talk about extensibility of markers using custom attributes to make markers a generally usable annotation mechanism.

As Yves mentioned, the goal is to have ITS mapping as a module at a later stage.

Disabling extensibility on markers [comparing with 1.2. mrk] would prevent new modules from entering at the inline level, which I think is quite bad.

No one wants to extend generic masking inlines, but the annotations are obviously a separate use case. We are talking very minimalistic extension mechanism, i.e. only attributes on two specific inline elements (<mrk>, <sm>). AND they MUST NOT compete with generic masking markup.

Cheers

Dr. David Filip

=======================

LRC | CNGL | LT-Web | CSIS

University of Limerick, Ireland

telephone: +353-6120-2781

cellphone: +353-86-0222-158

facsimile: +353-6120-2734

mailto: david.filip@ul.ie

On Fri, Nov 2, 2012 at 11:07 AM, Yves Savourel <ysavourel@enlaso.com> wrote:

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

---------------------------------------------------------------------
To unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: xliff-help@lists.oasis-open.org

xliff message