-
Type:
Sub-task
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 2.1_csprd01
-
Fix Version/s: 2.1_csprd02, 2.1_csprd04
-
Component/s: ITS Module
-
Labels:
-
Proposal:
-
Resolution:
I'm not sure how we can say that MT Confidence is supported in XLIFF:
The ITS specification does not have global pointer for that data category in ITS.
Isn't this a case similar to Localization Note where we can easily transfer the data into XLIFF, but technically, a ITS processor
cannot get the same result?
The Warning was already present in the csprd01 draft
http://docs.oasis-open.org/xliff/xliff-core/v2.1/csprd01/xliff-core-v2.1-csprd01.html#MT_Confidence
so no action is required to apply the CFD Resolution. Changing to no action..
Category was already partial overlap and the Warning about inaccessibility of Translation Candidates based MT Confidence by generic ITS Processors was already there in csprd01
http://docs.oasis-open.org/xliff/xliff-core/v2.1/csprd01/xliff-core-v2.1-csprd01.html#MT_Confidence
This has been reopened because of a new finding by Yves
http://markmail.org/thread/6kvjlbuuo3vczkfe
It seems to me the relationship between the 3 attributes matchQuality, its:locQualityRatingScore and its:mtConfidence is a bit confusing.
- According the specification both matchQuality can be used to represent its:locQualityRatingScore and its:mtConfidence.
One question that comes to mind is: What if you have both data categories set for a given <mtc:match>? How can matchQuality takes both values? (maybe the answer the third bullet?).
- There is a “[WIP]” marker (Work In Progress” I assume) that is at the end of this paragraph:
“The attribute locQualityRatingScore MUST NOT be used on <mtc:match>, where it maps to and from mtc:matchQuality unless in scope of mt-confidence annotatorRef [WIP].”
- I’m not sure I understand the constraint above: It seems to say matchQuality maps to mtConfidence if it’s within the scope of an annotatorRef for mt-confidence (and then we have to use locQualityRatingScore for locQualityRatingScore), otherwise matchQuality maps to locQualityRatingScore. Is that correct?
If so, it seems a recipe for a lot of problems: Some implementations may not support both MT Confidence and Localization Quality Scope.
I’m also not quite sure why two different ITS data categories values can map to the same XLIFF value: Is that means mtConfidence and locQualityRatingScore represent the same thing in ITS?
In the meeting 16th May 2017, we agreed that there are three possible solutions
1) keep looking for annotatorsRef to see which category is represented
2) reserve mtc:matchQuality for its:mtConfidence and represent rating score with the W3C namespace
3) use W3C namespace for both, encourage implementers to use the same score for its:mtConfidence and mtc:matchQuality
We also noted that this issue doesn't exist in core where both categories use the W3C ITS namespace.
Yves to get Felixe's opinion on whether 2 or 3 is better. TC fine with either.
We have consensus to go fpr option 2) based on this discussion
http://markmail.org/thread/u3k644ddhnon5b2m
This will be considered the approved solution unless dissent expressed by any TC member by Friday May 19, NOON UTC.
Implemented in prose and committed to SVN
To be printed on 19th May
Forgot to close before 4th PR.
This is CFD to resolve this issue as proposed in the section "Proposal"
i.e. with a Warning or Note highlighting that this is not accessible ITS Processors who are not XLIFF agents supporting the Translation Candidates module. The category remains a partial overlap category..
I will implement this solution unless challenged by January 24th 2017.