Re: [pcgen-xml] Expanded pcg proposal
- On 10/3/05, Devon Jones <soulcatcher@...> wrote:
> Ok, I have put some more thought into this, and I have an expanded+1 -- This is very easy to work with in different languages these days.
> proposal. I want to do what Java, and the OpenDocument people have
> done. I want a pcg format that is actually a number of files, in a
> specific directory structure, stored in a zip file.
> OpenDocument stores the following files:It looks like PCgen wouldn't be using any of these; is that right?
> * XML files
> o content.xml
> o meta.xml
> o settings.xml
> o styles.xml
> * Other filesHmm. What this should be for composite documents like you've
> o mimetype
described, I just don't know. It sounds like I could have a document
that's both an OpenOffice Writer document and a PCgen character.
Probably a minor nit for those stuck in the Windows world.
> /Yes; this must stay aligned with the OpenDocument stuff.
> - settings.xml - currently, we export certain settings in the base.xml,
> such as paper size. this has *nothing* to do with the character data.
> Settings.xml would be the right place for that
> - meta.xml - Would be useful for storing meta information, such asThis is still good, so long as there's no deviation from the
> creation time, username of the person who created the file, language
> settings, etc
> - mimetime - for storing the mime type, so that extension, while useful,See my note above about highly-composite documents based on this sort
> becomes immaterial. This means that this base format and directory
> structure could be used for more then one file type.
of JAR paradigm.
> - export.xml- what we were referring to as "Section 3" Technically, anyHmm. We definately have different ideas here. I do think that yours
> program that can do characters should be able to build this file.
> - log.xml - a place where the program can store any type of log
> information it wants. Should be non-destructive, each program that
> writes this file out should only append. This is what we were calling
> seciton 2.
take precedence, since I'm unlikely to actually scratch together
enough time to create something that takes advantage of all that I've
described for this.
I think both of these should be located in the PCgen-specific
directory you describe, and not at the top-level directory in the
> Attachments/ZIP with ZIP files included? Could be, but less efficient to work
> for storing any other related files. Can include other files of the
> exact same type for storing things like followers/mounts/etc
with. Could be just an additional tree that represents each separate
being. Not sure which would be best, and not sure Attachments/ is
best or making it a separate top-level directory.
Fred L. Drake, Jr. <fdrake at gmail.com>
"Society attacks early, when the individual is helpless." --B.F. Skinner
Just getting the built-in editors to work well has been an effort for a number of years now. I think that, if the code team were
to focus solely on the editors, they'd work on getting just the flat-file stuff working first before going towards the zipped
Paul W. King
OGL/PL/TM Chimp, Data Gibbon
From: email@example.com [mailto:firstname.lastname@example.org]On Behalf Of Edwin Holley
Sent: Wednesday, October 12, 2005 7:05 PM
Subject: RE: [pcgen-xml] Re: Expanded pcg proposal
Ok ... what about an editor for the data sets, which could support the zipped or unzipped data sets automatically.
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.11.14/130 - Release Date: 10/12/2005