Hi Doug and all, I'm just getting back to work and trying to catch up with everything, so I may speak without full understanding of the different discussions you all had the past 2 month, but it seems this one is still going on. My understanding of XLIFF content mechanism is that the format is meant to separate text from codes, using a finite number of inline element that allow to 'abstract' the original codes (regardless of their format). It seems that allowing other elements of another namespace within the content would break that basic principle. I understand that one might want to do a lot of things with an XLIFF document at different stage, like edit it. And using different namespaces in the content is very handy for this. But, in my view, those are proprietary modifications of XLIFF (which can certainly exist without conflict). I think the burden of go from the XLIFF format to those extensions (and back) should reside in whatever tool use the extension. The mandate of XLIFF is to be an exchange format, and as it, in my view, it cannot allow to have extension for the content. Just my first impression on this topic. But I certainly think the subject should be looked at carefully and the advantages (if any) of allowing extensions in the content be considered. kind regards and Merry Christmas -yves