OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: csprd03 - ref attribute in Translation Candidate annotation


In the section "5.1.4 Translation Candidate Annotation" the ref attribute of the annotation is listed as optional and has several
issues:

a) It has no normative definition (both the note and example are non-normative). This means an agent doesn't know where the
reference can point to, nor what behavior it is suppose to have with the referred object.

b) The Translation Candidate module has its own reference mechanism and only needs a span marker in the content. The ref attribute
is never necessary for the module to work.

c) In fact, the ref attribute in the annotation is kind of conflicting with the module way of referencing, as DavidF noted during
the discussion leading to the decision to move the Translation Candidate annotation out of the core:

"dF: I don't feel strongly about having defined an mtc: annotation, it could be used eventually if there were no suitable marked
spans in the core and the Enricher should be able to insert its match even if there was no span available. If the annotation had a
ref, it would be in conflict with the mtc:ref."
(https://lists.oasis-open.org/archives/xliff/201401/msg00171.html)

d) the note states:

[[
In this annotation type, the XLIFF Core ref attribute is primarily intended to allow for referencing of translation candidate
resources or other relevant metadata that are external to the XLIFF Document.

The Translation Candidates module uses its own mtc:ref to reference its match spans in source content the other way round.
Implementers who are not using the Transklation Candidates Module and want to reference translation candidates provided by external
systems such as TM or MT services, will be better off with defining their own Custom Annotation than using the mtc:match type.
]]

The two paragraphs are contradictory: the second paragraph says that you shouldn't really do what the first paragraph says.

I strongly recommend to:
- remove completely the note
- remove any <mrk ref> attribute from the example,
- and replace the ref usage from "The ref attribute is OPTIONAL" to "The ref attribute is not used".


-yves




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]