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

[Zaster]

OK, I feel a little stupid here... Why can't my browser read this stuff? Neither Firefox 3.0 nor IE 6 seems to render this stuff correctly. I see alot of naked tags in front of everything and it's obvious it's not formatting correctly. Do I need some sort of plug-in? Please pummel me with the clue bat.

 

[Asmor]

Your browser isn't supposed to be able to read it. You should probably just ignore this, it's not useful to you directly so much as it's useful to other people who then use it to make things which are useful to you.

 

[jimmifett]

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.

Datasets based on this schema are not intended to be handwritten. I handwrite them bc I created it, understand what is intended with the schema, and have a wonderful tool for assisting me in handwriting. It is intended to be used and written by programs.

The point of the GUIDs is to make sure anyone who adds content does not inadvertantly use another key being used by someone else in a completely seperate and unrelated dataset. When yet another person decides to use both of them for whatever reason, that person can be safe in knowing that they wont have duplicate keys. (yes, i know, GUID is not truly unique, but it's awfully darn close and a lot of thought went into them to make them that way, hence the standard)

Naturally, XMLBeans has nothing to do with GUIDs. It does however, have a lot to do with making objects as i'm sure you are aware.

I specifically made some things verbose as they have different properties than other related things, as well as different uses. I wanted to be able to define the specifics of something in one area, and then load a much simpler reference in a different area. In portions that have similar data, forexample, a power's keywords, I wanted to make sure that the keywords are segregated into grouped categories. I don't want to mix damage types with effect types or accessory keywords. Some powers also describe offering a choice of keywords for the user to select and apply, such as dragon's breath. I wanted to differentiate these choice of selection keywords from regular keywords.

Additionaly, I wanted there to be the ability to have mulitple choice groups, such that I can make choice (1) in a first group of items, and choice (2) from a second group of elements. To represent things like this, I have to make things a bit more complex than what some others above have suggested.

Back to the GUIDs, my intention with SQL is for there to be many tables, each with an entry containing the guid. The guid is a indexable unique key, but shouldn't be the Primary Key, as that should be some sort of integer. Rows in other tables would use that integer as a foreign key to link themselves together and provide consistency in the DB. That begs the question then, "how do I make sure new data i'm creating or importing in my local database does not unintentionally overwrite data in someone else's local database? Surely they could just as well have a diferent integer for the same item that I have." My solution, GUID stamped entries. An import program would look at an item's ID attribute, then check the apporpriate table via index to see if that item already exists. If it does, it can then compare the source datasets and the versions to see if it is importing new data. It can then add that item to it's tables generating an integer Primary Key for reference in other tables. As we all know, integers are often the best sql datatype for primary and foreign keys. As i've said above, the GUID is also used here when you create your own data and want to share with others, you primary key integer won't be very useful to others, since it may already be in use for a different item in their database. Thus, you supply your own GUID for the item you wish to share from your tables. (Any program, when adding new data, should be creating GUIDs to insert into the DB as well.)

For those wondering just what in the nine hells a GUID (or UUID) is:
Globally Unique Identifier (Universally Unique Identifer)
It can be represented several ways, I use ones that are based off time and node (version 1 UUIDs) using hex in a 8-4-4-4-12 format. This is the UUID Generator I use most often when I am inputting data by hand. There is also version 4 that instead of time / node, uses random numbers for generating. There are several libraries for various programming languages to do they same.

While UUIDs are not gaurenteed to be unqiue, the keyspace is so large (2^128) that it is widely felt that the chance of overlapping is sufficiently small, when used for a specific purpose such as differentiating similar data, there is a presumption of uniqueness.

And knowing is half the battle.
(the other half involves lots of guns)

-J

 

[jimmifett]

OK, I feel a little stupid here... Why can't my browser read this stuff? Neither Firefox 3.0 nor IE 6 seems to render this stuff correctly. I see alot of naked tags in front of everything and it's obvious it's not formatting correctly. Do I need some sort of plug-in? Please pummel me with the clue bat.

Nothing is wrong with your browser

This is how raw xml data looks when you haven't massaged it.
Other ppl can make the data look pretty using things such as XSLT (Xml Transformations) that can take this data, format it a certain way, and wrap html tags around it so it can look good

Sadly, I am not that great with XSLT, let alone with making things pretty, so I leave that to others for now. Stupid engineer side of me

 

[Zaster]

Thanks Jimmifett & Asmor, for destroying my confusion.

I'll just close the door to this alchemist's laboratory and back away slowly. But I had to, you know, investigate those strange odors wafting up the stairs. Good luck with your experiments.

I just hope you realize that in the Old West, this entire thread would get you shot for "Satan talk".

 

[Asmor]

Not a problem, we could always just import bulletproof.

 

[AbdulAlhazred]

Anyone still working on this?

Seems to me this is definitely something that would be highly useful. There are various people who have developed PDF and HTML libraries of powers, etc, but those certainly have vastly lesser utility than XML versions, and I would much rather generate XML based on some standardized schema that everyone is using vs doing it all myself.

Not only that, but once a schema exists it becomes fairly straightforward to autogenerate a basic GUI to allow CRUD to a database, etc. Looks like this thread hasn't been visited in quite a while, so if the project is dead I might consider looking into making it go forward again (or perhaps there is an alternative or the project has migrated someplace?).

 

[Asmor]

I think at this point it would be prudent to wait for WotC to release the character creator before doing any further work on schema. I do believe they've said that characters will be saved as XML, so it would be most beneficial if the developed schema were compatible with WotC's own.

 

[AbdulAlhazred]

I think at this point it would be prudent to wait for WotC to release the character creator before doing any further work on schema. I do believe they've said that characters will be saved as XML, so it would be most beneficial if the developed schema were compatible with WotC's own.

Quite true. Now, do I have the slightest confidence they can come up with a good schema? No. But of course there is always a first time... Anyone have any idea when this character creator is likely to actually materialize? hehe.

 

[the_redbeard]

You can already download a beta of the Character Builder.

It only has the first three levels, and there are some bugs. It IS a beta after all.

But after having very diminished expectations from previous WoTC software efforts, I am VERY impressed by the usability of the character generator.

They do use XML for the character file, and I've attached a sample. (The builder uses the extension .dnd4e which isn't a legal extension to upload on enworld so I renamed it rtf.)

Here's the link to WoTC's beta feedback if you want to tell them about their XML schema.