Re: [xliff] Simplified XLIFF element tree

[Andrzej Zydron <azydron@xtm-intl.com>]

  Hi Asgeir,

I appreciate your attempts at getting involved with this topic. When you 
reply to discussions such as these, please can you provide examples to 
back up your points. You need to justify your statements. Please see 
points below:

On 25/08/2010 22:44, Asgeir Frimannsson wrote:
> ----- "Andrzej Zydron"<azydron@xtm-intl.com>  wrote:
>> For pre-segmented XLIFF systems:
>>
>> <group id='e1' extype='para'>
>> <trans-unit id='u1'>
>> <source>This is the first sentence.</source>
>> <target>Pierwsze zdanie.</target>
>> </trans-unit>
>> <trans-unit id='u2'>
>> <source>This is the second sentence.</source>
>> <target>Drugie zdanie.</target>
>> </trans-unit>
>> </group>
>>
>> For unsegmented XLIFF systems a solution might be:
>>
>> <group id='e1' extype='para'>
>> <extr-text id='e1'>
>>           This is the first sentence. This is the second sentence.
>> </ext-text>
>> </group>
>>
>> The segmenting XLIFF editor would then generate the following:
>>
>> <group id='e1' extype='para'>
>> <extr-text id='e1'>
>>           This is the first sentence. This is the second sentence.
>> </extr-text>
>> <trans-unit id='u1'>
>> <source>This is the first sentence.</source>
>> <target>Pierwsze zdanie.</target>
>> </trans-unit>
>> <trans-unit id='u2'>
>> <source>This is the second sentence.</source>
>> <target>Drugie zdanie.</target>
>> </trans-unit>
>> </group>
> I see a few flaws with this approach:
> 1) Having to duplicate source text ( ->  same approach as<seg-source>)
If you are going to show the <extr-text> then it must be left alone, 
otherwise you are changing the context. The whole point of this element 
is to show the unsegmented text throughout the whole translation and 
review process. There is nothing wrong in showing data in different 
representations in this context. Mapping different ontological entities 
onto the same representation is perfectly valid in this instance.
> 2) No easy way of re-arranging segments
I fail to understand your point. Please can you provide examples.
> 3) No easy way of storing data that is between segments
I fail to understand your point. Please can you provide examples.

4) Every trans-unit in the file will be within a group element, even though it's one segment

You can see from the example that I have provided that this is not the 
case. The pre-segmenting process groups <trans-unit> elements within an 
encompassing <group> element. For instance a <para> element with 
multiple sentences would be such an case.
> 5) It's going to be a pain to work with in editors and processing tools, as<trans-unit>  elements would have to be created on demand based on if it segmented or not. And on re-segmentation, the<source>  would change.
I fail to understand your point. Please can you provide examples. Are 
you presenting the problem from the point of view of the systems 
architect or the end user?
> 6) If<extr-text>  is 'optional' it creates even more problems..
I fail to understand your point. Please can you provide examples.

Best Regards,

AZ
>> The benefit of using 'group' in this way is that we are not inventing
>> new elements and is totally backwards compatible with XLIFF 1.2. The
>> last thing we want to do is to introduce any fundamental change to the
>> XLIFF structure. For non-segmenting systems we have the new optional
>> <extr-text>  element. This should solve both problems.
> I think this touches on the core of this discussion. Part of what I and others will present over the symposium is really a major revision of XLIFF towards a 2.0 version, rather than minor backwards compatible changes. Tools that work with 1.x today will not work with 2.0 without modification.
>
> Great to see the discussion on 2.0 pick up!
>
> cheers,
> asgeir
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>

-- 
email - azydron@xtm-intl.com
smail - c/o Mr. A.Zydron
	PO Box 2167
         Gerrards Cross
         Bucks SL9 8XF
	United Kingdom
Mobile +(44) 7966 477 181
FAX    +(44) 1753 480 465
www - http://www.xtm-intl.com

This message contains confidential information and is intended only for
the individual named.  If you are not the named addressee you may not
disseminate, distribute or copy this e-mail.  Please notify the sender
immediately by e-mail if you have received this e-mail by mistake and
delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free as
information could be intercepted, corrupted, lost, destroyed, arrive
late or incomplete, or contain viruses.  The sender therefore does not
accept liability for any errors or omissions in the contents of this
message which arise as a result of e-mail transmission.  If verification
is required please request a hard-copy version. Unless explicitly stated
otherwise this message is provided for informational purposes only and
should not be construed as a solicitation or offer.


begin:vcard
fn;quoted-printable:Andrzej Zydro=C5=84
n;quoted-printable:Zydro=C5=84;Andrzej
email;internet:azydron@xml-intl.com
tel;work:+441494558106
tel;home:+441494532343
tel;cell:+447966477181
x-mozilla-html:FALSE
version:2.1
end:vcard