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

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

Hi Rodolfo,

I hear you. But that's the debate. If I read the tenor of the thread correctly, I think the momentum seems to be that you will not have the option for <pc> because there is appetite to take that option away, and do both kinds of markup with <sc>/<ec>.

I've made, and rested my case against. We'll see how it ends up.

- Bryan
________________________________________
From: xliff@lists.oasis-open.org [xliff@lists.oasis-open.org] On Behalf Of Rodolfo M. Raya [rmraya@maxprograms.com]
Sent: Sunday, October 09, 2011 4:51 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 Bryan,

While in my work a single element like <pc> is usually enough, I see the need for <sc>/<ec> in some contexts. I think that both options should exist because there are uses cases for both styles. Nevertheless, I'll probably continue using just <pc> or whatever has the functionality of current <ph>.

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

-------- Original Message --------
Subject: RE: [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: Sun, October 09, 2011 5:08 pm
To: "Rodolfo M. Raya" <rmraya@maxprograms.com<mailto:rmraya@maxprograms.com>>
Cc: "xliff@lists.oasis-open.org<mailto:xliff@lists.oasis-open.org>" <xliff@lists.oasis-open.org<mailto:xliff@lists.oasis-open.org>>

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<mailto:rmraya@maxprograms.com>]
Sent: Saturday, October 08, 2011 4:27 PM
To: Schnabel, Bryan S
Cc: xliff@lists.oasis-open.org<mailto: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>><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><mailto:xliff@lists.oasis-open.org<http://xliff@lists.oasis-open.org>>" <xliff@lists.oasis-open.org><mailto:xliff@lists.oasis-open.org<http://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><mailto:xliff-unsubscribe@lists.oasis-open.org<http://xliff-unsubscribe@lists.oasis-open.org>>
For additional commands, e-mail: xliff-help@lists.oasis-open.org<mailto:xliff-help@lists.oasis-open.org><mailto:xliff-help@lists.oasis-open.org<http://xliff-help@lists.oasis-open.org>>


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