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] Cloning of <g> elements


Title: Message
Hi Magnus,
 
I believe that (a) is a reasonable assumption to make. If you don't carry across all the attributes (DNA?) of the original tag then would it really be a clone?
 
As I understand it, the cloning ability is there primarily to allow for formatting that needs to be split in the <target> element because the original text span has been split in the translation. For example:
 
<source>The <g id="1" ctype="bold">big black</g> cat.</source>
<target>The <g id="1" ctype="bold">gros</g> chat <g id="1" ctype="bold">noir</g>.</target>
 
I understand that you might want to clone the <source> tags in order to segment the original source text. Although I'm not overly familiar with the work of the segmentation subcommittee I would guess that you're looking to introduce something along the lines of <seg>....</seg> in the <source> element and that XML rules dictate that you're not allowed to have <seg>...<g>...</seg> so you'd be looking to replace this with <seg>...<g>...</g></seg><g> with the <g> being cloned (I have an HTML verifier which does something similar).
 
What makes me nervous is the fact that the <g> might not be "clonable" and that the original XLIFF filter wouldn't be able to handle multiple occurrences of a particular <g> tag. Is there a reason why it's not possible to simply use an empty <seg/> tag to indicate where the text should be segmented? This would mean that you wouldn't have to clone elements from the original <source> and also has the added advantage that this element can simply be ignored when the XLIFF file is merged later in the process.
 
FWIW, I think that an element would have to have an explicit clone="yes" before it can be cloned with confidence.
 
Regards
 
David Pooley
Software Architect
SDL International
 
 
-----Original Message-----
From: Magnus Martikainen [mailto:Magnus@trados.com]
Sent: Tuesday, January 25, 2005 11:13 PM
To: xliff
Subject: [xliff] Cloning of <g> elements

Hi all,

 

Following a discussion in the segmentation subcommittee today I took an action item to post a question to the main XLIFF committee requesting a clarification on how cloning of <g> elements should work.

 

As you may be aware, the <g> element has an optional attribute named clone, with a default value "yes". This implies that all <g> elements that do not have an explicit clone="no" attribute value may be cloned by any tool processing the XLIFF content.

 

This functionality is of special interest to the segmentation subcommittee, and our current work-in-progress proposal for representation of segments relies on the ability to clone <g> elements that span segment boundaries in order to be able to introduce segments.

 

For these reasons I would like to have the following assumptions confirmed:

a)       When a <g> element is cloned, all attribute values of the original <g> element, including the id and xid values, are replicated into the clone.

 

Example:

<source>Some <g id="1" ctype="bold" xid="42" ts="offset:983">marked-up</g> text.</source>

<target>Some <g id="1" ctype="bold" xid="42" ts="offset:983">translated</g> marked-up <g id="1" ctype="bold" xid="42" ts="offset:983">text</g>.</target>

 

 

b)      The current specification mentions that multiple copies of the source <g> element may be placed in the <target> content. For segmentation purposes we would also need to clone them inside <source>. Would this be a reasonable extension?

 

Whatever the outcome I would suggest that we update the XLIFF 1.1 specification to clarify how this mechanism is intended to work.

 

Best regards,

Magnus Martikainen



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