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

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

________________________________________
From: Yves Savourel [yves.savourel@gmail.com]
Sent: Saturday, October 08, 2011 12:14 PM
To: Schnabel, Bryan S
Subject: RE: [xliff-inline] Representing information for the starting/ending/standalone parts

Bryan: The email service provider for the mailing address I use for OASIS is having problems today. Could you copy my email to the list? Thanks.

=========

Hi Bryan, all,

> (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>

There is no option (3). We cannot represent spans segmented at the middle with <pc>...</pc> no matter what attributes it would carries.


> ...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.

Actually id and rid, but yes <sc> and <ec> are linked with a common ID value.

> But 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.

Each representations seems as clear as the other to me. But it's just me.

The bottom line is that all tools would have to handle both notations, not just one, because <pc> cannot be used in all cases. That means more code to write, to test, more chances of errors, more confusion. For end-users working directly with the XLIFF file in an editor that means always having to look for both notations: search and replaces, etc.

Another aspect that relates to Christian's note: I'm not sure how enforceable the use of <pc> over <sc>/<ec> can be done. Would we somehow see as invalid a document that uses <ec>/<sc> where it could use <pc>? That could prove very tricky to do.


> 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.

It simplifies the implementation because it reduces the number of things to implement. Let's assume <pc> is easier to deal with. You still must handle <sc>/<ec>. No matter how easier the <pc> case is, it always comes in addition to the <sc>/<ec> case.

> 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).

That probably depends on many factors: What formats, how complex is the formatting, how smart are the tools to put tags at each ends outside segments, etc. But the fact is <pc> cannot be always used. So to be compliant your tools will have to handle <sc>/<ec> no matter how rare their use is in your context.

I don't think we want to go the way of making <pc> and <sc>/<ec> distinct options, it would completely break re-usability and interoperability.

Note that I'm not necessarily in favor of dropping <pc>. But I understand Christian's viewpoint as I cannot argument against the fact that having it does make XLIFF more complex. And. So the question is really about what benefits <pc> brings and are they worth the drawbacks <pc> also carries.

Cheers,
-ys