Subject: Re: [xliff] Translating XLIFF 1.2
Hi Yves, Thank you for such a succinct and accurate explanation. I, as an XLIFF evangelist and enthusiastic proponent, agree totally with your guidance. Best Regards, AZ On 23/02/2010 05:09, Yves Savourel wrote: > Hi Rodolfo, > > >> ... The introduction of Segmentation section must be >> changed, as it currently says that it "may be important >> for the user agent to break down the content of the >> <source>". It should clearly state that such operation >> is required. >> > I would disagree: Why would we want to make<seg-source> mandatory? > > XLIFF provides a way to represent segmentation if you wish to, it does not force anyone to use segmented document. There are quite a few tools that do perfectly well in their domain without segmentation. > > > >> ... some developers like me would interpret that segmentation >> can happen when the XLIFF file is created and write code >> that is valid according to the schema and the specification >> document, but wrong according to the intended spirit of the >> standard. >> > Most developers I know would simply read the Segmentation section of the specification and implement it if they needed to. There is not much to interpret in that section I think. > > Segmentation can certainly be done before the XLIFF file is created: XLIFF is just a file format. You just have to code it using<seg-source> to be interoperable. > > If a tool generates code where each<source> is an actual segment and does not uses<seg-source> to indicates that, it is still valid and following the specification, but it is simply not segmented from the view point of XLIFF. It's also sad because other tools won't be able to do much as far as manipulating segments in that file. > > Let's see it another way: You said another way to represent segmentation would be to use a<group> for the paragraph and the<trans-unit> for its sentences. I'm pretty certain any internal data structure that can generate such representation can also generate the<seg-source> model. If it has all the info to generate one it has them to generate the other as well. > > So, while the specification could probably use adjustments and more specific wordings--in segmentation and other areas--I don't think the current<seg-source> description warrants the deep changes you are listing for 1.2. > > Cheers, > -yves > > > > --------------------------------------------------------------------- > 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 - firstname.lastname@example.org 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.xml-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:email@example.com tel;work:+441494558106 tel;home:+441494532343 tel;cell:+447966477181 x-mozilla-html:FALSE version:2.1 end:vcard