FW: Coordination between OSCAR and XLIFF

[<bryan.s.schnabel@tektronix.com>]

Hello TC members,

The folks at OSCAR have approached me about a renewed effort to coordinate text elements between OSCAR and XLIFF. I've always thought there was merit in trying this. But I want the TC to consider take time to think about it. I've invited Arle and Rodolfo to share their ideas at the next XLIFF meeting (this Tuesday at 11:00 am, Eastern US time). We'll need to hear the proposal, then think about how this idea fits with our current efforts.

Thanks,

Bryan

________________________________________
From: Rodolfo M. Raya [rmraya@maxprograms.com]
Sent: Wednesday, January 13, 2010 9:00 AM
To: 'Arle Lommel - LISA standards and publications'; Schnabel, Bryan S
Cc: 'Andrzej Zydron'
Subject: RE: Coordination between OSCAR and XLIFF

Hi All,

My understanding about Arle's request for joint collaboration is this:

- Create a subcommittee in XLIFF TC to work on a representation for inline markup that could be used in XLIFF and TMX standards. This subcommittee could have members representing OASIS and LISA points of view (LISA is a member of OASIS).

- The new subcommittee will have to define semantics and implementation rules that could fit the needs of XLIFF and TMX, preserving compatibility as much as possible.

Arle´s current thinking seems to be aligned with inline markup defined in terms of XLIFF´s <g> and <x/>.

Currently, both TMX and XLIFF suffer from an excess in the number of options for handling inline markup. I divide the options in three categories:

1) Elements that contain the actual untranslatable markup are present in both standards (<ph>, <bpt>/<ept>, <it>, <bx>/<ex>, <ut>).

2) Elements that represent the location of markup in the segment, with real content stored somewhere else, are available only in XLIFF(<g> and <x/>)

3) Elements that delimit parts of the translatable text, indicating that a special property is applicable to the selected text are present in XLIFF and TMX (<mrk> and <hi>)

The number of elements could be reduced and a common naming scheme could be used in both standards. The goal of the proposed subcommittee would be to produce the required specification pieces to include in TMX and XLIFF standards.

There are many issues to consider for perfect compatibility. For example, XLIFF needs the content of untranslatable markup stored somewhere in the file or skeleton, but the actual markup would be optional in TMX, where placeholders are enough.

An issue that the XLIFF TC needs to consider separately is the definition of a segment. Sometime ago, the content of <source> was considered the segment requiring translation, but that was changed in XLIFF 1.2. Once we have a clear definition of segment in each standard, we can safely work on its content.

My $0.02

Rodolfo
--
Rodolfo M. Raya   <rmraya@maxprograms.com>
Maxprograms      http://www.maxprograms.com


> -----Original Message-----
> From: Arle Lommel [mailto:arle.lommel.lisa@gmail.com] On Behalf Of Arle
> Lommel - LISA standards and publications
> Sent: Wednesday, January 13, 2010 1:55 PM
> To: bryan.s.schnabel@tektronix.com
> Cc: Rodolfo M. Raya; Andrzej Zydron
> Subject: Re: Coordination between OSCAR and XLIFF
>
> Hi Bryan,
>
> Here we're talking about the way to escape and encapsulate non-textual
> markup elements within text, like an HTML <em> tag or RTF markup.
> Basically,
> we're interested in how you deal with any non-textual elements embedded
> within text.
>
> Our goal is to make it so that an XLIFF and a TMX text element could be
> freely exchanged (within reasonable limits) to foster interoperability
> between the two standards. At present one of the biggest limitations to
> interoperability is that the actual content differs in how markup is
> indicated.
>
> I've made quite a shift over the past year. I used to advocate
> incorporating
> all markup with maximum semantic information into segments, but lately
> I've
> realized that's simply impossible in many/most cases and that usually
> all
> you need to know is where the markup was so that you can extract it
> from
> other sources. As a result, I hope we arrive at a model that does allow
> for
> the *optional* encapsulating of markup within a framework that provides
> for
> simple placeholders of some sort.
>
> But all this is subject to discussion.
>
> Best,
>
> Arle
>
>
> bryan.s.schnabel@tektronix.com <bryan.s.schnabel@tektronix.com>
> scripsit
>
> > Hi Arle,
> >
> > Your proposal is welcomed by me (speaking for only myself for the
> moment). I'm
> > happy to hear that there's interest on the OSCAR side to the
> possibility of a
> > common metamarkup framework to be used by OSCAR and XLIFF. I will be
> happy to
> > bring this up with the XLIFF TC to see if there is interest. I also
> still
> > think there's value in defining an interchangeable text element (as
> we began
> > earlier) between XLIFF and TMX.
> >
> > Just so I'm sure I present this proposal to the TC accurately, could
> you
> > please explain what it is you mean by metamarkup and a common
> metamarkup
> > framework (Rodolfo and Andrzej, please feel free to give me your
> definition as
> > well)? I know it's probably obvious, but occasionally when we talk
> about such
> > things at XLIFF, I get the feeling people use the terms in different
> ways.
> >
> > Nice to hear from you Arle,
> >
> > Bryan
> > ________________________________________
> > From: Arle Lommel [arle.lommel.lisa@gmail.com] On Behalf Of Arle
> Lommel - LISA
> > standards and publications [arle@lisa.org]
> > Sent: Tuesday, January 12, 2010 8:36 AM
> > To: Schnabel, Bryan S
> > Cc: Rodolfo M. Raya; Andrzej Zydron
> > Subject: Coordination between OSCAR and XLIFF
> >
> > Hi Bryan,
> >
> > I have to apologize for the off-again, on-again (on our side) nature
> of
> > collaboration with XLIFF, but I think that we (on the OSCAR side) are
> finally
> > ready to really play ball on compatibility with XLIFF. I admit it's
> been a bit
> > frustrating, but what we would like to propose is that that XLIFF
> committee
> > form a task force to look at the issue of metamarkup and that OSCAR
> do the
> > same thing. These task forces would meet jointly to hash out a common
> > metamarkup framework to be used by both standards. I realize this is
> not a
> > trivial task, as we found out, but the momentum within OSCAR now
> (unlike six
> > months ago) seems to have swung in favor of trying this once more. My
> feeling
> > is that even if we can't come to a common metamarkup solution, we'll
> at least
> > really understand why and how to work around the necessary
> differences.
> >
> > If you're willing to have another go, we'd like to set this up soon
> and get
> > moving again.
> >
> > Best,
> >
> > Arle
> >
>