W3C home > Mailing lists > Public > public-i18n-its-ig@w3.org > October 2014

RE: [xliff] ITS scope with sm/em

From: Estreen, Fredrik <Fredrik.Estreen@lionbridge.com>
Date: Wed, 8 Oct 2014 16:41:05 +0000
To: Yves Savourel <ysavourel@enlaso.com>, XLIFF Main List <xliff@lists.oasis-open.org>, 'public-i18n-its-ig' <public-i18n-its-ig@w3.org>
Message-ID: <DE61C801D4C11842BC3FF36757FF3FC501A0DE3091@BIL-EXC11-01.corpnet.liox.org>
Hi Yves,

> Hi all,
> 
> Looking at the ITS mapping: In many case we put the ITS information on a
> marker (<mrk> element).
> 
> But such element can be represented by <sm/>...<em/> when it's
> overlapping another element.
> In that case the normal ITS scope mechanism can't work because it applies to
> the empty content of <sm/>, not the content between <sm/> and the
> corresponding <em/>.
> 
> We can have provision for this in the XLIFF module. But I'm not sure it's
> doable in the ITS rules, especially with inheritance when there are nested
> annotations.

This is an interesting problem and I doubt it is solvable in a general way without additional steps. It might be solvable when the <sm/> and <em/> is in the same segment, but I doubt it is in the case where they start and end in different segments (ie. different sibling trees).

One potentially workable solution would be to apply an XSLT transform on the XLIFF that merges all segments in each unit. Discards any non ITS carrying marker (to reduce risk of overlapping markers) and finally normalize the remaining markers to  the <mrk></mrk> spanning form. Since ITS information will likely be coming from and going to an XML source there should not be any overlapping markers at that stage as they would be difficult to represent in the source format. It is not guaranteed but we could declare that ill-formed. ITS global rules could then be evaluated against the transformed version. Admittedly not the most beautiful solution but I think it could work.

> I vaguely recall that such topic was discussed at some point in the ITS-WG no?
> Does anyone recall the outcome?
> 
> Cheers,
> -ys

Regards,
Fredrik Estreen
Received on Wednesday, 8 October 2014 16:42:02 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:11:31 UTC