Hi, In the current segmentation representation proposal we have no provision for representing segments that are in different order in the source and the target. This is something 1.2 allows. There are also more and more tools using human or on-the-fly alignments which need to preserve the "paragraph level" context (and therefore the order too). So, while I do like the current proposed representation for 2.0, I think it is still important to allow crossover alignments. === A) The technical side: I was wondering if anyone had some idea how to have both, probably using some optional attributes. For example here is a 1.2 case where we have a crossover alignment: <trans-unit id='1'> <source>Segment 1. Segment 2.</source> <seg-source><mrk mtype='seg' mid='1'>Segment 1. </mrk><seg mtype='seg' mid='2'>Segment 2.</mrk></seg-source> <target><mrk mtype='seg' mid='2'>Translation 2. </mrk><seg mtype='seg' mid='1'>Translation 1.</mrk></target> </trans-unit> Maybe the information could be provided with a simple attribute, giving the sequence in which the target segments (or <ignorable>) should be appended to provide the proper order when represented as the whole content of the unit: <unit id='1' targetOrder="2,1"> <segment> <source>Segment 1. </source> <target>Translation 1.</target> </segment> <segment> <source>Segment 2.</source> <target>Translation 2. </target> </segment> </unit> Another way would be to hold the information about the order in the target element: <unit id='1'> <segment> <source>Segment 1. </source> <target order='2'>Translation 1.</target> </segment> <segment> <source>Segment 2.</source> <target order='1'>Translation 2. </target> </segment> </unit> And if the order attribute is absent, the order is the same as for the source for that segment. This option would be a bit less "safe" as it may be a little bit more difficult to validate the values. === B) The core vs module side: Assuming we found a representation, now comes the dilemma of the processing expectations: Some tools don't support crossover alignments, so what should they do with targetOrder? - just make sure they preserve it? But if they change the segmentation it invalidates the original targetOrder, so preserving is not really a good solution. - detect it and generate and error because the document contains a feature/module the tool do not support? This is really a general question about how tools not implementing some features need to handle files with those features. The "just ignore what you don't support" is not always harmless. -ys