XLIFF Inline Markup SC

Hi All,   Here is a summary of processing expectations and associated schema support that I have arrived at. This proposal / summary does not try to handle the case of adding new previously nonexistent codes or modification of the native code content. It simply tries to establish a simple, safe and reasonably flexible foundation for interoperable edit operations. I do see a potential to add additional allowed operations on top of this through extensions. For example one could imagine that a table in the XLIFF document with codes that can be freely added to segments can be defined in an extension. That should not conflict with this proposal.   I use the term ‘edit’ to not only refer to interactive editing in an editor application, but rather all modification to the segments in the XLIFF file.   I have left out management of annotations for now as they are not essential to the round trip integrity of the file in most cases. Once we reach a consensus on the handling of the base content, translatable text and inline codes representing native code, we can continue adding more features to the processing expectations.   I have not used any particular implementation of this in XML, but instead kept that open and worked on the general concepts and properties instead.   Any critique, feedback or suggestions on this is warmly welcomed.   Best regards, Fredrik Estreen Attachment: xliff_edit_pe.pdf Description: xliff_edit_pe.pdf

Great work Fredrik! This should help us a lot with the specification draft.   Thanks, -ys   From: xliff-inline@lists.oasis-open.org [mailto:xliff-inline@lists.oasis-open.org] On Behalf Of Estreen, Fredrik Sent: Thursday, April 19, 2012 6:55 AM To: xliff-inline@lists.oasis-open.org Subject: [xliff-inline] Processing expectations for segment editing   Hi All,   Here is a summary of processing expectations and associated schema support that I have arrived at. This proposal / summary does not try to handle the case of adding new previously nonexistent codes or modification of the native code content. It simply tries to establish a simple, safe and reasonably flexible foundation for interoperable edit operations. I do see a potential to add additional allowed operations on top of this through extensions. For example one could imagine that a table in the XLIFF document with codes that can be freely added to segments can be defined in an extension. That should not conflict with this proposal.   I use the term ‘edit’ to not only refer to interactive editing in an editor application, but rather all modification to the segments in the XLIFF file.   I have left out management of annotations for now as they are not essential to the round trip integrity of the file in most cases. Once we reach a consensus on the handling of the base content, translatable text and inline codes representing native code, we can continue adding more features to the processing expectations.   I have not used any particular implementation of this in XML, but instead kept that open and worked on the general concepts and properties instead.   Any critique, feedback or suggestions on this is warmly welcomed.   Best regards, Fredrik Estreen