Translation Memory eXchange is, as the name suggests, not a terminology, but a translation format. I only added this for one specific customer workflow. It did turn out to be used, so the created files are now following the full TMX standard (I hope...). Support, though, is rudimentary. Anything beyond the most basic tmx could cause problems converting into anything else. tags and entities are only handled in a brute force way (<b> becomes &lt;b&gt;, instead of the correct <bpt i="1">&lt;b></bpt>, and so on.

Fields

Termbase fields are mapped to prop elements. There are some qiurks, since tmx is an open format, and the content of props can have any format. The converter recognises two formats, distinguished by the o-tmf attribute  in the header.:

• SDL TM8 Format: this is what Trados exports from  TM. The user fields have a prefix x-, and a postfix with the field content type, e.g. :MultiplePicklist. The converter will strip these to get the field name. For example:<prop type="x-color:MultiplePicklist"> is resolved to the picklist field color.
• any other format: any -x prefix is still removed, but it id not required. The rest of the type attribute is interpreted as the field name. This is also the output format. So the color field would be exported to <prop type="color">

The tuid attribute is converted into an entry field. On import, an entry field called "tuid" is interpreted as the tuid, not a field. If there is no tuid in the import, a unique number is created. Note: if your import file has only a tuid in some entries, and uses ordinal numbers like 1, 2, 3,..., there may be number clashes. You should have a tuid for all or no entries.

I'm sure you can find multiple ways of breaking things with tmx, but at the moment it has low priority. If you want to do proper TMX processing, try Olifant.

Hope that helps you answer your question?