Reply to thread

Message: <blockquote data-quote="Hollywood" data-source="post: 1230614" data-attributes="member: 7408">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.</blockquote>

Verification