Hi Yung,
> 1) Data type of score(similarity) and quality:
> * Is there any reason why the score should be an integer?
I suppose a real would be fine. We may want to force some precision (probably 2 decimals).
> 2) Score and quality?
> * I understand the points of having two attributes. However,
> our scoring logic all consider many factors including
> similarity, quality, content domains and types etc.
> The score for our case is a combination score, so we can
> list the suggestions clearly in the order of our preference.
We the same: a 'combined-score' that hold a value we can sort on.
It relates to Rodolfo's note about interpreting both similarity and quality together.
Maybe an attribute could be provided. The question then is : How does it work? Should it be required? What processing expectations should we attached to <match>?
If we have a required 'score' then how does it related to similarity and quality (and possibly other info like type)?
> 3) content-type, content-domain, match-type
> * Due to cross-file/type leverage, we need to deliver content-type
> (xml, html, properties, etc) and content domain. Do you think
> "origin" can be used for that purpose?
Not 'origin', to me 'origin' is more what system created the match. This would be more like the 'datatype' of 1.2
Lucìa was mentioning a possible 'category' for content-domain. Whatever the name, it seems that is something tool would use.
> * "type" requires a clearly defined list of values. For MT suggestions,
> translators should post-edit instead of translate. CATs may have
> specific features for MT suggestions. Therefore, XLIFF docs should
> use the same value in type attribute for MT suggestions.
+1
I'll try to update the wiki with all this feedback.
Keep it coming.
-ys
