MaxKaladin said:
Just a couple of comments from the peanut gallery.
1. I think history should be a part of any such data model. You should be able to look at the data and see exactly how the character progressed to the level they're at. I think this is important for a couple of reasons. One is if people use this at the game table and you have temporary level loss affect the character. This would make it easy to just click a button to apply that loss and the application can know exactly how to 'downgrade' the character. Another is for DMs making NPCs. One thing I sometimes do when making NPCs with programs like PCGen is decide I want to take a few levels off either to add them to a different class or just for balance. I generally find this to be a pain to do since you then end up having to go through and manually subtract skill points, feats and stat bonuses (which may then affect skill points) and so on. A history would make this much easier.
Level downgrade is fairly undefined by the SRD, though (as far as I can recall). A player can (and may want to) downgrade their level in a tailored fashion. Following the rules a character may increase their Str from 10 to 11, then lose a point of Dex because that's their highest score. This can be advantageous in certain, limited situations.
I think this should be up to the application, keeping old copies of files at any point. The application can do this automatically or at certain points (level up, for instance). The application can use intelligent merging to simulate Undo of certain things. Keeping an actual data history for rollback would likely result in a design that made it easy to Undo the last change, but difficult to, for instance, go down a level, without losing equipment, etc.
2. I think the data model should include tags that allow modifications for specific rulesets. For instance, you could specify that acid fog is level 8 in a specific set of house rules and when a program is switched to a set of house rules, it could go through the list and apply all of the modifications to the various elements in the data. You would probably need to specify what the specific set of rules is, what to modify and what to change it to. If you're really ambitious, you could also allow for new variables that aren't in the standard rules like spell points for house rules that use them.
I did already cover that type of thing in my namespaces idea. I should point out that they are not XML namespaces, but custom ones designed for the application to use. I imagine it as a dialog with optional check boxes for each of the namespaces. You check the ones that you want to apply. The namespaces themselves would have a parent namespace to indicate which changes have priority.
For instance, namespace MaxKaladinHouse would be a child of namespace SRD. In it, it would define <spells><spell name="acid-fog"><level sor="8" wiz="8"> ...end all tags...
Since MaxKaladinHouse is defined as a child of SRD, it obviously is designed to override the data in the SRD, so it would take precedence. Now if you had two namespaces ReanjrHouse and MaxKaladinHouse that both descended from the SRD and both redefined the Acid Fog spell, the dialog could detect this and ask the end user which has precedence.
Also, since it is XML, one could easily add a <SpellPoint> value for every spell, giving you that capability in a particular set of house rule, though better would be creating a metatag that calculated the SpellPoint cost based on Level. That way, you could apply the ReanjrHouse (acid fog level 6) and MaxKaladinHouse (acid fog level 8 and SpellPoints) and have it use ReanjrHouse for the level (6) and MaxKaladinHouse for SpellPoint rules, which calculate based on level 6 from ReanjrHouse.
Just throwing this stuff out so that people can get a better idea of where my thoughts are. Obviously nothing of this sort is implemented. That would be real work.
Yeah, I know its too early to define the data but I just wanted to throw those ideas out there.