OASIS XML Localisation Interchange File Format (XLIFF) TC

Hi all, To echo on David's note here: https://lists.oasis-open.org/archives/xliff/201210/msg00087.html ("...But I believe that the markers should remain fully extensible for annotations of various kinds that we cannot foresee.") This is Currently we do not allow non-XLIFF attribute in <mrk> (and <sm>). Like David, this is the one inline element where I think we should. There is a defined way of setting custom annotation using you own type and the ref/value attribute. But this system has an important drawbacks: The first issue is that it limits the information you can set to one per mrk. And in quite a few cases this is not enough. A work around that is to point to some outside element using ref (e.g. at the unit level) and place there all the information you need. But there is a problem with that too: when using an existing vocabulary you have to stick with its semantics and scope, and 99% of the time the scope of the attribute applies to the element where it resides, not to the element which points to the element where it resides. To describe this more simply: there are use cases in ITS and other vocabularies where you simply cannot map the set of information you would like using mrk with just ref/value. The only way is to allow extended attributes in mrk. Some use cases are listed in the wiki page where the MulitilingualWeb-LT WG is trying to map ITS to XLIFF: http://www.w3.org/International/multilingualweb/lt/wiki/XLIFF_Mapping Having extended attributes in mrk is probably a lot easier to deal with than dealing with elements at the segment level, so I don't think it add a big burden to the implementers. For the question of having extended elements in <segment> I would tend to agree with Rodolfo and David: the least elements we have at that level the better, for example for re-segmentation can be done more easily. Cheers, -yves

Hi all, I want to stress the importance and urgency of deciding on the extensibility of the markers. @Bryan, could you please make it an agenda item on 6th November? Yves agreed to to drive the resolution of this item in the meeting if possible. @All, please do express opinions, pros and cons prior to the TC discussion. Unfortunately, I cannot make the teleconf on 6th due to some urgent fatherly duties that cannot be delegated, so this is also my regrets for the meeting.. Best regards dF On Oct 29, 2012 1:35 PM, "Yves Savourel" < ysavourel@enlaso.com > wrote: Hi all, To echo on David's note here: https://lists.oasis-open.org/archives/xliff/201210/msg00087.html ("...But I believe that the markers should remain fully extensible for annotations of various kinds that we cannot foresee.") This is Currently we do not allow non-XLIFF attribute in <mrk> (and <sm>). Like David, this is the one inline element where I think we should. There is a defined way of setting custom annotation using you own type and the ref/value attribute. But this system has an important drawbacks: The first issue is that it limits the information you can set to one per mrk. And in quite a few cases this is not enough. A work around that is to point to some outside element using ref (e.g. at the unit level) and place there all the information you need. But there is a problem with that too: when using an existing vocabulary you have to stick with its semantics and scope, and 99% of the time the scope of the attribute applies to the element where it resides, not to the element which points to the element where it resides. To describe this more simply: there are use cases in ITS and other vocabularies where you simply cannot map the set of information you would like using mrk with just ref/value. The only way is to allow extended attributes in mrk. Some use cases are listed in the wiki page where the MulitilingualWeb-LT WG is trying to map ITS to XLIFF: http://www.w3.org/International/multilingualweb/lt/wiki/XLIFF_Mapping Having extended attributes in mrk is probably a lot easier to deal with than dealing with elements at the segment level, so I don't think it add a big burden to the implementers. For the question of having extended elements in <segment> I would tend to agree with Rodolfo and David: the least elements we have at that level the better, for example for re-segmentation can be done more easily. Cheers, -yves --------------------------------------------------------------------- To unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org For additional commands, e-mail: xliff-help@lists.oasis-open.org

re-sending from the proper e-mail address.. ---------- Forwarded message ---------- From: "David Filip" < davidf@davidf.org > Date: Nov 2, 2012 2:14 AM Subject: Re: [xliff] Extensions in segments / Extended attributes in mrk To: "Yves Savourel" < ysavourel@enlaso.com > Cc: < xliff@lists.oasis-open.org > Hi all, I want to stress the importance and urgency of deciding on the extensibility of the markers. @Bryan, could you please make it an agenda item on 6th November? Yves agreed to to drive the resolution of this item in the meeting if possible. @All, please do express opinions, pros and cons prior to the TC discussion. Unfortunately, I cannot make the teleconf on 6th due to some urgent fatherly duties that cannot be delegated, so this is also my regrets for the meeting.. Best regards dF On Oct 29, 2012 1:35 PM, "Yves Savourel" < ysavourel@enlaso.com > wrote: Hi all, To echo on David's note here: https://lists.oasis-open.org/archives/xliff/201210/msg00087.html ("...But I believe that the markers should remain fully extensible for annotations of various kinds that we cannot foresee.") This is Currently we do not allow non-XLIFF attribute in <mrk> (and <sm>). Like David, this is the one inline element where I think we should. There is a defined way of setting custom annotation using you own type and the ref/value attribute. But this system has an important drawbacks: The first issue is that it limits the information you can set to one per mrk. And in quite a few cases this is not enough. A work around that is to point to some outside element using ref (e.g. at the unit level) and place there all the information you need. But there is a problem with that too: when using an existing vocabulary you have to stick with its semantics and scope, and 99% of the time the scope of the attribute applies to the element where it resides, not to the element which points to the element where it resides. To describe this more simply: there are use cases in ITS and other vocabularies where you simply cannot map the set of information you would like using mrk with just ref/value. The only way is to allow extended attributes in mrk. Some use cases are listed in the wiki page where the MulitilingualWeb-LT WG is trying to map ITS to XLIFF: http://www.w3.org/International/multilingualweb/lt/wiki/XLIFF_Mapping Having extended attributes in mrk is probably a lot easier to deal with than dealing with elements at the segment level, so I don't think it add a big burden to the implementers. For the question of having extended elements in <segment> I would tend to agree with Rodolfo and David: the least elements we have at that level the better, for example for re-segmentation can be done more easily. Cheers, -yves --------------------------------------------------------------------- To unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org For additional commands, e-mail: xliff-help@lists.oasis-open.org

re-sending from the proper e-mail address.. ---------- Forwarded message ---------- From: "David Filip" < davidf@davidf.org > Date: Nov 2, 2012 2:14 AM Subject: Re: [xliff] Extensions in segments / Extended attributes in mrk To: "Yves Savourel" < ysavourel@enlaso.com > Cc: < xliff@lists.oasis-open.org > Hi all, I want to stress the importance and urgency of deciding on the extensibility of the markers. @Bryan, could you please make it an agenda item on 6th November? Yves agreed to to drive the resolution of this item in the meeting if possible. @All, please do express opinions, pros and cons prior to the TC discussion. Unfortunately, I cannot make the teleconf on 6th due to some urgent fatherly duties that cannot be delegated, so this is also my regrets for the meeting.. Best regards dF On Oct 29, 2012 1:35 PM, "Yves Savourel" < ysavourel@enlaso.com > wrote: Hi all, To echo on David's note here: https://lists.oasis-open.org/archives/xliff/201210/msg00087.html ("...But I believe that the markers should remain fully extensible for annotations of various kinds that we cannot foresee.") This is Currently we do not allow non-XLIFF attribute in <mrk> (and <sm>). Like David, this is the one inline element where I think we should. There is a defined way of setting custom annotation using you own type and the ref/value attribute. But this system has an important drawbacks: The first issue is that it limits the information you can set to one per mrk. And in quite a few cases this is not enough. A work around that is to point to some outside element using ref (e.g. at the unit level) and place there all the information you need. But there is a problem with that too: when using an existing vocabulary you have to stick with its semantics and scope, and 99% of the time the scope of the attribute applies to the element where it resides, not to the element which points to the element where it resides. To describe this more simply: there are use cases in ITS and other vocabularies where you simply cannot map the set of information you would like using mrk with just ref/value. The only way is to allow extended attributes in mrk. Some use cases are listed in the wiki page where the MulitilingualWeb-LT WG is trying to map ITS to XLIFF: http://www.w3.org/International/multilingualweb/lt/wiki/XLIFF_Mapping Having extended attributes in mrk is probably a lot easier to deal with than dealing with elements at the segment level, so I don't think it add a big burden to the implementers. For the question of having extended elements in <segment> I would tend to agree with Rodolfo and David: the least elements we have at that level the better, for example for re-segmentation can be done more easily. Cheers, -yves --------------------------------------------------------------------- To unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org For additional commands, e-mail: xliff-help@lists.oasis-open.org

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. 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. Regards, Rodolfo -- Rodolfo M. Raya rmraya@maxprograms.com Maxprograms http://www.maxprograms.com >
Original Message----- > From: xliff@lists.oasis-open.org [ mailto:xliff@lists.oasis-open.org ] On Behalf > Of Yves Savourel > Sent: Monday, October 29, 2012 11:36 AM > To: xliff@lists.oasis-open.org > Subject: [xliff] Extensions in segments / Extended attributes in mrk > > Hi all, > > To echo on David's note here: > https://lists.oasis-open.org/archives/xliff/201210/msg00087.html > > ("...But I believe that the markers should remain fully extensible for > annotations of various kinds that we cannot foresee.") > > This is Currently we do not allow non-XLIFF attribute in <mrk> (and <sm>). > Like David, this is the one inline element where I think we should. > > There is a defined way of setting custom annotation using you own type and > the ref/value attribute. But this system has an important drawbacks: > > The first issue is that it limits the information you can set to one per mrk. And > in quite a few cases this is not enough. A work around that is to point to > some outside element using ref (e.g. at the unit level) and place there all the > information you need. But there is a problem with that too: when using an > existing vocabulary you have to stick with its semantics and scope, and 99% > of the time the scope of the attribute applies to the element where it > resides, not to the element which points to the element where it resides. > > To describe this more simply: there are use cases in ITS and other > vocabularies where you simply cannot map the set of information you would > like using mrk with just ref/value. The only way is to allow extended > attributes in mrk. > > Some use cases are listed in the wiki page where the MulitilingualWeb-LT WG > is trying to map ITS to XLIFF: > http://www.w3.org/International/multilingualweb/lt/wiki/XLIFF_Mapping > > Having extended attributes in mrk is probably a lot easier to deal with than > dealing with elements at the segment level, so I don't think it add a big > burden to the implementers. > > For the question of having extended elements in <segment> I would tend to > agree with Rodolfo and David: the least elements we have at that level the > better, for example for re-segmentation can be done more easily. > > Cheers, > -yves > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: xliff-help@lists.oasis-open.org

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

>
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

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

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