D&D 4E Completely Unofficial 4e Dataset Xml Schema and Discussion (Updated 7/02)

[jimmifett]

Now with added Monsters, RAWR!

I added in a whole ton of stuff to support monsters. I'm not quite sure i like the powers portion of it yet, but it worked on theJester's Level 6 Tarantella.

There are, IMHO, a few things that could be reworked semanticaly with the original tarantella entry, but i'll save that for theJester's thread.

 

[Revinor]

To be honest I don't like it.

Way too verbose. RefIDs are ugly. Versioning is nice idea, but won't work in practice anymore (what fun it will be to have a character with feats from 6 different versions of core rules and having to copy full reference inheritance each time).

To take an example

<Feat ID="ID_798c55d8-3d49-11dd-ae16-0800200c9a66">
	<Name>Enlarged Dragon Breath</Name>

	<SourceInfo>
		<SourceMaterial RefID="ID_29636b80-43a1-11dd-ae16-0800200c9a66">Player's Handbook</SourceMaterial>

		<SourceDataSet RefID="ID_1d315f90-3d3c-11dd-ae16-0800200c9a66">
		<Name>CoreSet</Name>
		<Version>2008.06.06.0000</Version>
		</SourceDataSet>
	</SourceInfo>
	<DefaultCampaign RefID="ID_4c61dc70-3cb2-11dd-ae16-0800200c9a66">None</DefaultCampaign>
	<FeatTier IDRef="ID_87ab9f01-3d5c-11dd-ae16-0800200c9a66">Heroic</FeatTier>
	<FeatType IDRef="ID_a1c68552-3d46-11dd-ae16-0800200c9a66">Racial (Dragonborn)</FeatType>

	<FeatPrerequisites>
		<FeatPrerequisite>
			<Race RefID="ID_c85ef1a2-3318-11dd-bd11-0800200c9a66">Dragonborn</Race>
		</FeatPrerequisite>

		<FeatPrerequisite>
			<Power RefID="ID_73747a80-3ee1-11dd-ae16-0800200c9a66">Dragon Breath</Power>
		</FeatPrerequisite>
	</FeatPrerequisites>
</Feat>

Could be done as something like

<Feat id="PHB1:EnlargedDragonBreath">
	<Name>Enlarged Dragon Breath</Name>
	<Source book="PHB1" page="178">Player's Handbook 1, page 178</Source>
	<Tier>Heroic</Tier>
	<Category type="racial" subtype="PHB1:Dragonborn">Racial (Dragonborn)</Type>
	<Prerequisites>
		<Race id="PHB1:Dragonborn">Dragonborn</Race>
		<Power id="PHB1:DragonBreath">Dragon Breath</Power>
	</Prerequisites>
</Feat>

Basically, differences in my proposal are as follows:
a) no possibility to have more than one version of same ability/feat/etc - I see it as a major benefit, allowing transparent updates as one of the effects
b) human readable ids
c) namespace of ids reserved only per type (feat, race, power, etc), not global
d) Getting rid of all the source info duplicated in every entry
e) bit of duplication of data in attributes, to have attributes machine-parseable in addition to full text for thin clients
f) more context-oriented naming, no need to wrap <Race> inside <Prerequisites> into <Prerequisite>

I don't expect you to take any action on that - I just wanted to vent my frustration on some xml schemas which were designed to be machine generated and everybody ended up typing them by hand even a year later...

 

[jimmifett]

I can see where you are going with the simplified approach to things. That looks excellent for human readable xml.

However, I'm a developer by trade and my focus is on datasets for applications and databases. The RefIDs are specifically for use in middleware software loading data into databases as primary keys, hence the GUID. They also serve as a way for the middleware loader to check all dependencies against the current database and warn the user before import that their data is out of date.

When distributing the datasets, the RefIDs, when validating against a schema, allow a program/user to make sure they included all the descriptive data they need for their dataset. I do this to make sure datasets do not get sloppy.

A lot of 'duplication' you point out is due to making the xml 'classable' into objects types in programming languages. Specifically the XMLBeans apache project that creates and compiles java objects based on schemas (XmlObject base class) with all the setters and accessors involved. I believe also dotNet has a form of this as well.

I'm sure you know all this already, I point it out for others not up on programming, let alone object oriented stuff.

Additionally, as pieces of the schema solidify, I'll be creating SQL queries to build tables and such based on the schema for others to use.

I know several areas in my schema I want to clean up and standardize with other items in the schema, and I'm getting to them in time.

 

[Asmor]

Just a suggestion-- I found Orcus helpful testing out my monster maker, because he's one of (maybe the?) most complicated monsters in the Monster Manual. Multiple auras, which off the top of my head I can't think of any other critters that have more than one aura, and he's got something for every "field" except vulnerabilities.

 

[Micco]

I'm really glad you are doing this, Jimmifett.

I just wanted to drop a line to note there are people paying attention and eagerly awaiting completion of you schema. Hopefully it will create something of standard. I'm going to point the people over at MapTools to your thread. There's a group on the MapTool forum working on creating standard formats for the tokens for that open source VTT (which rocks, btw) for 4e.

It would sure be handy to have a shared schema so that I don't have to write some middleware to translate between yours and theirs!

I'd be happy to test any apps you have if you are looking for some input.

Thanks for your efforts!

 

[jimmifett]

Just a suggestion-- I found Orcus helpful testing out my monster maker, because he's one of (maybe the?) most complicated monsters in the Monster Manual. Multiple auras, which off the top of my head I can't think of any other critters that have more than one aura, and he's got something for every "field" except vulnerabilities.

I created a paraphrashed Orcus and made some changes to the schema to fix stuff i'd missed. (That Demon Prince of the Undead Guy, in OP)

I also gave him lore checks, a description, and some tactics.

Do you have an example of someone with vulnerabilities i can glance at? Too tired to dig through the MM at the moment.

 

[Asmor]

A quick google search found that someone typed up the Rotwing zombie and it's got vulnerable radiant 5. At work so I can't confirm that, but it seems likely.

http://www.enworld.org/forum/showpost.php?p=4269004&postcount=45

 

[jimmifett]

A quick google search found that someone typed up the Rotwing zombie and it's got vulnerable radiant 5. At work so I can't confirm that, but it seems likely.

http://www.enworld.org/forum/showpost.php?p=4269004&postcount=45

Ah, that was easy enough. Added in vulnerabilites to the schema for monsters.

I'm thinking of breaking the image tags out of everything that has them. I'm thinking of giving images it's own higher level area, and instead have the tags in their current place reference the main area. I think i'd make that IDRef optional so that image sets can be in seperate files from the actual datasets. I don't know. I'll have to ponder this and it's implications...

 

[Asmor]

Ah, that was easy enough. Added in vulnerabilites to the schema for monsters.

I'm thinking of breaking the image tags out of everything that has them. I'm thinking of giving images it's own higher level area, and instead have the tags in their current place reference the main area. I think i'd make that IDRef optional so that image sets can be in seperate files from the actual datasets. I don't know. I'll have to ponder this and it's implications...

*nods and smiles* Shiny things are shiny.

 

[misterdo]

I agree with Revinor

To be honest I don't like it.
...
Could be done as something like

<Feat id="PHB1:EnlargedDragonBreath">
    <Name>Enlarged Dragon Breath</Name>
    <Source book="PHB1" page="178">Player's Handbook 1, page 178</Source>
    <Tier>Heroic</Tier>
    <Category type="racial" subtype="PHB1:Dragonborn">Racial (Dragonborn)</Type>
    <Prerequisites>
        <Race id="PHB1:Dragonborn">Dragonborn</Race>
        <Power id="PHB1:DragonBreath">Dragon Breath</Power>
    </Prerequisites>
</Feat>

Basically, differences in my proposal are as follows:
a) no possibility to have more than one version of same ability/feat/etc - I see it as a major benefit, allowing transparent updates as one of the effects
b) human readable ids
c) namespace of ids reserved only per type (feat, race, power, etc), not global
d) Getting rid of all the source info duplicated in every entry
e) bit of duplication of data in attributes, to have attributes machine-parseable in addition to full text for thin clients
f) more context-oriented naming, no need to wrap <Race> inside <Prerequisites> into <Prerequisite>
...

I have to agree here... It's great that someone is putting in the work to get all of this codified, but the xml could be much less verbose. The GUID's are ugly and really unnecessary as it would be fairly trivial to define a unique, readable source attribute to allow redefinition with new rules- or use a namespace as above.
d) is definitely important- it's rather the point of having an ID, no?
With e) I would even eliminate more of the full text as it could be easily created from the attributes or even declared once as an xml entity.
I don't buy the code generation argument. There is nothing in XMLBeans that requires complex UIDs. A simpler schema will allow people to find errors, update rules, and contribute in other ways.
As far as validation- that's the point of the schema, isn't it? It is easy enough to find errors if an xml document is non-conformant...
Just my 2c. Good initiative with this project.