Suite Interoperability

[Twin Rose]

The XML files are included in the CSX beta. Since it IS in beta, there is still more evolvinmg to the XML itself, but since we have a good solid 'back bone' getting suggestions of "Hey, this is needed.." is much easier at this point. The beta files are located at:
www.twinrose.net

 

[soulcatcher]

>>> quick answer is that if it's designed for a particular program is has certain asumptions. Generally that's a gaurentee. I'm hoping to have a format that will not have those assumptions. Developing a new XML format is not all THAT hard.

You seem to have assumed it won't work and have started on your own. Or did you look at it and find problems?

I'm all for an interoperability standard but I'm against spending my limited time on tasks that don't require it (and may not go anywhere). There's an XML standard out there already - Chris's. It's (mostly) done. It works (far as I know, haven't delved into it). It has user support. I see no reason to create some other standard. I'll use Chris's.

Actually, I have yet to get access to it. I started one mostly to jump start dialog. It worked .

I'll be happy to look at it. And as I said before, I'm not against using it. However, I do want to make sure it's good as an exchange format, not as file format that is excellent for one program, and gimped for others.

Chris seems very willing to extend it too, so that is an excellent sign.

Devon

 

[Twin Rose]

Actually, I have yet to get access to it. I started one mostly to jump start dialog. It worked .

Chris seems very willing to extend it too, so that is an excellent sign.

I learned early on working with DarkSir, who was making his own custom character sheets (for use for all CS users, I hope! hehe)... That extending it is necassary. What I 'assume' and what others assume is almost never the same. Without knowing what the data is, it's easy to make sure CSX knows to "add value x y and z". That's a little harder in a stylesheet. And it's just better in the long run anyway

 

[andargor]

Hi all,

As I had mentionned before in Twin Rose's thread, I am doing some research on abstracting XML data to create a concept for an open framework for character creation engines (any RPG).

I've attached a (messy) illustration of what I am trying to acheive.

As you can see, interoperability is at the core of the concept. What I call the "Data Abstraction Layers" (DALs), used to convert data files in a "generic" format per RPG system and back to engine-specific formats.

This would allow easier submission of material by users and publishers who wish to release electronic material for the purposes of character creation (a trend that I would wholeheartedly support).

Some of you may think that I have smoked some good stuff this morning, and you are maybe right. This diagram is utopic, but some concepts, IMHO, would be readily implementable.

Andargor

 

[soulcatcher]

Just wanted to let you know that I havn't ignored your post with the diagram - just still digesting it.

I think as a whole, it's a good idea - but it's also very ambitious. I wonder is there is a way we can tackle the D&D character sheet transfers without hitting all of this - yet still building something with this type of proposal in mind.

Devon

 

[Athrawn17]

As an export you are thinking about for a character sheet and such I believe correct?

And this would just be a raw data dump? Which would conform to the, let's call it a "standard" for now. Right?

Then anyone should be able to make their own XSLT and make pretty char sheets out of the data, no matter what software did the dumping.


My question then, after looking at the CSX XML data, is that it's just a standard for the output data. Should there also be a standard for the storage of the data.......

Really each product could then do whatever they wanted with the data...apply rules and such...but just having an output "standard" is only half of the solution. One would also need a storage "standard" so I could add all the custom info I wanted to, and then import it into whatever program I, or my GM, feels like using.


Sorry, I should introduce myself as well. I've been working on this as a hobby for about 2 years now. My senior project in college was doing this. I have a schema for storage and the software (written in java), gives the user a nice lovely GUI to create all this data in xml. Which then the second piece, the part that's not done yet, would use to create the raw character data dump. It's a hobby and something I do to relax (writting insurance software can be very boring at times, but it does pay the bills). Anyway, just my two bits on this....since my software doesn't even work yet

Cheers!
Athrawn17

 

[DMFTodd]

My question then, after looking at the CSX XML data, is that it's just a standard for the output data. Should there also be a standard for the storage of the data.......Athrawn17

My thinking is that each individual application is probably going to need application specific data structures to work with. The "data dump" format is mainly for importing/exporting between applications.

So, say we have a format for spells. Me, the DM, has all the spells for my campaign in DM's Familiar. I could dump all those spells (or just the ones the PCs are allowed to have), or one of them, to the XML standard. My players, who use Campaign Suite for putting their characters together, can import those spells for building their characters.

Granted, it would be nice if we had a standard for data storage - so that DM's Familiar can read the same file that Campaign Suite did - but that is lots of work for not much gain in my mind (all it accomplishes is the removal oif the import/export steps, we still need the data dump for printing, etc.).

My mindset is very practical oriented in this stuff I think. We have next to no interoperability now (other than my stat block import, I don't know that there is *any* interoperability). Chris' XML provides a couple steps forward we can move on this. I'm going to concentrate my effort into taking those first couple small steps now. I'll worry about acheiving the top of the mountain later.

 

[andargor]

I think as a whole, it's a good idea - but it's also very ambitious. I wonder is there is a way we can tackle the D&D character sheet transfers without hitting all of this - yet still building something with this type of proposal in mind.

Yes I agree, it is utopic at this point. I was just trying to take a step back to get a sense of the overall picture.

For what you are discussing here, what is needed is the centerpiece: a generic XML format for the storage of D&D data (my example includes any RPG, but that is not really necessary). And this is what is hardest to achieve, get everyone to agree

Really each product could then do whatever they wanted with the data...apply rules and such...but just having an output "standard" is only half of the solution. One would also need a storage "standard" so I could add all the custom info I wanted to, and then import it into whatever program I, or my GM, feels like using.

That's what I'm talking about. Someone can write their own XML data files, convert from a book or whatever, and apply a transform to put it in a generic format which is not software specific (I used the "DAL" buzzword ).

Then, another software writer can import the data into his program using another transform, specific to him/her. This means that the "generic" format is stable and is not dependent on software versions or OSes.

After all, the generic data should never be modified after creation, only if there are errors/errata. This means infinite reusability.

Granted, it would be nice if we had a standard for data storage - so that DM's Familiar can read the same file that Campaign Suite did - but that is lots of work for not much gain in my mind (all it accomplishes is the removal oif the import/export steps, we still need the data dump for printing, etc.).

With the approach above, you would only need to maintain two small pieces: a transform to get generic data imported to a format suitable to your program (probably optimized for indexing and hashing and such), and another to export any data in your program you wish to share (if you want to do so).

Andargor

 

[Athrawn17]

And this is what is hardest to achieve, get everyone to agree
Andargor

Not really...someone just has to take the initiative and make the best format. If everything in the world was based on getting everyone to agree...we wouldn't get anywhere.

If a person makes a product and even if it's not 100% perfect, as long as the majority of a community uses it then we have achieved, IMHO, our goal.

We really are just trying to get everyone to play nicely with each other because we as gamers are tired of making kick ass spells and items and not being able for our fellow gamers to use them, because they have choosen a different product.

Also I think that this should NOT be done by any of the larger generators. The reason for this is because if a product is defining this, then they will be in a position where they have a head start in implementing it. However, on the other hand, if the products which everyone uses refuse to adapt, then the work will be all for nothing.

Finally, I think that there needs to be away to easily add information to this format. If a standard is made, then a GUI should be released with the standard. While most d20 players are at least somewhat computer literate, I'm not sure how many would feel comfortable editing XML directly. I would wager that there would be quite a few that would be able to fill out forms to enter the data though.

 

[Hollywood]

When I was forced to use "CS stuff" in it, it's usually indexing, and then I'll also have a 'string tag' for the same thing.. One is to speed up load in CS (and of coruse, anyone can use the same indexing, there's no law against that) and the other is for others to use. Working with my data-entry folks, we're making it extra robust. Even if the program itself doesn't USE all the tags, it still keeps the nodes aroudn and puts them out there for things like custom character sheets. I'm a believer in putting "more" in the data-files than may be needed for completeness, and the way people like their data formatted differently, that seems to be a good idea.

Mmms, well I downloaded the beta, after no responses from polite email inquiries, and created a character and saved him. Hopefully that the program is still in beta, you will be open to suggestions from the community XML format isn't bad, it could use some work though too. Lots of stuff isn't grouped together that should be, some of it is though [such as Skills, Feats, etc.].

To throw another DTD out into the mix, I've been putting together Character Viewers for the PocketPC and have been focusing on M&M, but the basics apply to all the d20 products I've seen so far. Anyways, here it is. You can see everything is broken up into discrete blocks of data. This helps keep things organized, but also helps with finding data on limited resource devices. I should note that currently it has the character abilities hard-coded. I think you could go one way or another on this, but it should probably not be that way. Same applies to the saving throws. At this time, its not namespaced at all, but it should be namespaced based on the information type, i.e. all the SRD stuff should be noted in a SRD namespace, all the 3.0 should be in a 3.0 namespace, d20Modern in its own namespace, M&M stuff in its, etc.

<?xml version="1.0" encoding="UTF-8"?>
<!ELEMENT CHA (#PCDATA)>
<!ATTLIST CHA
mod CDATA #REQUIRED
>
<!ELEMENT CON (#PCDATA)>
<!ATTLIST CON
mod CDATA #REQUIRED
>
<!ELEMENT DEX (#PCDATA)>
<!ATTLIST DEX
mod CDATA #REQUIRED
>
<!ELEMENT DMG (#PCDATA)>
<!ELEMENT FORT (#PCDATA)>
<!ELEMENT INIT (#PCDATA)>
<!ELEMENT INT (#PCDATA)>
<!ATTLIST INT
mod CDATA #REQUIRED
>
<!ELEMENT REF (#PCDATA)>
<!ELEMENT STR (#PCDATA)>
<!ATTLIST STR
mod CDATA #REQUIRED
>
<!ELEMENT WILL (#PCDATA)>
<!ELEMENT WIS (#PCDATA)>
<!ATTLIST WIS
mod CDATA #REQUIRED
>
<!ELEMENT ability_block (STR, DEX, CON, INT, WIS, CHA)>
<!ELEMENT age (#PCDATA)>
<!ELEMENT attack_block (base, melee, ranged, mental)>
<!ELEMENT background (#PCDATA)>
<!ELEMENT base (#PCDATA)>
<!ELEMENT birthplace (#PCDATA)>
<!ELEMENT capacity_block (light, medium, heavy, maximum, lifting, dragging)>
<!ELEMENT character (character_block, ability_block, save_block, damage_block, condition_block, movement_block, capacity_block, attack_block, defense_block, feat_block, weakness_block, skill_block, language_block, power_block)>
<!ELEMENT character_block (guid, name, realname, level, race, points, initiative, size, hero, age, gender, height, weight, description, personality, background, birthplace, firstappearance, occupation, quote, notes)>
<!ELEMENT condition (#PCDATA)>
<!ATTLIST condition
guid CDATA #REQUIRED
>
<!ELEMENT condition_block (condition)>
<!ELEMENT damage_block (stun, lethal)>
<!ELEMENT defense_block (base, standard, flatfooted, mental)>
<!ELEMENT description (#PCDATA)>
<!ELEMENT document (player_block, character)>
<!ELEMENT dragging (#PCDATA)>
<!ELEMENT email (#PCDATA)>
<!ELEMENT feat (#PCDATA)>
<!ATTLIST feat
guid CDATA #REQUIRED
appliesto CDATA #IMPLIED
>
<!ELEMENT feat_block (feat+)>
<!ELEMENT firstappearance (#PCDATA)>
<!ELEMENT flatfooted (#PCDATA)>
<!ELEMENT gender (#PCDATA)>
<!ELEMENT guid EMPTY>
<!ELEMENT heavy (#PCDATA)>
<!ELEMENT height (#PCDATA)>
<!ELEMENT hero (#PCDATA)>
<!ATTLIST hero
max CDATA #REQUIRED
>
<!ELEMENT initiative (#PCDATA)>
<!ELEMENT language (#PCDATA)>
<!ELEMENT language_block (language)>
<!ELEMENT lethal (#PCDATA)>
<!ELEMENT level (#PCDATA)>
<!ELEMENT lifting (#PCDATA)>
<!ELEMENT light (#PCDATA)>
<!ELEMENT maximum (#PCDATA)>
<!ELEMENT medium (#PCDATA)>
<!ELEMENT melee (#PCDATA)>
<!ELEMENT mental (#PCDATA)>
<!ELEMENT movement (#PCDATA)>
<!ATTLIST movement
base (30 | 60) #REQUIRED
run (120 | 60) #REQUIRED
sprint (120 | 3840) #REQUIRED
multiplier (4 | 64) #REQUIRED
>
<!ELEMENT movement_block (movement+)>
<!ELEMENT name (#PCDATA)>
<!ELEMENT notes (#PCDATA)>
<!ELEMENT occupation (#PCDATA)>
<!ELEMENT personality (#PCDATA)>
<!ELEMENT player_block (name, email, url)>
<!ELEMENT points (#PCDATA)>
<!ELEMENT power (#PCDATA)>
<!ATTLIST power
guid CDATA #REQUIRED
root CDATA #IMPLIED
DC (15 | 20 | 22) #IMPLIED
level CDATA #IMPLIED
appliesto (Super-Con | lead | light) #IMPLIED
flaw CDATA #IMPLIED
extra CDATA #IMPLIED
stunt CDATA #IMPLIED
>
<!ELEMENT power_block (power+)>
<!ELEMENT quote (#PCDATA)>
<!ELEMENT race (#PCDATA)>
<!ELEMENT ranged (#PCDATA)>
<!ELEMENT realname (#PCDATA)>
<!ELEMENT save_block (DMG, REF, FORT, WILL, INIT)>
<!ELEMENT size (#PCDATA)>
<!ELEMENT skill (#PCDATA)>
<!ATTLIST skill
guid CDATA #REQUIRED
total CDATA #REQUIRED
rank CDATA #REQUIRED
>
<!ELEMENT skill_block (skill+)>
<!ELEMENT standard (#PCDATA)>
<!ELEMENT stun (#PCDATA)>
<!ELEMENT url (#PCDATA)>
<!ELEMENT weakness (#PCDATA)>
<!ATTLIST weakness
guid CDATA #REQUIRED
appliesto (Amnesia | Kryptonite) #IMPLIED
>
<!ELEMENT weakness_block (weakness+)>
<!ELEMENT weight (#PCDATA)>

I should note that this format was started some time ago, and definetly way before the TR started their init to convert to XML. I'm just throwing this out for examples sake, as I think some communication on the subject is good [but not as much as the yahoogroup thats trying to represent 3rd Ed. in XML.. thats a lost cause I think].