Re: [xliff-comment] Another possible solution for reformat

[Tony Jewtushenko <Tony.Jewtushenko@oracle.com>]

Hi Doug and all:

At the heart of all recent discussions regarding reformat lays the question
"Is maintaining compatibility between 1.0 and 1.1 data files absolutely
necessary?".  I think for us to decide on an implementation direction for
reformat, we must first resolve this question to our collective
satisfaction.

To refresh your memories on the actual policy,  please follow this link to
see the migration policy the TC agreed to for 1.0->1.1 ->
http://lists.oasis-open.org/archives/xliff/200208/msg00005.html.  This
document lists the migration policy that was voted on and accepted by the TC
back in August 2002 and would require revision (with a vote to accept it) in
order to revise.

Some history:  this migration policy was initially drafted at the face to
face meeting this past spring,  and reflects the opinion of the group at
that time.  Specifically,  when we initially discussed the migration policy,
the group felt that it was important to assure developers of XLIFF 1.0 that
their data could be migrated without significant investment in migration
tools or process.  It was also mentioned that it would be highly desirable
that XLIFF tools be backwards compatible where possible (per the Microsoft
Word doc model),  so that tools could universally read and write any version
of XLIFF.

Tomorrow we'll (briefly) revisit the reasons and considerations for
implementing this policy,  and decide if they still apply.  Please formulate
in your own minds what your thoughts and opinions are on this matter before
tomorrow's meeting.

Regards,
Tony


----- Original Message -----
From: "Doug" <doug@ektron.com>
To: "XLIFF" <xliff-comment@lists.oasis-open.org>
Sent: Monday, January 20, 2003 3:17 PM
Subject: [xliff-comment] Another possible solution for reformat


> The current structure of trans-unit limits source and target to plain text
> and XLIFF placeholders.
>
> <trans-unit id="00001" translate="yes">
>   <source>Unable to store persistent object</source>
>   <target>Unable to store persistent object translated</target>
> </trans-unit>
>
> One proposed option is to encapsulate the text and other format elements,
> like coord, font, and style, within a <source-info> element and place the
> text (with placeholders) within <text> tags.
>
> <trans-unit id="00001" translate="yes">
>   <source-info>
>     <text>Unable to store persistent object</text>
>     <coord>
>       <x reformat = "no">x </x>
>       <y reformat = "no">y</y>
>       <cx reformat = "yes">cx </x>
>       <cy reformat = "yes">cy</y>
>     </coord>
>   </source-info>
>   <target-info>
>     <text>Unable to store persistent object translated</text>
>     <coord>
>       <cx>cx </x>
>       <cy>cy</y>
>     </coord>
>   </target-info>
> </trans-unit>
>
> The problem with this option, although it is arguably the cleanest
> structure, is that it does not maintain compatibility with XLIFF 1.0.
> Granted the transform from XLIFF 1.0 is not difficult.
>
> The structure below does not strictly maintain compatibility, but the
> migration path is obvious. The <source-info> and <target-info> tags are
> optional. That is, the XLIFF 1.0 structure is permitted. I believe this
> makes it easier to write code or XSLT to handle both XLIFF 1.0 and XLIFF
> 1.1. Unfortunately, code written for XLIFF 1.0 would likely need to be
> changed to support XLIFF 1.1 because <source> may not be the direct child
of
> <trans-unit>. The real advantage to this structure is the clear migration
> path because the <source> and <target> tags are preserved instead of being
> renamed as <text>.
>
> New extended structure:
>
> <trans-unit id="00001" translate="yes">
>   <source-info>
>     <source>Unable to store persistent object</source>
>     <coord>
>       <x reformat = "no">x </x>
>       <y reformat = "no">y</y>
>       <cx reformat = "yes">cx </x>
>       <cy reformat = "yes">cy</y>
>     </coord>
>   </source-info>
>   <target-info>
>     <target>Unable to store persistent object translated</target>
>     <coord>
>       <cx>cx </x>
>       <cy>cy</y>
>     </coord>
>   </target-info>
> </trans-unit>
>
> -OR- Old basic structure:
>
> <trans-unit id="00001" translate="yes">
>   <source>Unable to store persistent object</source>
>   <target>Unable to store persistent object translated</target>
> </trans-unit>
>
> The original XLIFF 1.0 structure would also be allowed. The schema would
> specify the <source-info> and <target-info> tags as optional if <source>
and
> <target> were the sole children. That is, if <coord> or other format
element
> is used, the <source-info> and <target-info> would be required. Pattern
> matching for TM would only be performed on <source> and <target> content.
>
> Another, more psychological, benefit to making <source-info> and
> <target-info> optional is that if an application only requires text and no
> format elements, the structure becomes simple. One of my complaints with
XML
> Schema is that it requires twice as many tags as I would expect. We should
> remove the question "Why do I need <source-info> and <source>?". With
XHTML,
> the <tbody> element is required, but most people used to older versions of
> HTML don't like it. It appears on the surface to be an extraneous tag. It
> also breaks a lot of HTML parsing code that assumes <tr> will be a child
of
> <table>.
>
> The bigger issue of whether XLIFF 1.0 compatibility is required or not is
> beyond my ability to answer. From a practical point of view, it depends on
> how many applications of XLIFF 1.0 exist beyond the XLIFF TC members. How
> widely has XLIFF 1.0 been adopted? If XLIFF 1.0 has not been implemented
> outside the TC, then compatibility is not a consideration and the use of
> <text> would be preferred.
>
>
> Regards,
>
> Doug D
>
> Ektron, Inc.
> +1 603 594-0249
> http://www.ektron.com
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>