D&D 4E 4e Character XML Schema

[ninjeff]

I've attached the latest schema and example characters in this post.

His attributes probably look funny because my brain is still in 3.5 mode and I only boosted one stat at levels 4,8,14,18,24, and 28. His stats should really be Int 24, Wis 18, Cha 12, Dex 10, Str 10. This doesn't include the bonuses from level 11 or 21, or his human bonus which should go to Int.

Funny, that's almost exactly how I modified it.

I tried that at first too. Then I came upon Bracers of Defence (PH 244) which doesn't have a plus but has three different versions. I suppose we could put Bracers of Defence 10, Bracers of Defence 20, and Bracers of Defence 30 but if we do something different for each item that doesn't use standard pluses then parsing could get messy.

Going by the name in the table, I used <item>Bracers of Defense (paragon tier)</item>. It seems like that's the standard notation in the books.

 

[megasycophant]

Whaddya know, my first ENWorld post. This kinda stuff really brings the geeks outta the woodwork, eh?

Might I suggest using the following markup instead:

<race name="Human">
   <feat name="Skill Training">
       <skill>Diplomacy</skill>
   </feat>
</race>

I heartily second that. Generic elements like the "choice" element above kinda violate the core premise of xml, in that the elements should be self-descriptive. (The worst example I've seen being xml configuration files full of <property name="key">someValue</property> lines, serving to do nothing but complicate a properties file.) This also makes validation downright impossible.

One glaring issue I'm seeing, and perhaps it's because I'm thinking about it from a different perspective, is that it seems to me that the cart is coming before the horse. If this xml schema is just being created to be able to display/store unvalidated character information, that's all well and good, but if any sort of validation is to occur, more groundwork should be laid. (Of course, that could just be my preference for the bottom-up approach.) I would say:

1. Type hierarchies should be defined codifying specific options available. Easier shown than explained, here's an example using feats, the most obvious. First the schema:
   

   <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
   	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   	xsi:schemaLocation="http://www.w3.org/2001/XMLSchema http://www.w3.org/2001/XMLSchema.xsd">
   
   	<xsd:element name="pc">
   		<xsd:complexType>
   			<xsd:sequence>
   				<xsd:element name="feat" type="Feat" maxOccurs="unbounded" />
   			</xsd:sequence>
   			<xsd:attribute name="name" type="xsd:string" />
   		</xsd:complexType>
   	</xsd:element>
   
   	<xsd:simpleType name="WeaponGroup">
   		<xsd:restriction base="xsd:string">
   			<xsd:enumeration value="spears" />
   			<xsd:enumeration value="heavy blades" />
   			<!-- other groups here -->
   		</xsd:restriction>
   	</xsd:simpleType>
   
   	<xsd:complexType name="Feat" abstract="true">
   		<xsd:attribute name="name" type="xsd:string" />
   		<xsd:anyAttribute />
   	</xsd:complexType>
   
   	<xsd:complexType name="GeneralFeat">
   		<xsd:complexContent>
   			<xsd:restriction base="Feat">
   				<xsd:attribute name="name">
   					<xsd:simpleType>
   						<xsd:restriction base="xsd:string">
   							<xsd:enumeration value="Alertness" />
   							<!-- other feat names here -->
   						</xsd:restriction>
   					</xsd:simpleType>
   				</xsd:attribute>
   			</xsd:restriction>
   		</xsd:complexContent>
   	</xsd:complexType>
   
   	<xsd:complexType name="WeaponGroupFeat">
   		<xsd:complexContent>
   			<xsd:restriction base="Feat">
   				<xsd:attribute name="name">
   					<xsd:simpleType>
   						<xsd:restriction base="xsd:string">
   							<xsd:enumeration value="Weapon Focus" />
   							<!-- other feat names here -->
   						</xsd:restriction>
   					</xsd:simpleType>
   				</xsd:attribute>
   				<xsd:attribute name="group" type="WeaponGroup" use="required" />
   			</xsd:restriction>
   		</xsd:complexContent>
   	</xsd:complexType>
   </xsd:schema>

   And here's an example document:
   

   <pc name="Joe" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   	xsi:noNamespaceSchemaLocation="enWorldExample.xsd">
   	<feat xsi:type="GeneralFeat" name="Alertness" />
   	<feat xsi:type="WeaponGroupFeat" name="Weapon Focus" group="spears" />
   </pc>

2. A dataset should be defined enumerating options, [somewhat bogus yet hopefully illustrative] frex:
   

   <weapon name="dagger">
   	<group>light blade</group>
   	<category>simple</category>
   	<handedness>1</handedness>
   	<melee>true</melee>
   	<range>
   		<category>light thrown</category>
   		<normal>5</normal>
   		<long>10</long><!-- assuming these aren't always 2x normal -->
   	</range>
   	<proficiencyBonus>+3</proficiencyBonus>
   	<damage>1d4</damage>
   	<price>1</price>
   	<weight>1</weight>
   	<offHand>true</offHand>
   </weapon>

3. The character definition should consist of references (to keys defined by the schema) to this dataset, frex:
   

   <pc name="Joe">
   	<body>
   		<leftHand item="dagger" />
   		<rightHand item="dagger" />
   	</body>
   </pc>

That said, it almost feels to me like the best way to go about some of this would be to have two layers of schema, the first used to generate the core data, then somehow compile the core data into a schema used for character definition. When you start getting into weapon-specific feats like Weapon Proficiency (I started to use this to show it) or updating enumerated things on the fly, schema gets a lot hairier and scarier and it would mean manually editing the schema.

 

[dragon_eater]

[*]A dataset should be defined enumerating options, [somewhat bogus yet hopefully illustrative] frex:

<weapon name="dagger">
	<group>light blade</group>
	<category>simple</category>
	<handedness>1</handedness>
	<melee>true</melee>
	<range>
		<category>light thrown</category>
		<normal>5</normal>
		<long>10</long><!-- assuming these aren't always 2x normal -->
	</range>
	<proficiencyBonus>+3</proficiencyBonus>
	<damage>1d4</damage>
	<price>1</price>
	<weight>1</weight>
	<offHand>true</offHand>
</weapon>

I was going to suggest something like that too. I was just going to wait until we had figured out how to do characters before trying to tackle the xml schema for everything else (Races, Classes, Items, Etc).
Otherwise I agree the generic elements like choice aren't a good strategy.

EDIT: For the dagger might I suggest this instead:

<weapon name="dagger">
	<category>simple</category>
	<handedness>1</handedness>
	<melee>true</melee>
	<range>
		<normal>5</normal>
		<long>10</long><!-- assuming these aren't always 2x normal -->
	</range>
	<proficiencyBonus>+3</proficiencyBonus>
	<damage>1d4</damage>
	<price>1</price>
	<weight>1</weight>
	<groups><!-- Because some items have more then one group -->
             <group>light blade</group>
       </groups>
        <properties>
             <property>Off-hand</property>
             <property>light thrown</property>
        </properties>
</weapon>

 

[ninjeff]

megasycophant: Welcome to the thread! As a fellow geek, I can't help appreciating that your idea is awesome and cool: a schema that can validate a character all in one step. Unfortunately, I see two major problems with it.

First of all, it's infeasible. A schema like this would require updating not just with every new book, but also with every online Dragon article. The new version of the schema would then have to be distributed to application developers and users, who would have to have the latest version to be able to use their characters. Also, a feat like:

Flipflop
Choose attack rolls or damage rolls. You gain a +1 bonus to these rolls.

would necessitate the creation of an <attackOrDamageFeat> type, which seems a bit over the top. The types of choices in the books can vary wildly, which is why we're allowing most of them (not feats, skills, languages or powers) to be specified in plaintext.

Second, it's illegal. IANAL, but I'm pretty sure distribution of a schema containing a significant amount of the PHB's rules text would constitute a copyright infringement.

With these points in mind, I've decided to stick with a schema that only validates whether an XML file represents a 4e D&D character, not whether it's a correct character.

However, you're absolutely right that schemas for datasets are a good idea. If we have well-defined datasets, then application developers can hook into those rather than having to hardcode rules into their applications, which helps them avoid breaking laws. Users could enter the data on their own from the books (legal, AFAIK) or find datasets elsewhere (illegal, but not our problem). Maybe a parser could even be made to turn rules text into XML data.

 

[megasycophant]

Forgive me for chopping up your post to respond. Don't think I've rearranged it to take anything out of context.

Also, a feat like:

Flipflop
Choose attack rolls or damage rolls. You gain a +1 bonus to these rolls.

would necessitate the creation of an <attackOrDamageFeat> type, which seems a bit over the top. The types of choices in the books can vary wildly, which is why we're allowing most of them (not feats, skills, languages or powers) to be specified in plaintext.

I beg to differ. Now, representing the effects of feats/powers/etc would be a bit more laborious, but simpler in a way as well, since you're not validating data by the end user. Well-defined type derivations could cover it. (With perhaps a CYA type for the least common denominator, containing freeform exception text.)

Since we're talking about building a schema for character definition rather than building a rules engine, I only meant to imply that the choices associated with a feat/power would be built in, and I think those are relatively limited. Of course, I've only had the rulebooks for a few days, but I can't think of any powers off the top of my head that require a choice (some of the Ranger powers, frex, require two weapons OR a ranged weapon, but you don't CHOOSE either/or when you pick the power). There are some feats that require a choice, but your example is probably about as complicated as it gets.

With these points in mind, I've decided to stick with a schema that only validates whether an XML file represents a 4e D&D character, not whether it's a correct character.

I mentioned that as an aside in my post. If that's the objective, making things as simplistic as possible would be ideal and you're on the right track. I'll even rescind my statement about the generic attributes.

First of all, it's infeasible. A schema like this would require updating not just with every new book, but also with every online Dragon article. The new version of the schema would then have to be distributed to application developers and users, who would have to have the latest version to be able to use their characters.
...
Second, it's illegal. IANAL, but I'm pretty sure distribution of a schema containing a significant amount of the PHB's rules text would constitute a copyright infringement.
....
However, you're absolutely right that schemas for datasets are a good idea. If we have well-defined datasets, then application developers can hook into those rather than having to hardcode rules into their applications, which helps them avoid breaking laws. Users could enter the data on their own from the books (legal, AFAIK) or find datasets elsewhere (illegal, but not our problem). Maybe a parser could even be made to turn rules text into XML data.

I'm not sure how the GSL would cover such things. I wouldn't think we'd be defining more than the GSL allows (still under the assumption that we're not giving the details of feats/powers/etc, just config info). Seems like the touchy bit would be that they wanna have their own software for creation/maintenance of characters. I'm no lawyer, either. On legal grounds, though, I'd say we'd only distribute the schema for defining datasets, not the data itself. (Ah, brings back memories of PCGen.)

I attempted to address these points regarding maintenance, legality, etc in my post, but I was running out of steam at that point. A schema compiler is just what I'd propose. I don't like the actual data being defined in the schema either. I'd see it working this way, with rulesets in play:

• A schema is defined to define rulesets.
• User creates multiple datasets based on this schema. (Or fetches rulesets that are sanctioned by publishers.)
• A schema is defined which describes a schema for definition and validation of character data.
• Some magical construct (or software significantly advanced to appear as such to most) compiles the rulesets into said character schema.
• User creates character data based on this compiled schema.

Alernately, if rulesets are unavailable, a schema could be defined allowing for the same format which does minimal validation (sans rulesets). This would allow for "freeform" definition as well as definition/validation based on compiled rules.

So, I think we're in violent agreement!

 

[banana]

I've attached the latest schema and example characters in this post.

Looks good, I'll incorporate that into the next version of this character editor (I like the name "Four Ee" but typing it feels weird!). If it gets to a state where it is actually a useful tool I might post about it separately, but for now it's more of an experiment in working with this character description format. A very successful experiment, I might add - 4e seems very well suited to representing just a character's key, variable data and then deriving the rest in a deterministic way.

generalhenry is right, this is extremely nerdy - and a lot of fun.

 

[ninjeff]

Forgive me for chopping up your post to respond. Don't think I've rearranged it to take anything out of context.

Wouldn't dream of it.

Your position makes a lot more sense to me now, but I still have one major problem: won't a schema compiler effectively remove the interoperability that we're going for? If every user compiles their own schemas based on the books they own or their houserules, then won't applications lose the ability to easily parse characters? Forgive me if I'm getting the wrong end of the stick here, but it's really a deal-breaker for me.

So, I think we're in violent agreement!

We're definitely on the same wavelength with respect to defining rulesets, but I'm afraid the interoperability thing is a big problem for me. To me, the need for rulesets is not for defining character schemas but for allowing applications to turn character data into a playable character sheet (or even to run an online game!).

 

[megasycophant]

Your position makes a lot more sense to me now, but I still have one major problem: won't a schema compiler effectively remove the interoperability that we're going for? If every user compiles their own schemas based on the books they own or their houserules, then won't applications lose the ability to easily parse characters? Forgive me if I'm getting the wrong end of the stick here, but it's really a deal-breaker for me.

No, not at all. The application which merely displays/prints character sheets uses a minimal schema, the one that doesn't contain all the validation-type data, just validating format. Easier to illustrate with an example. Let's say that I have house-ruled the following feat:

Munchkin Attack
Your character's uber-power crackles in his fingertips.
Choose a weapon group. When using a weapon from this group, do damage equal to the player's birth year (unfortunately, you don't get to roll your loaded damage die).

Odd... "Munchkin" wasn't in my spellchecker's dictionary.

I have my houserules dataset, compiled it with my other datasets, yadda, yadda, yadda in order to create and validate my character data. The xml output for this feat looks something like this:

<feat xsi:type="WeaponGroupFeat"
 	name="Munchkin Attack" group="spears" />

My compiled schema which I used to validate my document defines the name attribute for a WeaponGroupFeat something like this:

<xsd:attribute name="name">
	<xsd:simpleType>
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="Weapon Focus" />
			<xsd:enumeration value="Munchkin Attack" />
			<!-- other feat names here -->
		</xsd:restriction>
	</xsd:simpleType>
</xsd:attribute>

I send it to someone else (or pull it into a display/formatting/printing tool). This tool uses the minimal schema (which is really all it needs). It knows about the WeaponGroupFeat type, but just knows enough to display it. The definition for name in its schema looks like this:

<xsd:attribute name="name" type="xsd:string" />

So, a 'good' document will validate against both schemas. Documents created with the 'enhanced' schema (containing all the data enumerations) etc will always conform to the minimal schema (but not necessarily the other way around). Also, documents could be created and manipulated using the minimal schema if a user doesn't feel the need to do the validation, programatically manipulate the data, etc.

The obvious first step is to create that minimal schema. (Which is essentially what your'e doing, eh?) It shouldn't change too much either once you've worked out the enhanced schema.

 

[megasycophant]

generalhenry is right, this is extremely nerdy - and a lot of fun.

Woah, there. Let's be careful about our terminology. This is clearly geeky, not nerdy.

 

[Agglomérante]

Wow, that's a lot of work! Thanks.

I tried a transformation on the sample file and it failed. If it's working at your end I'll take a hard look at my config (jEdit w XML/XSLT plugins). If you could confirm, that'd be awesome.

The WOTC e-tools subscription rates are actually cheap enough to convince me not to blow a weekend or longer designing my own tools, but I'm worried they won't implement a faceted navigation for powers, monsters, etc. The game's finally got fabulous structure, but from what I've seen of the e-tools WOTC doesn't have the time/money (or knowledge) to leverage it. It's a real shame.