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] Simplified XLIFF element tree

  Hi Yves,

Thank you for your wise comments. I would be somewhat concerned about 
backwards compatibility. I would STRONGLY argue for backwards 
compatibility. Not doing so would endanger the work of the committee in 
the eyes of existing adopters. A subset based on existing elements would 
in my mind be the much better approach.

Best Regards,


On 02/09/2010 05:46, Yves Savourel wrote:
> Hi everyone,
>>> 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.
> I don't see a problem with having markup in the source text that is used to delimit specific properties of the text, in addition to the one used for the inline codes. One of the properties can be the segmentation. another can be terms, etc.
> If we have clearly defined processing expectations associated with some elements, reading the original un-segmented from such marked up content should be easy.
>>> 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.
> Two notes on this:
> a) To have a segmentation representation backward compatible we would need to use<seg-source>  in some way: That is the only way to represent segmentation described in the XLIFF 1.2 specification.
> b) But it's a moot point anyway: to me, 2.0 should not concern itself with backward compatibility.
> We should be able to create new structures, remove some, do anything that makes XLIFF better.
> I thought that was an established start point for 2.0.
> If it is not then we need to tackle that before anything else.
> Actually I'm even thinking we should make sure 1.2 tools cannot read 2.0 files. This would avoid any half-implementation based on some vague changes in 1.2 readers. I suspect a large part of the 2.0 changes will be the expected processing associated with the elements/attributes and we want to avoid 2.0 files being processed like 1.2 ones.
> Cheers,
> -ys
> ---------------------------------------------------------------------
> 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.

fn;quoted-printable:Andrzej Zydro=C5=84

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