[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, AZ 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.
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]