Re: ITS 2.0 / XLIFF 2.0 implementation

Hi Yves, all,

thanks a lot for the update. A few questions below.

1) Loalization Note: we probably have discussed this before, sorry for asking: there is a mapping to XLIFF 1.2 „note“ element
https://www.w3.org/International/its/wiki/XLIFF_1.2_Mapping#Localization_Note
what is the reasons for not using that mapping for the XLIFF 2.0 „note“
http://docs.oasis-open.org/xliff/xliff-core/v2.0/xliff-core-v2.0.html#note

2) About „terminology“ the warning
"WARNING: TBD: the XLIFF 2 specification allow ref and value to be both set at the same time. ITS 2.0 does not allow an info and an info-ref to be set at the same time. So we have to decide something for this case.“ 
This sounds like an issue only for roundtripping, that is going from XLIFF to a document with ITS. So we could say that an implementation needs to make explicit what value will end up in the document with ITS.

3) Directionality
Since ITS 2.0 is basically saying „this is in flux“ we may drop it from the mapping?

4) Localization quality rating
It looks like this could be the same as LQI?

In general: should we set up repository on github etc. with input and output files (roundtripping xliff <> ITS) for implementers?

- Felix


Am 24.08.2014 um 15:55 schrieb Yves Savourel <ysavourel@enlaso.com>:

> Hi all,
>  
> Here is an update on the current status of the Okapi implementation of the mapping of ITS 2.0 in XLIFF 2.0:
>  
> As you may recall, the data categories are classified into several types:
>  
> - Existing in XLIFF
> - Partially Covered in XLIFF
> - Represented using ITS Itself
> - Not Representing Metadata
>  
> Note that several data categories have not been mapped at all yet:
> http://www.w3.org/International/its/wiki/XLIFF_2.0_Mapping#Data_Categories_Not_Mapped_Yet
>  
> The library aims at implementing only the data categories that are partially covered in XLIFF or the ones represented using ITS itself. The ones existing in XLIFF are simply accessible through the normal XLIFF API, and the ones not representing metadata are just not useful in an XLIFF API.
>  
> Currently the library implements:
>  
> - Domain
> - MT Confidence
> - Terminology
> - Text Analysis
> - Provenance(*)
> - Localization Quality Issue(*)
>  
> *: Both Provenance and LQI have some restriction currently: stand-off notation is supported within units only.
>  
> In addition, currently, the standoff notations are processed so they are assigned to their referrers directly. That is once the reference is parsed the data exist in that object but not as a separate standoff object anymore. This cause the fragment identification function to not find them if you try (because they are not standoff anymore: they are parsed and assigned to the objects they were applied too). I’ll have to refactor this to work with some kind of backing store and indirect access from the referencing objects. That, hopefully, would be transparent from the caller of the API.
>  
> As usual you can get the library here:
> http://okapi.opentag.com/snapshots/okapi-xliffLib_all-platforms_1.0-SNAPSHOT.zip
>  
> The Java documentation is here:
> http://okapi.opentag.com/xlifflib/javadoc/
>  
> And all the project’s information here:
> https://code.google.com/p/okapi-xliff-toolkit/
>  
> Feedback and bug reports are welcome.
>  
> Thanks,
> -yves