Changes in Avatar XML [Updated]

Its likely the pre-proposed will more or less stick. However, in the code redesign, I'm also re-evaluating how the data in that format is presented. I brought up the xml format values before, and how they should be "readable" in the sense of their data (not the hierarchy format) and decided to go back on that. The idea before was that the values themselves should make sense when editing them by hand. However, in working with those values directly, I've found that the trickery there was more confusing - and maybe that's just my perspective as a developer. But, additionally (also as a developer), it will be much easier to manage that data if how its presented in XML mirrors how its presented in the binary.

Particular cases include:

• eyeY: inverted
• glassesY: inverted
• moleY: inverted
• mouthY: inverted
• mustacheY: inverted
  
• noseY: inverted
• eyebrowY: inverted, offset by 3 (it's minimum value is 3, unlike the others which are 0)
• mingles: inverted
• eyeType: value converted to order presented in interface
• eyebrowType: value converted to order presented in interface
• hairType: value converted to order presented in interface
• noseType: value converted to order presented in interface
• mouthType: value converted to order presented in interface

The new format will not present the data with this kind of filtering and will use the raw data. This means that you cannot just copy values from the old format to the new and expect the same results. However, the editor should be able to consume the old XML format as well as the new, so loading an old XML character will allow you to get an updated XML file with the correct values.

Update:
I think I've decided to go back on what I've said here. While most of the values will remain unchanged (relating to the format), I think there will continue to be one exception. This exception, however, is a new exception - not one listed above. It's for colors. Instead of an integer ID specifying which number of a pre-defined set of colors is to be used, I figured it would be better, moving forward, that a standard hex color be specified instead. This goes back to extensions and adding more functionality/possibilities than that which is possible for current-day Mii characters. If you're going to eventually allow specifying any color, some random number isn't going to cut it given how colors themselves are represented as numbers (in hex). So, for example, instead of having a favorite color of "10", it would be 0xFFFFFF (or #FFFFFF), meaning white.