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
Maxprograms http://www.maxprograms.com
> -----Original Message-----
> From: [mailto:] On Behalf
> Of Yves Savourel
> Sent: Monday, October 29, 2012 11:36 AM
> To:
> 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:
> For additional commands, e-mail:
