I'll swing with that. I just really, really hate editing XML. I don't really see much of an implementation difference between pure-python and XML in terms of knowing the data structures, because you can have something like:
fitness = {'name': "Fitness", 'type': 'Stat' 'level': 'Primary', secondary_affected: [('Long-Distance Running', 1), ('Lifting Capacity', 0.3), ('Carrying Capacity', 0.3), ('Sprint Speed', 0.7)], 'skills': [('Something here', 0.5)]}
or you could have...
<stat level='Primary' name='Fitness'>
<affect type='Secondary'>
<stat level='Secondary' name='Long-Distance Running' weight='1' />
<stat level='Secondary' name='Lifting Capacity' weight='0.3' />
<stat level='Secondary' name='Carrying Capacity' weight='0.3' />
<stat level='Secondary' name='Sprint Speed' weight='0.7' />
</affect>
<affect type='Skills'>
<skill name='Something here' weight='0.5' />
</affect>
</stat>
Agreed. I'd even argue that determining the data structures for XML would be equally, if not more taxing on developers because not only does the structure (read: schema) have to be agreed upon, but the parser must be created as well.
With pure python, the amount of work that needs to go in a parser relies solely on the amount of encapsulation that developers agree to implement. That is, raw python data structures (dictionaries, lists, etc) could be used initially, then a layer could be built upon that to make it easier for non-programmers. Further, I seem to remember the argument being made that these kinds of files wouldn't be edited by hand in most cases (eg. editor tools) so the technology used is irelevant.
A final argument would be that the XML parser would simply be converting tags to python objects, so in theory wouldn't it be much simpler to just cut out the middle man?
At any rate, I'll follow suit with whatever we decide upon but would much rather not have to play with XML for this particular purpose.