Hi Yves,
The (ugly) way <pc> could be used in Case 2 is as follows.
<segment>
<source>First <pc id='1'/>part. </source>
</segment>
<segment>
<source>Second part.<pc idref='1'/></source>
</segment>
I assume the reason you said we could not do it in your original sample was that each having the same ID would be due to the non-unique ID value. I agree. By using the id/idref pair you know that any <pc> with an id is essentially <sc>. And any <pc> with and idref is essentially <ec>. I cannot think of anything more that would be needed (other than the other stuff that would already be needed in <sc>/<ec>).
(note to self - careful - don't start to advocate the <pc> only approach)
- Bryan
-----Original Message-----
From: [mailto:] On Behalf Of Yves Savourel
Sent: Thursday, December 15, 2011 2:36 PM
To:
Subject: RE: [xliff-inline] XLIFF Inline Markup Subcommittee Teleconference - Dec-13-2011 - Summary
Hi Andrew, Bryan, all,
> Case 2 (10 percent), an inline starts in one segment
> and ends in a different segment
> <sc>/<ec> is good. <pc> is less good because it adds
> complexity (extra attributes representing start and
> end are ugly).
Just to be clear:
I'm for including <pc>, but it's important to underline that it cannot represent broken span-like codes at all. So in your case 2 here <pc> is not "less good" it's just not possible.
Or I'm missing something.
Here is a span-like code with <pc>:
<segment>
<source>First <pc id='1'>part. Second part.</pc></source>
</segment>
We cannot do something like this:
<segment>
<source>First <pc id='1'/>part. </source>
</segment>
<segment>
<source>Second part.<pc id='1'/></source>
</segment>
So how <pc> could represent such non-well-formed span?
(just trying to be sure we are all on the same page)
-yves
-yves
---------------------------------------------------------------------
To unsubscribe, e-mail:
For additional commands, e-mail:
