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

Yves, let me react and explain

You are right that this annotation has been first introduced in reaction to prohibiting metadata on segment, i.e. between csprd01 and csprd02

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.

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.

When implementing the translation candiadate 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

- 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

So IMHO the translation candidate annotation is a valid core device that is independent of storage of candidates within the mtc module. I think that the core annotation together with the mtc module address the feature request documented in the wiki.

Thanks and regards

Dr. David Filip

=======================

LRC | CNGL | LT-Web | CSIS

University of Limerick, Ireland

telephone: +353-6120-2781

cellphone: +353-86-0222-158

facsimile: +353-6120-2734

http://www.cngl.ie/profile/?i=452

mailto: david.filip@ul.ie

On Thu, Dec 26, 2013 at 5:01 PM, Yves Savourel <ysavourel@enlaso.com> wrote:

Hi David, all,

To follow-up on issue 130.

This type of annotation didn't exist in the core of the cs02. It has been added between cs02 and cs03 I'm not sure why as it seems
it's not mentioned in either the wiki tracking or the list of changes in the document (I may have missed something though)

The Matches module should define what is used, not the core.

> Translation Candidates annotation is a core device for pointing to
> translation candidates analogical to the term annotation.
> It can be used by the module but really is independent of it, same
> as the term annotation is independent of the glossary module.

The case of the term annotation is completely different: it's used to denote terms and the reference to additional information is
only optional.

> This is the case especially after matches got their own ref for
> pointing back to core.

Actually having matches holding the ref shows an annotation is not even needed now as you can point directly to a segment (something
I don't like as it may result loosing information when you re-segment the content). By the way: the Matches section doesn't
explicitly say if you can or cannot do that, but no constraint forbid it and the wording technically allow it. (and obviously that
was one of the main point of Dave).

In general I don't think it's good to define module-specific metadata in the core. So far this annotation is the only one doing
that.

So I still strongly suggest to remove that section 4.7.3.1.3 and define the mtc:match as a type for <mrk> in the Matches module,
where IMO it belongs.

Side note: The example 4.3.1.22 has a match example, but doesn't use the latest Matches mechanism (ref from the match).

Cheers,
-yves

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

xliff message