Loading ...
Sorry, an error occurred while loading the content.

Re: [pcgen-xml] Expanded pcg proposal

Expand Messages
  • Fred Drake
    ... 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
    Message 1 of 36 , Oct 4, 2005
    • 0 Attachment
      On 10/4/05, Brass Tilde <brasstilde@...> wrote:
      > Why would the PCGen character data, i.e. the current PCG file, or the
      > previous "section 1", not be "content"?

      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, so
      we should be careful that it can't be confused with such. (But I
      really need to spend more time reading those specifications myself.)

      > mimetype does what exactly? Contain the name of each file in the
      > package along with it's mime-type, so that PCGen, or some other program,
      > can open the appropriate program?

      No, that's META-INF/manifest.xml. mimetype contains the MIME type
      that should be used for the entire package.

      > I'll point out that Windows doesn't
      > care a lick about mime-type, depending on the extension instead. I
      > understand that other OSes do respect mime-type, but Windows is a large
      > fraction of PCGen users.

      No kidding. MSIE doesn't even like using MIME-type information from
      HTTP responses, where that's exactly what it should be using.

      For documents that are created by PCgen, a distinct extension should
      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.

      > Help me understand what's going on, and I will. :-)

      I think we're a long way from really having a usable cross-platform
      composite document format, but that has nothing to do with PCgen in
      particular. Current best-practices are to apply OpenDocument as much
      as possible, but to continue with extension proliferation (a decidedly
      non-scalable approach) to keep Windows happy until someone can fix
      that platform's native insanity.

      Yes, I'm somewhat Windows-hostile myself, but I recognize that some of
      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. :-(


      -Fred

      --
      Fred L. Drake, Jr. <fdrake at gmail.com>
      "Society attacks early, when the individual is helpless." --B.F. Skinner
    • Paul W. King
      LOL 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
      Message 36 of 36 , Oct 12, 2005
      • 0 Attachment
        LOL

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

        Paul W. King
        OGL/PL/TM Chimp, Data Gibbon

        -----Original Message-----
        From: pcgen-xml@yahoogroups.com [mailto:pcgen-xml@yahoogroups.com]On Behalf Of Edwin Holley
        Sent: Wednesday, October 12, 2005 7:05 PM
        To: pcgen-xml@yahoogroups.com
        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
      Your message has been successfully submitted and would be delivered to recipients shortly.