RE: [xliff] XLIFF 2.0 Core

["Lucia.Morado" <Lucia.Morado@ul.ie>]

Hello,

I am following these last emails with interest, thanks for making such an impressive progress.
I totally agree with the structure you have proposed for the core elements. 
I have downloaded Rainbow and tried it with some files and it worked for me perfectly.

I have being thinking about the proposed <match> and <matches> (the previous <alt-trans>).
If we take them out of the core and consider them as a modular element, maybe this is also the momentum to work on them and exploit their possible uses to the full.
Rodolfo differentiated <match> and <matches>:

	><matches> :  collection of matches retrieved from any system (MT, TM, etc.)
	>Contains:
	>- One or more <match> elements
	>------------------------------------------------------
	><match> a potential translation suggested for the enclosing <segment> element
	>Contains:
	>- One <source> element followed by
	>- One <target> element

I personally like this idea. I think the <matches> elements are providing pre-translation information that could help the translator in his job.
However, the <match> property could also be used to store previous changes in the segments (this is currently done in the target element by adding the state attribute with workflow information and/or by making use of the phase mechanism) . I think this can be one of the most interesting uses. For example, if you can store there a translation that a translator has done but the proofreader has discarded. This would allow us to keep track of the changes of the document to a great granularity. Using Rodolfo´s example:

	<unit id="ud1">
	  <segment>
	    <source> John D. Williams went to the park. </source>
	    <target> </target>
		<match user="proofreader" name="Linda Spencer" date="2011-04-10T11:30:00Z"">
			<source> John D. Williams went to the park.
			</source>
			<target> John D. fue al parque.
			</target>
		</match>
		<match user="translator" name="James Lee" date="2011-04-09T09:30:00Z">	
			<source> John D. Williams went to the park.
			</source>
			<target> John D. fue a el parque
			</target>	
	  </segment>
	</unit>

In this example we have two options: 
	a)To have the main target blank until a final translation is reached.
	B)To introduce in the target element the latest modification.


Most of the things that I have just mentioned are already present in 1.2, but most tool makers do not make use of those possibilities. I think we can work on this modular <match> and give them a guide to keep track of the changes in the document.
What do you think?

Lucia




-----Original Message-----
From: Rodolfo M. Raya [mailto:rmraya@maxprograms.com] 
Sent: 09 April 2011 21:24
To: xliff@lists.oasis-open.org
Subject: RE: [xliff] XLIFF 2.0 Core


> -----Original Message-----
> From: Yves Savourel [mailto:ysavourel@translate.com]
> Sent: Saturday, April 09, 2011 8:06 AM
> To: xliff@lists.oasis-open.org
> Subject: RE: [xliff] XLIFF 2.0 Core
> 
> In other words, there may be conflicts of interest between XLIFF as
> exchange format and XLIFF as internal format.

No conflict for me. I know that XLIFF is intended for exchange, just provided a practical example that XLIFF 1.2 can also be used to hold data but it does not mean that XLIFF 2.0 core would be good for that too. 

I'm quite sure that the core module, being minimalistic, will not be enough for storing all required internal data. Hopefully the standard extensions defined by the XLIFF TC will allow using XLIFF 2.0 for storing all data.

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


---------------------------------------------------------------------
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