Re: [pcgen-xml] Expanded pcg proposal
> > Why would the PCGen character data, i.e. the current PCG file, orthe
> > previous "section 1", not be "content"?Tell me about it.
> We're definately looking at the issues of packaging format vs. content
> format here. Welcome to a world of tedium. :-)
> It is content. It's not a recognized OpenDocument format, though, soI have to ask why adherence to the OpenDocument format is so important.
> we should be careful that it can't be confused with such. (But I
> really need to spend more time reading those specifications myself.)
I'm not saying it isn't, just asking why it is. What does it gain us
besides being able to say that it's true?
> No, that's META-INF/manifest.xml. mimetype contains the MIME typeMy bad. I don't know where my brain was when I asked this. It's no
> that should be used for the entire package.
different from the mime-type in an HTML or XML files.
> > I'll point out that Windows doesn't care a lick about mime-type,Fortunately, there are alternatives that *do* recognize the content-type
> depending on the extension instead.
> No kidding. MSIE doesn't even like using MIME-type information from
> HTTP responses, where that's exactly what it should be using.
tag, such as Firefox, so I encourage everyone to use that whenever I
> For documents that are created by PCgen, a distinct extension shouldAnd given that every OS that is currently capable of running PCGen also
> be used, so that Windows is kept happy. There should be a specific
> (and registered!) MIME type for that case as well, and that MIME type
> should be stored in the mimetype file within the package file.
supports so-called "long" file names, I don't think that extension
should be limited to three characters, and risk overlapping with
> Yes, I'm somewhat Windows-hostile myself, but I recognize that some ofIf one recognizes that Windows and *nix were originally targeted towards
> us have to get along with it. My hostility stems from the days when
> I'm forced to be in that camp due to customer requirements. :-(
different audiences, the problems become easier to accept. They are
both migrating towards the same thing, though.
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