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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

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


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


I don't think re-segmentation and annotation would be a problem; data can always be duplicated the worst case. However, I agree with your opinion in principle regarding annotation.




From:        Yves Savourel <ysavourel@enlaso.com>
To:        <xliff@lists.oasis-open.org>
Date:        12/26/2013 12:05 PM
Subject:        [xliff] 130 candidate annotation in Dec-17 Draft
Sent by:        <xliff@lists.oasis-open.org>




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




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