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

["Rodolfo M. Raya" <rmraya@maxprograms.com>]

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