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: RE: [xliff-comment] Proposed changes to matches module


Title: RE: [xliff-comment] Proposed changes to matches module

Hi Dave, all,

 

+1 on having the id of inline codes unique within the unit (regardless of the other aspects of the proposal).

 

I believe this has been the intention. For example in the section about adding inline code there is the following PR: “The id value of the added code MUST be different from all id values in both source and target content of the unit where the new code is added.”

 

Cheers,

-yves

 

 

From: David.O'Carroll [mailto:David.OCarroll@ul.ie]

Sent: Monday, September 30, 2013 9:37 AM

To: David.O'Carroll; xliff-comment@lists.oasis-open.org

Subject: RE: [xliff-comment] Proposed changes to matches module

 

 

Hi all,

 

In accordance with my previous comment (see below) I would suggest changing the scope of the id attribute on inline markup. It is currently only unique at segment level. This does not support the current matches implementation or my suggested implementation of matches (which references inline markup ids from a unit level). I would suggest changing the scope of the id's uniqueness to unit level while preserving the statement "elements and inline elements with the same id in both source and target MUST be corresponding elements." (From the XLIFF 2,0 editors draft on mrk's id attribute).

 

Regards,

Dave

 

-----Original Message-----

From: David.O'Carroll [mailto:David.OCarroll@ul.ie]

Sent: Mon 9/30/2013 4:33 PM

To: xliff-comment@lists.oasis-open.org

Subject: [xliff-comment] Proposed changes to matches module

 

 

Hi all,

 

The current implementation of the matches module (i.e. where the source references the match using mrks) does not seem adequate. The only solution at the moment to handle multiple matches for a single source is to have nested mrk elements in the source with each one referencing a unique match.

 

I would suggest having the match reference the source instead. This can be achieved by adding two attributes to the match element; segRef and mRef. segRef is a URI pointing to the segment id that contains the source for the match. mRef is a URI pointing to some inline marker (mrk for a single segment and matching sm em tags for cross segment matching). It is required to have one and only one of segRef or mRef on the match element.

 

This solution means the source can remain intact in all cases where the segment is the source of the match. It also avoids having to use nested mrks in the source when multiple matches are available for a single source.

 

Regards,

Dave



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