RE: [xliff-inline] Representing information for the starting/ending/standalone parts

[Yves Savourel <ysavourel@enlaso.com>]

Hi Christian,

>> ...have only a unique <ph> element with an optional
>> attribute that would indicate whether it represents a 
>> start, end or placeholder code...
>
> To my ears, the work with just one representation 
> sounds attractive.

Before we even get to discuss a single element representation :)
we would have to first contemplate the elimination of the <pc> representation.

I'm curious about the opinion of everyone.
I'm guessing Bryan is very much in favor of having it. (and it is in the list of requirements).
What about others?

<sc>/<ec> alone or both <sc>/<ec> and <pc>?

Here is a rough list of pros-cons I can thing of:

Pro of eliminating <pc>:

- It simplifies the implementation to a great extend: No need to find out if the code has a corresponding opening/closing in the same segment.

- it reduces our list of attributes, getting rid of all the ...Start and ...End like equivStart/equivEnd. So it's a bit simpler to write/read and implement.

Cons of eliminating <pc>:

- we don't implement the requirement 17 (should preserve span-like structurs (http://wiki.oasis-open.org/xliff/OneContentModel/Requirements#Shouldpreservespan-likestructures)

- it may makes life more complicated for XSLT-based processor.
(...Although I'm not 100% sure about this. Because having <pc> does not eliminate <sc>/<ec> since you can have span split by segments. So presumably XSLT-based tools will have to deal with <sc>/<ec> anyway).


More pros/cons anyone?

Cheers,
-ys