xmld20 - an XML Schema for d20 gaming systems - design

There are a few features that I'm looking for while designing this schema. I'll try to spell them out here, but, as I develop both the schema and any software based on it, I might come back to this page and update it.

Target

The final goal will be XML Schema (or XSchema) documents that conform to W3C recommendations, sample XML documents that conform to these schemas and XSLT documents that convert those documents to other formats, such as statblocks and characters sheets as final targets, as well as tranformation to other data formats such as the d20-xml format or what eTools expects.

While I have more experience with the older XML DTD format, this is a dead definition, and I'll definitely be sticking to XSchema. Or, now that I go and look at the W3C site, DDML.

Goals

Because I eventually want to make tools from these schemas, they will need to portray the whole gamut of data that is available in d20.

Things that will need representation include:

Monsters and Races
Classes
Spells
Items

Representation of the text information of all of these things is not enough, though; if that was all that was needed, then the d20-xml format would be enough. The data must be represented in such a way that software can process it, both for generating new output (monster stat blocks, spell lists, etc.) and for computation (figuring out what you get when you take this monster and add three levels of this class, how and whether a certain spell is going to affect a certain monster, etc.)

This last idea is the most important. From the XML data (with this designed schema), a program should be able to use the class information to level up a character or NPC, regardless of the race or monster. In this idea of adding races and classes together, it must be able to cope with multiclassing, with ideas of prerequisites for feats (and when these prerequesites are waived). The currect style of the d20-xml data doesn't work in this way. For instance, this is the AC entry for the first monster in the Monster Manual, the aboleth:

<ArmorClass>16 (-2 size, +1 Dex, +7 natural), touch 9, flat-footed 15</ArmorClass>

While this information is useful to a human for reading the total, for being able to somewhat easily figure out the creature's touch AC, etc., and even figure out what would happen if the creature was shrunk or enlarged and such, it's not so readable to software (that is, it's not easily parseable by software).

Optimally, this would be represented as

<ArmorClass size="-2" dex="1" natural="7">16 (-2 size, +1 Dex, +7 natural), touch 9, flat-footed 15</ArmorClass>

This way, the software can look for specific attributes to pull out the specific numbers, in case it, say, needs to figure out what happens to the creature if a spell removes its natural armor benefit, or the creature is magically enlarged. The d20-xml guys got it right with the saves and abilities, however:

<Saves Fort="7" Ref="3" Will="11">Fort +7, Ref +3, Will +11</Saves> 
<Abilities Str="26" Dex="12" Con="20" Int="15" Wis="17" Cha="17">Str 26, Dex 12, Con 20, Int 15, Wis 17, Cha 17</Abilities>

In this way, the information is easily viewable by both man and machine.

Another approach would be to not supply the human-readable text:

<ArmorClass size="-2" dex="1" natural="7"/>
<Saves Fort="7" Ref="3" Will="11"/>
<Abilities Str="26" Dex="12" Con="20" Int="15" Wis="17" Cha="17"/>

With this method, the information is still there for the machine, but is no longer there in human-readable format. The data isn't being entered twice though, which is a benefit for the data-entry people. Additionally, with the use of XSLT, you can take the above format and reproduce the mixed version without much work.

For now, I think that's the approach I will take -- machine-readable only. I'll also co-develop the XSLT to produce a double-readable format, and, of course, I'll try to keep XSLT sheets available for my other targets (d20-xml and eTools) as I develop and change my own schema.

<--intro ^--xmld20--^ design, continued-->