RE: [xliff] 130 candidate annotation in Dec-17 Draft

[Yves Savourel <ysavourel@enlaso.com>]

Hi David, all,

> However, the situation is anyways strictly 
> analogical to the term annotation.
> The term annotation is to be used by the glossary module 
> to point back to the content, however the term annotation can 
> work without the glossary module for those who chose 
> not use the glossary module.

I think it's different.
Maybe it's simpler to look at it from the core viewpoint:

My test question for determining if an annotation type should be part of the core or not is: "Can this annotation with only its
required attributes be use just with the core elements?"

The answer is yes for the term annotation, the translate annotation and the comment annotation. But it is no for the translation
candidate annotation.

<mrk id='1' type='term'>text</mrk> by itself identifies 'text' as a term.

<mrk id='1' type='match'>text</mrk> by itself is useless.


> So the translation candidate annotation can work as a core 
> device for people who are not using the translation candidates 
> module, and want instead to point to leverage resources 
> external to the XLIFF document.

I would say those people should definitely use their own annotation type, so processors would know what kind of data the ref
attribute would point to, otherwise it'll useless. Since you are not defining it.

And yes, we do have that ref for the term annotation as well. And the target of the ref is as vague as for the translation candidate
annotation. But it has two aspects that are different:

- just displaying the information in the case of the term annotation is most likely useful, while in the case of applying a match
you would really need to know more that just the pointed content (i.e. you would need to know how to get the score info, the
source/target text, etc. from that content).

- The term annotation was in 1.2, not the translation candidate annotation. I don't think we ever discussed this feature, if anyone
request it, if anyone actually implemented it, etc.

As for ref in term, I would be fine with dropping the ref feature from the term annotation for 2.0. If we think it should be better
defined and just displaying the information is not be good enough for 2.0. But that is a separate issue from the translation
candidate annotation. And, the important point is that even without ref the term annotation would still be useful in core.



> When implementing the translation candidate annotation 
> I considered the option to define it in the module.
> However it seems bad design to me for a couple of reasons:
>
> - The analogy with term and glossary as explained above

IMO the analogy is not true all the way and doesn't stand the test question.


> - Module cannot define a core value, if the value was to 
> be defined in the module it would need to be an mtc: prefixed 
> value. This value would not be accessible for people who 
> want to use an external leverage resource, which 
> seems legitimate to me

As I said above, users who want to access some useful external reference mechanism should define it and use their own annotation
type. Otherwise if two different mechanisms are defined, how would you make a distinction and know which process to use?

Cheers,
-yves