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
dF
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:
On Thu, Dec 26, 2013 at 5:01 PM, Yves Savourel <> 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
