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

["Schnabel, Bryan S" <bryan.s.schnabel@tektronix.com>]

Hi Yves, Christian, and SC,

> I'm guessing Bryan is very much in favor . . .
> What about others?

While we wait for the opinions others, I have a few thoughts. My lurking leads me to understand the options as (numeration added by me): 

> (1) <sc>/<ec> alone or (2) both <sc>/<ec> and <pc>?
. . . or (I thought I heard) (3) <pc> alone with attributes to also carry the load of <sc>/<ec>

And for the record, yes, I prefer (2) or (3), and I admit, have absolutely no love for (1).

One reason for disliking (1) is that I prefer clarity over brevity. I understand immediately what the <sc>, <ec>, and <pc> mean. If we eliminate <pc> and use <sc>'s and <ec>'s in a single span, we need to investigate the attribute id on each to know which goes with the other. Bur if we have a rule that <pc> is always used in a single span, and <sc>/<ec> is only used in cases where the code crosses spans, the nature of the code and the span could not be clearer.

And I don't think I agree with, or maybe just don't understand the first bullet under "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.

I don't think eliminating <pc> simplifies the implementation for the reason you give. In fact, I think if you have a well-formed <pc> with start and end tags, there could be no confusion about whether or not you had a pair in the segment; you would know you have a pair.

Finally, in my experience (processing documentation and firmware in and out of XLIFF), the need to cross segments has been a very rare corner case (i.e., we are picking the uglier representation to accommodate the more infrequent use case). This, of course, could be challenged by people who have experience to the contrary.

I very much agree that it would be very good to hear the opinions of others. 

Thank Yves and Christian for shedding further light on this important topic.

- Bryan

-----Original Message-----
From: xliff-inline@lists.oasis-open.org [mailto:xliff-inline@lists.oasis-open.org] On Behalf Of Yves Savourel
Sent: Friday, October 07, 2011 2:54 PM
To: xliff-inline@lists.oasis-open.org
Subject: RE: [xliff-inline] Representing information for the starting/ending/standalone parts

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



---------------------------------------------------------------------
To unsubscribe, e-mail: xliff-inline-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: xliff-inline-help@lists.oasis-open.org