Suite Interoperability

[Hollywood]

Ok, to continue on a bit. The DTD I posted is based on only the SRD material needed in M&M [i.e. no equipment lists really, no hitpoints, etc.] and while I could generate a DTD for this, I'll just post a 3.0 character instead. Easier to do a diff on the output from the beta CSX to compare and contrast. This is a slightly older format that I've had around for at least 2 years that works with a HTML/Javascript based chargen [no, I won't release it.. its a complete kludge and was mainly a technology play-area... but it works for me as its highly adaptable to my group's house rules! ] and should really be updated. Anyways, here he is, the greatest halfling hero (r) ever, Nevin [FYI, I've cut out most of the "text" for readability, but if anyone is interested feel free to email me]!

Ok, that posting was just completely unreadable!! Anyways, here is a link to Nevin's XML file.

P.S. Just for clarification, the "guid" is a unique identifier, it could be anything. I've chosen to use Window's GUIDs for the Pocket PC and UIDs in Java/Javascript. It should be noted that the UIDs are not as globally unique in Java, but it should server without too many problems.

 

[Hollywood]

I'm having a blast with XSL.

Glad someone is.... I hate it. Speaking of XSL, here is an XSL sheet that will transform the XML of Nevin I posted. I know it works with Apache's XSLT processor but also needs the bsf engine and the rhino javascript add-on jars.

 

[Fractalwave]

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.].

You probably caught Chris when he was taking a few days off and I don't check these boards daily. He is back now but he'd a bit backlogged. I'm sure he's open to suggestions. Just give him the weekend to catch up.

 

[andargor]

Let's not let this thread die...

I've actually seen some movement in the d20-XML group! (Incredible, I know) I think we are on the verge of something, seeing the transform that Hollywood posted.

If I may make one comment: my belief is that the content of interoperable character sheets only need to have user inputs. Why is it necessary to have all the calculations? Don't the engines know the rules?

All that should be in there is "the user chose Str 18, Dex 13, etc.", "the user put 2 skillpoints at level 2 into Craft (Alchemy)","the user rolled 8 for hitpoints at level 5", etc.

Custom feats are probably more troublesome, and spell/item descriptions would still need to be relatively standard, but that is "data" as opposed to "user input".

Am I making any sense?

Andargor

 

[Hollywood]

I've actually seen some movement in the d20-XML group! (Incredible, I know) I think we are on the verge of something, seeing the transform that Hollywood posted.

Well, last I looked, their's was pretty detailed. Probably way too detailed.

If I may make one comment: my belief is that the content of interoperable character sheets only need to have user inputs. Why is it necessary to have all the calculations? Don't the engines know the rules?

Not necessarily no. Think about creating a XSLT to transfer an XML character.. unless the XML has the information on modifiers, etc. you will only get a very very simple character sheet in transformation. Shouldn't have rules in the character data, but you should provide ALL the necessary, non-descriptive, information necessary to output the character without need to "know the rules".

Custom feats are probably more troublesome, and spell/item descriptions would still need to be relatively standard, but that is "data" as opposed to "user input".

Definetly, if its a custom object (i.e. class, feat, skill, equipment, spell, weapon, et al), at the very least the character data should have the description block for that object. More than likely the engine that created the custom object will also output any "engine specific rules" necessary to import and recreate that object elsewhere, which is prefectly fine.

 

[andargor]

Well, last I looked, their's was pretty detailed. Probably way too detailed.

I agree, but I just wanted to point out that there was some movement. If only it doesn't degenerate into more bickering and we can get something out, even if it isn't perfect.

Not necessarily no. Think about creating a XSLT to transfer an XML character.. unless the XML has the information on modifiers, etc. you will only get a very very simple character sheet in transformation. Shouldn't have rules in the character data, but you should provide ALL the necessary, non-descriptive, information necessary to output the character without need to "know the rules".

I see what you are saying, you wish to allow the creation of "pure" output tools that uses the "common" XML? I submit, however, that tracking user input is necessary to avoid other tools (or the transforms) having to reverse-engineer bonuses, which may lead to errors. Maybe both, output data and user inputs, should be included in the sheet, which shouldn't be a big problem.

Andargor

 

[Hollywood]

I see what you are saying, you wish to allow the creation of "pure" output tools that uses the "common" XML?

Yup

I submit, however, that tracking user input is necessary to avoid other tools (or the transforms) having to reverse-engineer bonuses, which may lead to errors. Maybe both, output data and user inputs, should be included in the sheet, which shouldn't be a big problem.

The data is more important, and if you output all the variables, then you should be ok. But you could also track what the user inputs were too if desired.

 

[DarkSir]

In theory, writing a transform for CSX that will output a standard like what you're talking about would be relatively painless.

However, the standard that you listed probably wouldn't work as a default for CSX. Since the outputted XML file isn't an export, per se, as much as it is the entire save file for the character (Which needs to contain progression history and whatnot, so that you can actually back your way out of what you've already done) No other standard is probably going to need that information.

So, my suggestion would be for someone (probably me, at some point ) to make a transform that would alter CSX's charactersave XML into an exportable XML.

Jay

Yup



The data is more important, and if you output all the variables, then you should be ok. But you could also track what the user inputs were too if desired.

 

[Hollywood]

In theory, writing a transform for CSX that will output a standard like what you're talking about would be relatively painless.

However, the standard that you listed probably wouldn't work as a default for CSX. Since the outputted XML file isn't an export, per se, as much as it is the entire save file for the character (Which needs to contain progression history and whatnot, so that you can actually back your way out of what you've already done) No other standard is probably going to need that information.

So, my suggestion would be for someone (probably me, at some point ) to make a transform that would alter CSX's charactersave XML into an exportable XML.

The point is you shouldn't have to necessarily write a transform [of which no process is relatively painless, no matter what you claim :/] to transform CSX, or any other supporting product, "character save" into exportable XML. If the XML datastore is properly designed, it would be able to support multiple products without affecting any other products. The following are needed:

a) Basic character data in an "exploded" format that gives as much information as possible so that even "dumb" clients can convert and display or use the information. Examples currently have been bandied about here, including both CSX and the example I tossed up. Both of those two contain very similiar data, but I'd say mine has things grouped together better which can help going forward to other d20 products.
b) Any custom tracking information on how the character was built in a particular app. The XML datastore can handle multiple products easily, and it is not necessary at this point to have a common data structure except at the root entry point.
c) The ability to support custom data, i.e. those new feats, equipment, etc. At very least a common data format can be specified to contain at least an id, name, description. You can go further to describe come other common attributes. Custom elements can be embedded as needed for proprietary scripts, etc. that are needed by a particular application.

Having all a, b, c in one XML data format that represents a character will allow characters to be imported/exported between various applications without a lot of need for converting or transforming custom protocols. The character and its data would be spelled out in a detail manner in the first section (a) that any client can use.

Individual clients may embed custom save information in section (b) which can be safely ignored [but never modified or removed] by other clients. It matters very little that non-CSX clients may not need that information, but its there in case the character gets imported back into a CSX client. A hypothetical example: A character created in CSX gets exported and sent to the GM. The player uses another tool to create a beautifully formatted output via an XSL transform he wrote so that he can bring his character to the game. Perhaps another player downloads the character to his PDA and pulls it up on a character view app. The GM uses the character in DMGenie, or RPM or other similiar application, and modifies the character during the adventure. The character could then be sent back to the player after the adventure and the player cold load it back up into CSX. The XML data format for the save would have all the character's data, plus any custom content needed for that character, plus any proprietary data needed for CSX, DMGenie, or whatever. When the format is being used in CSX, of course it'd only access the character data, the custom data, and the proprietary CSX data, leaving the DMGenie, etc. data alone and untouched.

Lastly any custom information can be stored in section (c) and used by other clients [of course, clients are responsible to make sure that they don't export proprietary content to an inherintely unsafe format].

All that being said, I really don't consider the CSX format ideal anyways for at least one reason; the use of non-unique names as an "id". Even E-Tools got this right by assigning all "objects" a unique id in the form of a GUID. Using unique identifiers, such as a GUID, is the only way that two clients of different types, and even two clients of the same type, are going to know whether two "objects" are the same or not.

 

[andargor]

Having all a, b, c in one XML data format that represents a character will allow characters to be imported/exported between various applications without a lot of need for converting or transforming custom protocols. The character and its data would be spelled out in a detail manner in the first section (a) that any client can use.

I have no problem with custom info from different tools being stored in the export, and that is safely ignored by other tools. Maybe I didn't understand your example correctly, but if changes are made in another tool, then a common way of indicating that those changes have been made to other tools would have to be implemented. I still maintain that "recorded" user choices is probably the most tool independent way to do this.

All that being said, I really don't consider the CSX format ideal anyways for at least one reason; the use of non-unique names as an "id". Even E-Tools got this right by assigning all "objects" a unique id in the form of a GUID. Using unique identifiers, such as a GUID, is the only way that two clients of different types, and even two clients of the same type, are going to know whether two "objects" are the same or not.

Ah. The unique ID issue. There are two ways of doing it:

- Having a central repository to ensure there are no GUID collisions. It would need to be relatively real-time in order to not slow down anyone's development (i.e. it can't be a periodically published list). Also, it needs to be OS independent (I know Windows has a facility for generating "random and unique" GUIDs, but it won't apply to Macs or Linux)

- Using game system elements to establish uniqueness. I submit that a name, a type, a version, and a source reference (perhaps with the game system name) would be sufficient. For example, I have not seen duplicate D&D feats named X from the same source, except errata (and the version tag fixes that).

In theory, writing a transform for CSX that will output a standard like what you're talking about would be relatively painless.

However, the standard that you listed probably wouldn't work as a default for CSX. Since the outputted XML file isn't an export, per se, as much as it is the entire save file for the character (Which needs to contain progression history and whatnot, so that you can actually back your way out of what you've already done) No other standard is probably going to need that information.

So, my suggestion would be for someone (probably me, at some point ) to make a transform that would alter CSX's charactersave XML into an exportable XML.

Jay

The point is you shouldn't have to necessarily write a transform [of which no process is relatively painless, no matter what you claim :/] to transform CSX, or any other supporting product, "character save" into exportable XML. If the XML datastore is properly designed, it would be able to support multiple products without affecting any other products. The following are needed:

Just maybe to "synchronize the clocks" about what the idea is, I'l attempt to illustrate what happens in the graphic file format world. The example is Windows-centric, but hopefully the idea for a common generic format not tied to any tool, which would use transforms, will be illustrated.

- Tool One uses GIF files
- Tool Two uses JPG files
- Tool Three uses BMP files

To avoid having the makers code something specific to import and export pictures in the format of the other tool makers (which number grows with each new tool released from new makers), a common format is established: DIB.

DIB is a very simple format, with no special encoding. It just says which pixel has what color. Each maker has only to code support to and from DIB, with their own encoding. If they have a new version of their format, they just update their import/export routines.

The common XML format is just that (the DIB ). If my XSL-fu was as good as my code-fu, I'd probably draft up something fairly quickly for DMGenie, RPM and Campaign Suite, and the common format is really irrelevant. Whether it's based on CSX or not is not that important. I just found it to be a good starting point.

That's basically the idea. If I'm way off base here, please do not hesitate to slap me

Andargor