Re: [all] ITS to XLIFF Mapping

Hi David,

2012/10/14 Dr. David Filip <>

> Felix, this should be one of the main points of the public part of the
> meeting.
> I notified the Chair and the Secretary (Yves was on the call :-) that the
> external people (both from this group :-)) coming will open this.
> If we consolidate on a simple set of extension features, the namespace
> could be pushed as a module and so have better status than a private
> extension. The profile could become a co-published best practice note.
> Anyway, this is what I want to propose on Monday..
I won't be at the meting on Monday, but here is my input summarized:
1) having a way to express ITS metdata in XLIFF is good
2) what approach works best for this (a dedicated namespace, the ITS
namespace in XLIFF itself, something else) is something for the XLIFF TC to
3) No 2) would have been my input on Monday - from the ITS side, I think it
is helpful to have implementors on board. So far I can see Yves / Okapi,
and various people who might wrap Okaki (e.g. SOLAS). Having more
implementors who provide an additional basis library (=in addition to
OKAPI) might be helpful.



> Cheers
> dF
> Dr. David Filip
> =======================
> LRC | CNGL | LT-Web | CSIS
> University of Limerick, Ireland
> telephone: +353-6120-2781
> *cellphone: +353-86-0222-158*
> facsimile: +353-6120-2734
> mailto:
> On Sun, Oct 14, 2012 at 7:48 AM, Felix Sasaki <> wrote:
>> Hi Yves, all,
>> 2012/10/12 Yves Savourel <>
>>> Hi all,
>>> In Prague we discussed a bit about the need to have a common way to
>>> represent ITS data categories in XLIFF, and a possible best practice
>>> document on this.
>>> I've started a wiki page with some notes on mapping ITS data categories
>>> to XLIFF markup, it's here:
>>> Some parts of ITS can be mapped directly to existing XLIFF elements or
>>> attributes, other parts will need to use some form of extension. We should
>>> probably agree on a namespace for those and, once we have the mapping
>>> completed, create a schema for it to go with the table.
>>> Currently the Okapi libraries use its own namespace for the extensions,
>>> but we'll adjust this to the common one.
>>> How should we proceed?
>>> I suppose some of us can have a chat about this next week at
>>> Redmond/Seattle, but we probably want to have a thread on this in this
>>> mailing list. As long as it's correctly labeled people not affected can
>>> identify and skip those emails.
>>> What do you think Felix? Should I raise an issue so we can track this?
>> That would be useful - we can then use the issue name in the mail
>> subject, and people who are not working on this can skip it. Wrt "how to
>> proceed": although this is not a normative features of ITS 2.0, having test
>> files (generic XML / HTML5 / DocBook etc. in > XLIFF+ITS out) seems to be
>> quite useful. Maybe also for the roundtripping, though it seems there is a
>> n:1 mapping from the source format to XLIFF, e.g. all of these
>> <span its:translate=no">...
>> <code its:translate=no">...
>> would end up in
>> <mrk mtype="protected">
>> So should this be part of the or a different "real life usage" test suite?
>> On the "how to proceed" part: do we need to involve the XLIFF TC formally
>> here? By no means I am pushing for that (less formal = faster progress),
>> just asking. In terms of the actual work being done we already have many
>> people in both TCs, so that shouldn't be a problem. Nevertheless a timeline
>> might be good (with milestones like mapping definition, mapping test case
>> dev, mapping testing, etc.).
>> I won't be at the XLIFF TC meeting on Monday (flying in Monday evening to
>> Seattle), but in case it is helpful, you can let the TC people know that I
>> think such a mapping will be very useful.
>> Best,
>> Felix
>>> Cheers,
>>> -yves
>> --
>> Felix Sasaki
>> DFKI / W3C Fellow

Felix Sasaki
DFKI / W3C Fellow

Received on Sunday, 14 October 2012 09:15:48 UTC