Hi Matt, Is the mechanism whereby the formatting attributes in <trans-unit> can be specified as the original values and overridden in the <target> not sufficient? I think also that your proposal would also require moving all formattable-type information into dedicated elements to work, for example we would have to deprecate attributes such as 'coord' and create a coordinate element to fit within a <reformat> element. While I consider this to be in no means out of the question, I don't think we can use this approach for 1.1. Regards, Mark Mark Levins IBM Software Group Dublin Software Laboratory Airways Industrial Estate Cloghran Dublin 17 Ireland Phone: +353 1 7046676 IBM Tie Line 166676 "Matthew.Lovatt" <
Matthew.Lovatt@oracle.com> 29/11/2002 13:00 To XLIFF list <
xliff@lists.oasis-open.org> cc Subject [xliff] Reformat Suggestion for XLIFF 2.0 All, Despite the suggestion to postpone the reformat element in 1.1, I have still been thinking about the issue I have been doing more work with an xliff 1.0 implementation for Oracle, and the issue has required numerous untidy workarounds. This is therefore a new simpler suggestion for 2.0. If it as simple as I think it may be, I have no objections to reinserting into 1.1 ---------------------------------------------------------------------------------------------------------------------- Problem One problem overlooked in reformattable elements or attributes, is that any structure that is changed during translation has no placeholder to store the original value Say we have some structure that is to be modified during translation For example x-value="xxx" During translation this becomes x-value="zzz" But we have lost the original value of xxx New Solution The idea is that any structure that may be translated is enclosed within a reformat element <reformat> <sourceval> x-value="xxx" <sourceval> <
eformat> is translated to <reformat> <sourceval> x-value="xxx" <sourceval> <transval> x-value="zzz" < ransval> <
eformat> Any structure not enclosed within a reformat element may not be changed during translation, except state etc. If concerned about wordiness <rfmt> <sval> x-value="xxx"<sval> <tval> x-value="zzz" < val> <
fmt> If a transunit has five reformattable elements, then we need five <rfmt> elements. If we tried to put all into one element, we will have problems matching up like with like. An advantage is that any structure can be controlled in this way, regardless of being XLIFF standard or an extension This is just an Idea. I have not checked to see if it is workable within the schema Mat Attachment: Matthew Lovatt.vcf Description: Binary data