Re: [xliff] ITS IG ACTION-56: Do write up of processing its+xliff files

Hi Yves and all,

this was a long weekend … and here is a first version of the section on handling ITS and XLIFF:

https://www.w3.org/International/its/wiki/XLIFF_2.0_Mapping#General_considerations_for_ITS_2.0_and_XLIFF

You will still see some „to be done“ marks. I was esp. not sure about the requirements for creating a global rule discussed here
http://lists.w3.org/Archives/Public/public-i18n-its-ig/2014Oct/0026.html
So comments and also direct edits are very welcome.

Cheers,

Felix

Am 12.11.2014 um 23:11 schrieb Felix Sasaki <felix@sasakiatcf.com>:

> Thanks for the feedback, Yves.
> 
> Am 12.11.2014 um 21:38 schrieb Yves Savourel <ysavourel@enlaso.com>:
> 
>> Hi Felix,
>> 
>>> to get this going I looked at the archives on what we discussed. 
>>> One question I have: in the wiki we say there are three types of 
>>> processors that use the information
>>> 
>>> . An XLIFF Extractor aware of both ITS and the ITS module for any 
>>> data coming from the original source document. 
>>> . An XLIFF Modifier aware of the ITS Module for data generated 
>>> during the life time of the XLIFF document. 
>>> . An XLIFF Merger aware of both the ITS Module and the ITS syntax if 
>>> any of that data is merged back into the translated document. 
>>> 
>>> Does the information need to be written differently for these or in 
>>> general?
>> 
>> I think it depends on each the data category:
>> 
>> - Always: The description of how the data category is coded in the ITS module (or mapped to other core/modules)
>> 
>> - The description of how to map existing annotations to XLIFF (if it's not obvious, for example: mention termInfoPoint for the value
>> attribute in a term annotation).
>> 
>> - The description of how to map the XLIFF data into the original document (if it's not obvious, for example the ref/value use case)
>> 
>>> About the information itself, I think we have two aspects:
>>> 
>>> 1) re-writing selected ITS attributes into the oasis namespace,
>>> with prefix "itsm" as a good practice.
>>> 
>>> 2) The handling of overlap as described in this thread
>>> http://lists.w3.org/Archives/Public/public-i18n-its-ig/2014Oct/0011.html
>> 
>> I think this second part should have its own sub-section because a) it applies to pretty much all data categories and b) it doesn't
>> concern XLIFF module processors per say: it's a 'pure-ITS' issue.
>> 
>> We could:
>> 
>> - describe the issue
>> - provide the algorithm to do the transformation
>> 
>> - if possible provide the XSLT to do the transformation? (maybe as a separate thing)
>> 
>> BTW, I'm not sure following the same outline as the other modules will work well for the ITS module.
>> As a user I'd like to see a single place to go get the information.
>> And see it per data category (regardless how it's done: mapped, mixed, using the ITS module)
> 
> This sounds like one separate section and the data category section refer to it. I will give that separate section a try, also the conversion.
> 
>> We would probably also need a section of the item:annotarorsRef.
> 
> Makes sense, I will try to do that too. Expect a draft by the weekend.
> 
> Best,
> 
> Felix
> 
>> 
>> Cheers,
>> -yves
>> 
>> 
>> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>

Received on Monday, 17 November 2014 14:42:28 UTC