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: text/vcard