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

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

Hi Rodolfo,

I agree. The question on the table is *should* we handle all cases with a single element, or the pair set, or both?

This question seems to always make me jump on my soap box. But I'm beginning to feel that I'm making my case too strongly and too often, and that I'm the only one who has strong feelings about the need to preserve a <pc> like options. So I'll state my philosophy one last time, then try to leave it alone.

My dislike for <sc>/<ec> goes back to my dislike for <bpt>/<ept>, especially when the practice of escaping XML code was involved. Perhaps it is my flaw, but that just strikes me as an XML hack. That said, I can acknowledge that there ares some cases (like inlines that liberally span segments) where I just need to plug my nose and accept the <sc>/<ec> approach. But I agree, there are (somewhat ugly) ways of handing this without needing the pairs, but that's another case all together.

I get disheartened when we start talking about eliminating the elegant choice of <pc> and make all cases use the <sc>/<ec> pair, even in the majority use case where inlines do not span segments. 

I think the first time I noticed this was when TMX was going to propose something like:

<!ELEMENT Inline EMPTY>

That was to be the only option for inlines. Notice the lack of #PCDATA. So for easy XML-source inlines that do not cross segments (along with complex inlines that do span segments), one could not properly (form an XML philosophy) mark up an inline.

For example, even a simple inline like this:

<p>I <b>really </b>like playing guitar.</p>

One would only be allowed to use the ugly pair:

<tu>I <Inline id="a1" name="b"  />really <Inline idref="a1" />like playing guitar.</tu>

or even worse (from my point of view):

<tu>I <Inline id="a1" syntax="&lt;b&gt;"  />really <Inline idref="a1" syntax="&lt;/b&gt;"  />like playing guitar.</tu>

Instead of the nicer:

<tu>I <Inline  name="b">really </Inline>like playing guitar.</tu>

It would take something like <!ELEMENT Inline (Inline|#PCDATA)> to do the latter (forgive me if my DTD-speak is faulty).

So my bottom line, if this only bugs me, and everyone else doesn't mind, then its time for me to fall in line, and get off my soap box.

Thanks,

Bryan
(steps off soap box)
(or perhaps the response should be "nice speech - but this tread doesn't relate to that")

I think it comes down to this. We have two guiding principles that are not always cooperative. (1) XLIFF's goal is to honor XML philosophy. (2) XLIFF's goal is to provide a single way (in the spirit of simplicity and interoperability) to do things.

________________________________________
From: Rodolfo M. Raya [rmraya@maxprograms.com]
Sent: Saturday, October 08, 2011 4:27 PM
To: Schnabel, Bryan S
Cc: xliff@lists.oasis-open.org
Subject: RE: [xliff] RE: [xliff-inline] Representing information for the starting/ending/standalone parts

Hi,

With an incomplete view of the discussion (I don't have all details), I just want to say that in my experience a pair like <sc>/<ec> is not really needed and it is possible to handle all cases with a well designed single tag, like the proposed <pc>. The key is in having a good set of attributes with a well designed processing expectation.

Best,
Rodolfo
--
Rodolfo M. Raya
Maxprograms http://www.maxprograms.com

-------- Original Message --------
Subject: [xliff] RE: [xliff-inline] Representing information for the
starting/ending/standalone parts
From: "Schnabel, Bryan S" <bryan.s.schnabel@tektronix.com<http://bryan.s.schnabel@tektronix.com>>
Date: Sat, October 08, 2011 8:41 pm
To: "xliff@lists.oasis-open.org<mailto:xliff@lists.oasis-open.org>" <xliff@lists.oasis-open.org<mailto:xliff@lists.oasis-open.org>>

Hi Yves,

I really understand what you're saying. I just have three short comments:

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

Exactly! I think we've gone the long way around to make my point. <pc> can be made to work across spanned segments with proper attributes (example will follow). But using <pc> across segments is as (in my opinion) ill-suited as using <sc>/<ec> in a single segment.

I could do this:

<p>These skis are good in <slang> Crud. Powder and packed powder</slang> would be better served by another ski.</p>
=
<seg>These skis are good in <pc fuct='start' id='s1' /> Crud.</seg>
<seg>Powder and packed powder<pc fuct='end' idref='s1' /> would be better served by another ski</seg>

Okay, so I've gone out of my way to com up with a silly example, but I only


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