AW: ITS/XLIFF Mapping - segment mrk vs non-segment mrk

 Hi Yves, all,

I am wondering what the effect of the categorization as a (non) segment on current implementations would be, like the Tilde xliff terminology annotation. Any thoughts?

Best, 

Felix

-------- Ursprüngliche Nachricht --------
Von: Yves Savourel <ysavourel@enlaso.com> 
Datum:  
An: public-i18n-its-ig@w3.org 
Betreff: ITS/XLIFF Mapping - segment mrk vs non-segment mrk 
 
Hi all,

In mapping document we recommend to use <mrk> to place several of the data categories. In several cases we need to decide whether it
includes the <mrk> representing segment boundaries or not.

For example for MT Confidence it does (and it is exclusively that one), but what about Localization Note (technically one can have
<mrk mtype='seg' comment='...'>), LQI, Allowed Characters, etc. basically any of the data categories we allow in <mrk> and where we
don't use mtype.

I think it may be important to mention the distinction (if there is one) as the two type of mrk elements are likely to be treated
very differently when a tool reads the document: the objects to store a segment and the objects to store a inline marker may be very
different and require separate implementations.
Writing out the two types is also different.

I went through all the data categories for which we had some mapping currently to mrk and noted below if technically they could or
not hold the mapping for the given data category:

- Translate: cannot be in segment-mrk
- Terminology: cannot be in segment-mrk
- Text Analysis: cannot be in segment-mrk
- Locale Filter: cannot be in segment-mrk
- Storage Size: probably does not make sense to have in segment-mrk

- Localization Note: could be in segment-mrk
- Domain: could be in segment-mrk
- Provenance: could be in segment-mrk
- Localization Quality Issue: could be in segment-mrk
- Allowed Characters: could be in segment-mrk

- Localization Quality Rating: depends
- MT Confidence: only in segment-mrk

Thoughts?

-ys

Received on Wednesday, 24 July 2013 05:46:34 UTC