OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


Hi,

I'm new here and might have missed something in the previous discussion. My understanding on the <pc>, <sc>+ <ec> issue is that it is more a question of nested inline codes or a single level segment model. Please excuse my made up attributes in the bellow examples.

Source: This is <b> a test of <i> italic bold</i></b> text.
<PC> Version: This is <pc id="1" type="bold"> a test of <pc id="2" type="italic"> italic bold</pc></pc> text.
<SC>+<EC> Version: This is <sc id="1" type="bold"/> a test of <sc id="2" type="italic"/> italic bold<ec idref="2"/><ec idref="1"/> text.

In the first version the original DOM of the source is preserved with nesting and all. As long as the source is XML and no segmentation across an inline code span is needed it is a nice representation.
In the second version the source DOM is masked out and we only deal with text and one level of elements. This can in addition represent arbitrary SGML and other custom formats as well as cross span segmentation.

If my initial understanding is correct it is my position that it makes more sense to only have the <sc>+<ec> pair of tags for paired codes. The rational for that is that they can represent all paired codes regardless of the source format and the segmentation of the source. And not having the <pc> will then leave a single way to tag a paired inline code. It also removes a potential need to define an unambiguous mapping from <pc> to <sc>+<ec> and back that a processing application applying segmentation or segment merging to an existing Xliff document could make use of. In this case it makes sense to also include a tag for standalone placeholder codes like the <ph> tag. In my opinion the most important aspect of inline code handling is to reduce the number of available choices when tagging to a single one in order to simplify implementation and interoperability. The issue here is that, as the initial mail in the thread indicate, <pc> can not exist alone. It must have other elements to support it for some documents.

If this understanding is wrong and the <pc> element can not have child elements it can be used to represent all content that the <sc><ec> model can.
<PC> no nesting version: This is <pc id="1" type="bold" mode="open"/> a test of <pc id="2" type="italic" mode="open"/> italic bold<pc idref="2" mode="close"/><pc idref="1" mode="close"/> text.
If this model is adopted it might make more sense to also include the placeholder tag type in the one inline tag using an additional mode. This model only differ from <sc>,<ec> and <ph> in that there  is one tag replacing the three and an attribute decide which one it represent, it does not add or change any functionality.

Having the <pc> element behave as in both above models will in my opinion be confusing and a source of interoperability issues.

On the side question on whether to represent the actual native inline code or not escaped inside the Xliff inline elements I do not have any strong feelings. In my experience translators tend to want to see the actual codes for some formats, for others they do not care except for the function it provide or even not that. But this is a completely separate question from what inline elements to provide in the Xliff format. Given that it would be nice but probably not essential to find a portable way to convey that information.

Best Regards,
Fredrik Estreen

________________________________________
From: xliff@lists.oasis-open.org [xliff@lists.oasis-open.org] on behalf of Schnabel, Bryan S [bryan.s.schnabel@tektronix.com]
Sent: Sunday, October 09, 2011 9:08 PM
To: Rodolfo M. Raya
Cc: xliff@lists.oasis-open.org
Subject: RE: [xliff] RE: [xliff-inline] Representing information for the starting/ending/standalone parts

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>



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





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]