OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]