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

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

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