[xliff] XLIFF inline tags

As a tools developer, I'm a 
little concerned over the functionality of the inline tags available in XLIFF. 
Sleep deprivation (thank you son) means that I may forget later so I thought 
that I'd raise this now. I apologise 
that this has come so late in the day but it was only the recent discussion on 
the <bin-unit> problem that prompted me to re-visit these tags. I accept that this is tool late for V1.1 but perhaps 
we can discuss this for the next version ...

 

First of all, I'm not clear why <bx/> and <ex/> are required. As far as I can make out, they are functionally 
equivalent to <bpt></bpt> and <ept></ept> (i.e. empty elements). John may be able to set me straight on this. 
If this is the case then at least I'll know what to do with them in my parser. 
However, having extra elements for the sake of it doesn't make my life any 
easier.

 

Secondly, I don't think that I'm given sufficient freedom of choice 
for my mark-up style. I believe that <g> and <bpt> are supposed to be functionally equivalent. However, 
<g> gives me the ability to "clone" whereas <bpt> gives me the option of an "rid" and a "crc". A similar case applies 
to <x/> and <ph>; I can "clone" an <x/> but <ph> lets me specify a "crc" and an "assoc". In fact, 
<x/> also has to do the job of <it> but doesn't have the option of a "pos" attribute (it would also 
need an attribute to indicate what role it's playing; <ph> or <it>).

 

Thirdly, I'd also be interested to hear views on sub-sentence 
alignment and the role of the "id" and "rid" attributes. Take, for example, the 
following snippet of HTML and it's translation in to French:

 

<p>The 
<b>black</b> 
<i>cat</i></p>

<p>Le 
<i>chat</i> 
<b>noir</b></p>

 

When filtered 
in to XLIFF, we have the following possibilities (depending on mark-up 
style).

 

<source>The 
<g id="1" ctype="bold">black</g> <g id="2" 
ctype="italic">cat</g></source>

 

<source>The 
<bpt id="1" ctype="bold">&lt;b&gt;</bpt>black<ept 
id="1">&lt;/b&gt;</ept> <bpt id="2" 
ctype="italic">&lt;i&gt;</bpt>cat<ept 
id="2">&lt;/i&gt;</ept></source>

 

Is there than an implicit requirement to match up the formatting in 
the target or should we be looking to use the "rid" attribute to do this? SDLX 
traditionally matches up the <g> tags by "id" but, in TMX (the origin of <bpt> et al), 
there's no requirement to do this and there is available an "x" attribute to 
achieve this goal.

 

My logic would suggest that the following translations 
are correct:

 

<target>Le 
<g id="2" ctype="italic">chat</g> <g id="1" 
ctype="bold">noir</g></target>

 

<target>Le 
<bpt id="2" ctype="italic">&lt;i&gt;</bpt>chat<ept 
id="2">&lt;/i&gt;</ept> <bpt id="1" 
ctype="bold">&lt;b&gt;</bpt>noir<ept 
id="1">&lt;/b&gt;</ept></source>

 

However, are there any restrictions in XLIFF to prevent 
me from having the following as translations? (Note that "id" 
numbers)

 

<target>Le 
<g id="1" ctype="italic">chat</g> <g id="2" 
ctype="bold">noir</g></target>

 

<target>Le 
<bpt id="1" ctype="italic">&lt;i&gt;</bpt>chat<ept 
id="1">&lt;/i&gt;</ept> <bpt id="2" 
ctype="bold">&lt;b&gt;</bpt>noir<ept 
id="2">&lt;/b&gt;</ept></source>

 

I thought that perhaps this was what the "rid" attribute was for (to 
match up the formatting between source and target). I'd rather avoid having to 
deal with the second situation in my parsing, as I then need to work out exactly 
which source formatting corresponds to which target formatting. In the case 
above, I could possibly use the "ctype" to match them up but that's not a 
mandatory attribute so it's not always possible. I also don't relish the 
prospect of fetching out the content of <bpt> and trying to use that!

 

As I said, I 
don't expect anything to get resolved for V1.1. However, I'd like to see some 
clarification of inline mark-up in the next version (V1.2 / V2.0?). The 
currently available options are adequate for my own filtering (I'll stick to the 
OpenTag tags that I know and love) but I'd really like to provide an XLIFF 
editing environment for files that come from other sources and I don't feel that 
the current specification is helping as much as it 
could.

 

David 
Pooley

Software 
Architect

SDL International

**********************************************************************

This email and any files transmitted with it are confidential and

intended solely for the use of the individual or entity to whom they

are addressed. If you have received this email in error please notify

the system manager.

This footnote also confirms that this email message has been swept 

for the presence of computer viruses.

**********************************************************************