Cartographer supports this, in theory. However, I chose to limit your choices when it comes to Class Type and Element Type. There is a reason for this.
Cartographer uses the Class Type and Element Types in an object model to look up the images and descriptions of each object. These entries are stored in resource tables. The Class Type isn't used too extensively right now, but the idea was to allow plugins to specify the class of object that they can modify and Cartographer would automatically filter plugins based on the item that was selected. This has never been implemented.
The item type, obviously, is a little more important to Cartographer. This is how we determine which image (not fully implemented) and description to display on the screen.
Cartographer could be modified in three ways:
1. Someone gives me a list of every possible class ("Vehicle", "Projectile", etc) and every possible element ("Wounded Marine Sitting", etc) and I can allow those values to be used in the XML.
2. I allow you to put whatever you want in the Class and Element attributes. However, the item will loose any future plugin functionality and Cartographer will not be able to display an image or description for the item (except for, possibly, a supplied name) if Cartographer doesn't know the values you supply.
3. Make it so that even the elements images and text can be stored as part of the CTG file. This would require a lot of re-work and would loose multi-spoken-language support. I still haven't seen any interest expressed in the translation of Cartographer to another spoken lanuage, so this may be a mute point. (Solution #3 still does not address the plugin problem inherent to #2). Cartographer would be quite a bit larger with this soltion, because the images would be stored in base64 encoding (rather then in binary resources).
Any other suggestions are welcome. Solution #1 is obviously preferable, but I don't know if anyone wants to take the time (lord knows I didn't). Solution #2 would also work, with some limitations in future expansion. Solution #3 requires quite a re-working of the engine, but I could do it also. It does seem like the least beneficial option, however...