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

Re: [pcgen-xml] Expanded pcg proposal

Expand Messages
  • Devon Jones
    ... well, a number of reasons: 1) It ll be a lot easier for people to write code against it, because vast chunks of our file format have a full spec as well as
    Message 1 of 36 , Oct 5, 2005
    • 0 Attachment
      Brass Tilde wrote:

      >the
      >
      >
      >
      >Tell me about it.
      >
      >
      >
      >
      >I have to ask why adherence to the OpenDocument format is so important.
      >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?
      >
      >
      well, a number of reasons:
      1) It'll be a lot easier for people to write code against it, because
      vast chunks of our file format have a full spec as well as sample code
      http://books.evc-cit.info/
      what this means is that for the files that are exactly the same
      (Manifest.xml, settings.xml, mimetype, meta.xml), we have an example
      implementation, and a ton of doco for other people to use.

      2) It means we have to do less work to define specific files

      3) Any tools for OpenDocument files stand a reasonable chance working
      with our files if they are for organization or file management and
      such. We are essentially using the the same container, with a different
      payload. the closer we can get on the container, the more likely it is
      that our files will be usable in other environments. (the only parts of
      the open document spec we are not implementing is content.xml and
      styles.xml - both explicitly related to payload)

      >Fortunately, there are alternatives that *do* recognize the content-type
      >tag, such as Firefox, so I encourage everyone to use that whenever I
      >can. :-)
      >
      >
      Well, and with the rise of opendocument, I don't expect us to be the
      last project that moves to this type of file format. Essentially the
      container portion of opendocument can spread pretty far and wide. The
      capability to store this much metadata in the file is IMHO sweet.

      >And given that every OS that is currently capable of running PCGen also
      >supports so-called "long" file names, I don't think that extension
      >should be limited to three characters, and risk overlapping with
      >something else.
      >
      >
      I deffinitly agree. I was considering xpcg or orpgpcg, I'm deffinitly
      willing to look at other ideas

      >If one recognizes that Windows and *nix were originally targeted towards
      >different audiences, the problems become easier to accept. They are
      >both migrating towards the same thing, though.
      >
      >
      Deffinitly

      Devon
    • 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.