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

Re: [pcgen-xml] Prototype internal XML schema

Expand Messages
  • Peter Kahle
    I haven t had a chance to look at it in too much depth, but it seems like a format that would work. My only question is, have you worked on creating boni yet?
    Message 1 of 15 , Feb 19, 2002
    • 0 Attachment
      I haven't had a chance to look at it in too much depth, but it seems
      like a format that would work. My only question is, have you worked on
      creating boni yet? I didn't see them (but then, I also didn't download
      your updated DTD.)
      More when I get a chance to look at it more,
      P

      On Tue, Feb 19, 2002 at 11:08:03AM -0800, Keith Davies wrote:
      > mynex3@... wrote on Tue Feb 19 10:38:33 2002:
      > >
      > >
      > > Sorry Keith, I just haven't had a chance to read it yet... I've been
      > > inundated with projects lately. :( (also most of the reason I've kept
      > > mostly quiet on this group)
      >
      > no worries Mynex. I was just wondering if there was anyone here....
      >
      > I checked my web logs after posting my corrections, and there were
      > downloads (including one person who decided to browse a bit), but I
      > hadn't heard anything here.
      >
      > I've got a couple weeks before I DM again, so I've got time to work on
      > this right now. If everyone's cool with what I posted Sunday night,
      > I'll carry on in that vein -- the file schema will have to be able to
      > produce something fitting the framework described in the posting, but
      > needn't look like it.
      >
      >
      > Keith
      > --
      > Keith Davies
      > kjdavies@...
      >
      > Logan: "I don't think it's a good idea."
      > Raven: "The vote is three to one against you -- me, the crystal ball,
      > and the little voices in your head."
      >
      >
      > To unsubscribe from this group, send an email to:
      > pcgen-xml-unsubscribe@yahoogroups.com
      >
      >
      >
      > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
      >
      >

      --

      Those who would give up essential Liberty to purchase a little temporary
      safety, deserve neither Liberty nor safety.
      -- Ben Franklin

      || Peter M Kahle Jr || PGP Public Key on Keyservers ||
      || pkahle@... || http://pops.dyndns.com/~pkahle/ ||
      ##===============================##======================================##
    • Keith Davies
      ... The updated DTD actually just corrected a few syntactical problems. I ve got a habit (when I m in a hurry, or writing stuff on paper) of doing
      Message 2 of 15 , Feb 19, 2002
      • 0 Attachment
        Peter Kahle wrote on Tue Feb 19 11:32:31 2002:
        >
        > I haven't had a chance to look at it in too much depth, but it seems
        > like a format that would work. My only question is, have you worked on
        > creating boni yet? I didn't see them (but then, I also didn't download
        > your updated DTD.)

        The updated DTD actually just corrected a few syntactical problems. I've
        got a habit (when I'm in a hurry, or writing stuff on paper) of doing

        <!ELEMENT something (content*)
        id ID #REQUIRED
        refid IDREF #REQUIRED
        value CDATA #IMPLIED
        >

        when it should be

        <!ELEMENT something (content*)>
        <!ATTLIST something
        id ID #REQUIRED
        refid IDREF #REQUIRED
        value CDATA #IMPLIED
        >

        This gets the information down for me, but I need to go back and correct
        the syntax. The viewer I was using to confirm syntax was nonvalidating
        (to my surprise), so I didn't realize the DTD was broken until I popped
        it in another viewer and it crapped out.

        And, as in my posting message, this is just to demonstrate the framework
        I expect to be used inside the program. The data elements (<weapon>,
        <spell>, etc) will be quite similar, but these are far from complete.
        The schema used in the files will actually be considerably different,
        in that they will describe the relationships between things and how to
        construct data that fits the sample schema.

        And no, I haven't done boni yet, outside of marking some places for
        them (the <effects> element). I'll look into that soon, though.


        Keith
        --
        Keith Davies
        kjdavies@...

        Logan: "I don't think it's a good idea."
        Raven: "The vote is three to one against you -- me, the crystal ball,
        and the little voices in your head."
      • mynex3@comcast.net
        Okay, finally looked it over (And save it to a file in case I need to reference a specific point)... Looks good, I don t see anything that jumps out and say
        Message 3 of 15 , Feb 19, 2002
        • 0 Attachment
          Okay, finally looked it over (And save it to a file in case I need to
          reference a specific point)...

          Looks good, I don't see anything that jumps out and say 'NO!!!!!!' ;p

          I did note that there were a lot of missing references to tags.. this is
          probably due to the fact that there is no current list of every tag in
          every file... That's being worked on, and hopefully soon, I can supply
          that....

          The other thing that may be an issue, there are going to be several key
          changes coming in the next few months regarding some 'basic' code
          assumptions (How skills are handled, how PC attributes are handled (Str,
          Int, etc))... Not a huge problem, but means re-working the DTD for
          proper validation... Are you planning on being the DTD 'Silverback'?
          Whether you are or aren't _PLEASE_ make sure that it is so completely
          documented on what does what/how to change it (without giving DTD-XML
          courses. ;p) that someone could take it over at a moments notice.

          I expect though, that it will be mostly the formats/Tags of the list
          files that will be in a near constant frenzy of change, so I'm not to
          worried about the DTD (as long as it handles whatever junk people chuck
          into the list files).

          Mynex

          - #1 Evil assistant to the PCGen Code Monkeys (Code Badgerer)
          - PCGen Document & List File Silverback
          - RPG Gateway - Software Section Editor
          - RPG Reviews - d20 section Editor/Reviewer


          > -----Original Message-----
          > From: Keith Davies [mailto:kjdavies@...]
          > Sent: Monday, February 18, 2002 2:16 PM
          > To: pcgen-xml@yahoogroups.com
          > Subject: Re: [pcgen-xml] Prototype internal XML schema
          >
          > Keith Davies wrote on Sun Feb 17 23:23:58 2002:
          > >
          > > I've attached a zip file containing a DTD and sample document that
          > > fits the DTD
          >
          > Heh, this is mildly embarassing... I should've validated the DTD
          > before posting <g> There are a couple of syntax errors in it; I've
          > put a corrected version at
          >
          > http://s142-179-103-186.bc.hsia.telus.net/kjdavies/pcgen/pcgen-int.dtd
          >
          >
          > Keith
          > --
          > Keith Davies
          > kjdavies@...
          >
          > Logan: "I don't think it's a good idea."
          > Raven: "The vote is three to one against you -- me, the crystal ball,
          > and the little voices in your head."
          >
          > ------------------------ Yahoo! Groups Sponsor
          >
          > To unsubscribe from this group, send an email to:
          > pcgen-xml-unsubscribe@yahoogroups.com
          >
          >
          >
          > Your use of Yahoo! Groups is subject to
          http://docs.yahoo.com/info/terms/
        • Keith Davies
          ... There are lots and lots and lots of things missing from this file. I was just showing framework -- will be *where* it is, but the internals are
          Message 4 of 15 , Feb 19, 2002
          • 0 Attachment
            mynex3@... wrote on Tue Feb 19 13:10:38 2002:
            >
            >
            > Okay, finally looked it over (And save it to a file in case I need to
            > reference a specific point)...
            >
            > Looks good, I don't see anything that jumps out and say 'NO!!!!!!' ;p
            >
            > I did note that there were a lot of missing references to tags.. this is
            > probably due to the fact that there is no current list of every tag in
            > every file... That's being worked on, and hopefully soon, I can supply
            > that....

            There are lots and lots and lots of things missing from this file. I
            was just showing framework -- <weapon> will be *where* it is, but the
            internals are not yet fully defined. Actually, the only reason those
            elements have as much as they do is because I already had them typed
            up for something else.

            > The other thing that may be an issue, there are going to be several key
            > changes coming in the next few months regarding some 'basic' code
            > assumptions (How skills are handled, how PC attributes are handled (Str,
            > Int, etc))... Not a huge problem, but means re-working the DTD for
            > proper validation... Are you planning on being the DTD 'Silverback'?

            Oook.

            I'm planning to make as much as is feasible configurable via the files.
            You'll notice the <stat> elements there... they'll be referred to in
            the <campaign> element to say which ones are in use, and I may even
            include information on generating them (such as allowing specification
            of a dice roll), although that's sort of dubious because, personally,
            I haven't used the the randomly-generated values *yet*.

            > Whether you are or aren't _PLEASE_ make sure that it is so completely
            > documented on what does what/how to change it (without giving DTD-XML
            > courses. ;p) that someone could take it over at a moments notice.

            I'll be providing documentation (or roping someone else into to
            writing it, I hope); right now I think there's enough knowledge in
            the audience to follow what I've done. The other stuff I was coming
            up with earlier -- the actual data file schema -- isn't as simple as
            this... but it is to describe how to construct a file that looks like
            this. That's a little more complex anyway.

            I spent a little over an hour preparing the DTD (initially; another
            hour or so while preparing sample.xml correcting minor problems), but
            preparing the XML file took about four hours, so there'd be a decent
            example of how it works.

            Most people I know... skip that, I don't know *anybody* around here
            who can read DTDs. It's much easier for people to read example XML
            than it is for them to read DTDs, which is why I spent the time on
            it. It's probably much larger than it needs to be, because I included
            many examples where I only needed a few (the spell lists in particular).

            When I'm done, I expect to have:

            Internal DTD
            External (file) DTD
            Example of internal data
            Example of external (file) data
            Example transformation script for turning external into internal.
            Documentation explaining what things mean and are.

            Also -- as the use of entities in the DTD may have shown -- I'll try
            to use common sets of attributes whenever possible, to minimize symbol
            set size and ambiguity (do I use *this* or *that*?).

            The reference elements (<weapon>, <spell>, etc) will probably not
            change between DTDs -- there's no need for them too. The assignment
            and classification elements will collapse, from

            <list .../>
            <list-entries>
            <ref> ...
            </list-entries

            to

            <list>
            <ref> ...
            </list>

            , but I'm going to keep the separation between them in the data files
            because it makes it less painful to add new things to the lists, and
            the things to new lists.

            > I expect though, that it will be mostly the formats/Tags of the list
            > files that will be in a near constant frenzy of change, so I'm not to
            > worried about the DTD (as long as it handles whatever junk people chuck
            > into the list files).

            That's why I'm working on framework right now and making it as flexible
            and adaptable as possible. Minor details can vary (representation of
            objects such as weapons, spells, etc), ideally without damaging the
            framework. While we can transform things if needed, I'd prefer to
            avoid the necessity.


            Keith
            --
            Keith Davies
            kjdavies@...

            Logan: "I don't think it's a good idea."
            Raven: "The vote is three to one against you -- me, the crystal ball,
            and the little voices in your head."
          • giliath01
            ... Perhaps I am confused, but are you intending on storing the data inside of the objects in XML??? In traditional programming you want to abstract your data
            Message 5 of 15 , Feb 19, 2002
            • 0 Attachment
              > When I'm done, I expect to have:
              >
              > Internal DTD
              > External (file) DTD
              > Example of internal data
              > Example of external (file) data
              > Example transformation script for turning external into internal.
              > Documentation explaining what things mean and are.

              Perhaps I am confused, but are you intending on storing the data
              inside of the objects in XML??? In traditional programming you want
              to abstract your data layer from your logic layer so that you could
              add another data layer at any point. Part of the difficulty I see in
              moving to XML this time is going to be that every object loads itself
              from the .lst files. XML is a good data representation layer when
              you want to be able to do human editing, but it is not great when
              space (like memory) is an issue.

              It would seem that since there is going to be a fairly significant
              rewrite to use XML that moving to a set of persistence classes that
              turn the XML into objects would be a good approach. That way it
              would be easier to later put this into postgres or some database when
              PcGen becomes a webapp.

              ~Giliath
            • Keith Davies
              ... The data inside the elements would of necessity be XML. When loaded into memory, it depends on the program. I ve been told that, using JDOM, the XML tree
              Message 6 of 15 , Feb 19, 2002
              • 0 Attachment
                giliath01 wrote on Tue Feb 19 15:13:31 2002:
                >
                > > When I'm done, I expect to have:
                > >
                > > Internal DTD
                > > External (file) DTD
                > > Example of internal data
                > > Example of external (file) data
                > > Example transformation script for turning external into internal.
                > > Documentation explaining what things mean and are.
                >
                > Perhaps I am confused, but are you intending on storing the data
                > inside of the objects in XML??? In traditional programming you want
                > to abstract your data layer from your logic layer so that you could
                > add another data layer at any point. Part of the difficulty I see in
                > moving to XML this time is going to be that every object loads itself
                > from the .lst files. XML is a good data representation layer when
                > you want to be able to do human editing, but it is not great when
                > space (like memory) is an issue.

                The data inside the elements would of necessity be XML. When loaded
                into memory, it depends on the program. I've been told that, using
                JDOM, the XML tree can be kept and manipulated. This is good. It
                is not *necessary* to do it this way -- the data loaded from the XML
                file may indeed be translated to objects of specific classes in the
                program -- a <weapon> may be represented in memory as an instantiation
                of Weapon. That's entirely cool, and it is actually outside the scope
                of the XML design and translation project to design the (program's)
                internal structure of the data -- the requirements document said that
                we would not be telling the front-end folks how to hold the data in
                memory.

                The schema I presented on Sunday can be used to hold data for use
                inside the program. It is easily navigable, reasonably simple to
                search, even without indexes (I do so using a simple tree presentation
                of the data -- I expand <pcgen-int>, <reference>, <weapons>, then scan
                them for <weapon name="Longsword"/>). It keeps related information
                close together, but in small enough chunks (I think) that it can be
                managed, without the use of arbitrary divisions (such as by first
                letter of the name).

                We need a target of some sort, that *could* be used internally. It
                may be as I presented Sunday. It may be built in code. It could be
                something entirely different. I don't know. However, if we have a
                sample target schema that *could* work -- presents the data in a
                navigable, searchange, *usable* form -- then we've got something to
                aim at. If we aim at the (admittedly very incomplete) schema I've
                presented, then we just need to show that the file schema can create
                a file fitting that schema... or a code-based representation of the
                schema.

                > It would seem that since there is going to be a fairly significant
                > rewrite to use XML that moving to a set of persistence classes that
                > turn the XML into objects would be a good approach. That way it
                > would be easier to later put this into postgres or some database when
                > PcGen becomes a webapp.

                Heh. Leaving aside the question of feasibility in making PCGen a
                webapp, the sample file I presented does not preclude alteration of
                the system to put it into a database. However, it has been decided
                (several times) that going to a database is not something we want to
                do, at least for now. That being the case, I don't want to spend my
                time preparing for something that may or may not be done in the;
                I'd much rather aim for something manageable now. I'll try to avoid
                decisions that lock us into anything, but that shouldn't be *too*
                hard -- my design is going to be as normalized as is feasible, and
                XML is fairly easy to move into a database. The big pain is going
                to be converting everything over to XML.


                Keith
                --
                Keith Davies
                kjdavies@...

                Logan: "I don't think it's a good idea."
                Raven: "The vote is three to one against you -- me, the crystal ball,
                and the little voices in your head."
              • giliath01
                Great work so far on the prototype dtd btw... I just had one question so far:
                Message 7 of 15 , Feb 20, 2002
                • 0 Attachment
                  Great work so far on the prototype dtd btw... I just had one
                  question so far:

                  <race id="race.phb.dwarf" name="Dwarf">
                  <race-stats favored-class="class.phb.fighter">
                  <stat-mod stat-id="stat.phb.con" value="+2"/>
                  <stat-mod stat-id="stat.phb.cha" value="-2"/>
                  </race-stats>
                  </race>

                  I noticed in the humn the favored-class is choose(class-list.all).
                  Would you therefore need to create a list of classes anytime a race
                  had more than 1 favored-class?


                  ~Giliath
                • Keith Davies
                  ... At this point, I think so. There may be another mechanism (listing the IDs of the classes, in an IDREFS style?), but at 11pm on a Sunday I m not going to
                  Message 8 of 15 , Feb 20, 2002
                  • 0 Attachment
                    giliath01 wrote on Wed Feb 20 08:08:32 2002:
                    >
                    > Great work so far on the prototype dtd btw... I just had one
                    > question so far:
                    >
                    > <race id="race.phb.dwarf" name="Dwarf">
                    > <race-stats favored-class="class.phb.fighter">
                    > <stat-mod stat-id="stat.phb.con" value="+2"/>
                    > <stat-mod stat-id="stat.phb.cha" value="-2"/>
                    > </race-stats>
                    > </race>
                    >
                    > I noticed in the human the favored-class is choose(class-list.all).
                    > Would you therefore need to create a list of classes anytime a race
                    > had more than 1 favored-class?

                    At this point, I think so. There may be another mechanism (listing
                    the IDs of the classes, in an IDREFS style?), but at 11pm on a Sunday
                    I'm not going to look too hard <g>

                    I can see how defining a new list for each class that can have multiple
                    favored classes could be annoying, but by having a list for this, we
                    can make it more easily customizable. OTOH, since this is not the main
                    data file, only the structure I envision being used inside PCGen, the
                    benefits to this may not be entirely evident.

                    Remember, a structure I showed for data files had

                    <class-list id="class-list.all" name="All Classes" />

                    In data/wotc/core/phb/class-list.xml:

                    <list-entries list-id="class-list.all">
                    <ref refid="class.phb.cleric"/>
                    <ref refid="class.phb.fighter"/>
                    <ref refid="class.phb.rogue"/>
                    <ref refid="class.phb.wizard"/>
                    <!-- ... more ... -->
                    </list-entries>

                    In data/wotc/core/dmg/class-list.xml:

                    <list-entries list-id="class-list.all">
                    <ref refid="class.dmg.adept"/>
                    <ref refid="class.dmg.aristocrat"/>
                    <ref refid="class.dmg.commoner"/>
                    <ref refid="class.dmg.expert"/>
                    <ref refid="class.dmg.warrior"/>

                    <ref refid="class.dmg.arcane-archer"/>
                    <ref refid="class.dmg.blackguard"/>
                    <!-- ... more ... -->
                    </list-entries>

                    in data/wotc/fr/frcs/class-list.xml:

                    <list-entries list-id="class-list.all">
                    <ref refid="class.frcs.archmage"/>
                    <ref refid="class.frcs.thay-wizard"/>
                    <!-- ... more ... -->
                    </list-entries>


                    As you can see, this way we can have multiple sources feeding objects
                    into a single list, without requiring modification to the actual list
                    element, nor filling it with references to objects that may never be
                    loaded. The references to the FR classes are included if and only if
                    the FR class-list file is loaded. This minimizes the impact of new
                    files, or adding new lists.

                    The actual campaign 'definition' file (the file that is used to
                    create the sample.xml file I presented) might look like:

                    <pcgen>
                    <campaign id="campaign.core" name="Core Rules">
                    <use refid="armor-list.light"/>
                    <use refid="armor-list.medium"/>
                    <use refid="armor-list.heavy"/>
                    <use refid="armor-list.shield"/>
                    <use refid="weapon-list.simple"/>
                    <use refid="weapon-list.martial"/>
                    <use refid="weapon-list.exotic"/>
                    <!-- ... more ... -->
                    </campaign>

                    <includes>
                    <include href="data/wotc/core/phb/armor.xml"/>
                    <include href="data/wotc/core/phb/class.xml"/>
                    <include href="data/wotc/core/phb/equipment.xml"/>
                    <include href="data/wotc/core/phb/feat.xml"/>
                    <include href="data/wotc/core/phb/skill.xml"/>
                    <include href="data/wotc/core/phb/spell.xml"/>
                    <include href="data/wotc/core/phb/weapon.xml"/>
                    </includes>
                    </pcgen>

                    This can be fairly easily transformed into a file similar to the
                    one I presented on Sunday. I wrote an XSLT script that did it,
                    in about 5 minutes (as a first pass; I didn't actually dereference
                    the lists).

                    This is a mechanism I expect to use for many things (notably
                    <feat-lists>, <spell-list>s and <weapon-list>s) to allow easier
                    customization of campaigns. By keeping the assignment to lists
                    separate from both the lists and the objects being assigned, we
                    get maximum flexibility in assignment.

                    For example, I want to revise spells used by clerics, particularly,
                    define spell chains similar to the progressions used by psionicists
                    (for sorcerers -- a feat will allow a single slot to be used for a
                    spell chain), and I don't care for the current weapon groupings so I
                    want to be able to create new ones and use them instead.

                    Anyway, I expect to use a mechanism like this for many other things.
                    Rather than devise and introduce another mechanism that may be a
                    little easier, I'd rather be consistent with other places that use
                    collections of things and create a <class-list>. OTOH, I'm not
                    fanatic about it -- if we can come up with a better mechanism,
                    preferably one that can be used in many places, I'd certainly think
                    about it.


                    Keith
                    --
                    Keith Davies
                    kjdavies@...

                    Logan: "I don't think it's a good idea."
                    Raven: "The vote is three to one against you -- me, the crystal ball,
                    and the little voices in your head."
                  • mythicrpg
                    ... representation ... Ok, I ve looked over and actually started using the sample.xml file. (by using, I mean doing test runs parsing the data, displaying a
                    Message 9 of 15 , Feb 22, 2002
                    • 0 Attachment
                      --- In pcgen-xml@y..., Keith Davies <kjdavies@t...> wrote:
                      > Hi All,
                      >
                      > I've attached a zip file containing a DTD and sample document that
                      > fits the DTD, that describe how I envision the internal
                      representation
                      > of XML data in PCGen. This DTD does *not* describe how I expect the
                      > actual data files to be encoded; the data files themselves will
                      > contain the data to be transformed into this structure and the rules
                      > for doing that transformation (for instance, adding references to
                      > items to the various lists shown here).

                      Ok, I've looked over and actually started using the sample.xml file.
                      (by using, I mean doing test runs parsing the data, displaying a GUI,
                      etc.)
                      I like (love) the direction you're going.
                      As to the DTD (I'm not using a validating parser), I'm with most
                      people in the "I don't/can't read/care about DTDs"... so I have no
                      comment there.

                      Just random comments:
                      - Add abbrevs to classes as a required attribute.
                      - How are you going to handle saves in relation to classes?
                      - "melee='no'"? I'm not sure if that's the best way, maybe it's
                      simply not intuitive for me, but I don't have a better suggestion.

                      As you say, it's not complete, but I thought I'd comment on the
                      structure a bit.
                      I'm looking forward to the rest of the structures more complete
                      (spells, etc)....

                      (btw, I'm using this time to build a 'PCGEN compat' front-end in a
                      different language than Java, so I'm *very* interested in the format
                      being as robust as possible.)

                      You've said this is the 'internal' format and you don't expect the
                      source files to look like this. What I'm interested in is, do mean
                      that the source files will remain in the .lst format? Or is there
                      some intermediary format you're going to use. What I mean is, what
                      you have now seems to be headed in a very open format usable by many
                      different front-ends. Why would this not also be the file format for
                      the data?
                    • Keith Davies
                      ... Cool, thanks. Note (I ve said this a bunch of times, but I can t be too clear on this) that this is not the schema that ll be used for the actual data
                      Message 10 of 15 , Feb 22, 2002
                      • 0 Attachment
                        mythicrpg wrote on Fri Feb 22 08:06:53 2002:
                        >
                        > --- In pcgen-xml@y..., Keith Davies <kjdavies@t...> wrote:
                        > > Hi All,
                        > >
                        > > I've attached a zip file containing a DTD and sample document that
                        > > fits the DTD, that describe how I envision the internal
                        > representation
                        > > of XML data in PCGen. This DTD does *not* describe how I expect the
                        > > actual data files to be encoded; the data files themselves will
                        > > contain the data to be transformed into this structure and the rules
                        > > for doing that transformation (for instance, adding references to
                        > > items to the various lists shown here).
                        >
                        > Ok, I've looked over and actually started using the sample.xml file.
                        > (by using, I mean doing test runs parsing the data, displaying a GUI,
                        > etc.)
                        > I like (love) the direction you're going.

                        Cool, thanks. Note (I've said this a bunch of times, but I can't be
                        too clear on this) that this is not the schema that'll be used for the
                        actual data (currently LST) files, for very good reasons. However, it
                        should be fairly easy to produce a file that looks like this, from the
                        data files that will be produced.

                        > As to the DTD (I'm not using a validating parser), I'm with most
                        > people in the "I don't/can't read/care about DTDs"... so I have no
                        > comment there.

                        I do use a DTD because it makes a lot of the transformations easier to
                        write, and it provides some documentation.

                        > Just random comments:
                        > - Add abbrevs to classes as a required attribute.

                        The schema's not complete; @abbrev was supposed to be there, but I
                        forgot... and it didn't matter for what I was doing. Thanks for
                        noticing, though.

                        > - How are you going to handle saves in relation to classes?

                        There's a couple of possibilities:

                        <progression id="prog.save.good" name="Good Save Progression">
                        <formula value="2+$class_level/2" />
                        </progression>

                        <progression id="prog.save.medium" name="Medium Save Progression">
                        <formula value="1+$class_level*2/5" />
                        </progression>

                        <progression id="prog.save.bad" name="Bad Save Progression">
                        <formula value="$class_level/4" />
                        </progression>

                        <class ...>
                        <class-stats>
                        <class-save save-id="save.fort" progression="prog.save.good"/>
                        <class-save save-id="save.ref" progression="prog.save.medium"/>
                        <class-save save-id="save.will" progression="prog.save.bad"/>
                        </class-stats>
                        </class>

                        Another possibility (that I don't like quite as much, but is more
                        flexible):

                        <class ...>
                        <class-levels>
                        <class-level level="1">
                        <adjust var-id="save.fort" mod="+2" />
                        <adjust var-id="save.ref" mod="+1" />
                        </class-level>
                        <class-level level="2">
                        <adjust var-id="var.bab" mod="+1" />
                        <adjust var-id="save.fort" mod="+1" />
                        </class-level>
                        <class-level level="3">
                        <adjust var-id="var.bab" mod="+1" />
                        <adjust var-id="save.ref" mod="+1" />
                        <adjust var-id="save.will" mod="+1" />
                        </class-level>
                        </class-levels>
                        </class>

                        This amounts to

                        Level Fort Ref Will BAB
                        1 +2 +1 +0 +0
                        2 +3 +1 +0 +1
                        3 +3 +2 +1 +2


                        > - "melee='no'"? I'm not sure if that's the best way, maybe it's
                        > simply not intuitive for me, but I don't have a better suggestion.

                        Actually, looking at it, breaking missile weapons out makes some
                        sense; they don't actually do damage themselves (you noticed there's
                        an element that describes the association between missile weapons
                        and their ammunition, rather than assigning damage and ranges to
                        the weapons themselves?). I don't want to have <melee-weapon> and
                        <missile-weapon>, though. Element names are the problem, though;
                        breaking them apart makes sense to me.

                        The reason I have @melee='no' is because most weapons *are* melee,
                        so it makes sense to have that as the default.

                        > As you say, it's not complete, but I thought I'd comment on the
                        > structure a bit.

                        Thanks -- that's why I posted the structure. I'll be working on it
                        more this weekend.

                        > I'm looking forward to the rest of the structures more complete
                        > (spells, etc)....
                        >
                        > (btw, I'm using this time to build a 'PCGEN compat' front-end in a
                        > different language than Java, so I'm *very* interested in the format
                        > being as robust as possible.)
                        >
                        > You've said this is the 'internal' format and you don't expect the
                        > source files to look like this. What I'm interested in is, do mean
                        > that the source files will remain in the .lst format? Or is there
                        > some intermediary format you're going to use. What I mean is, what
                        > you have now seems to be headed in a very open format usable by many
                        > different front-ends. Why would this not also be the file format for
                        > the data?

                        Nope, I want to move entirely to XML.

                        The reason I won't use the format presented above is that it will be
                        very hard to edit, customize, and maintain, even if I break it into
                        smaller pieces. One of the goals is to customize the data as much as
                        possible, and cause additions to the system to have minimal impact.

                        As a result, the data files will describe the objects (<weapon> et al)
                        and the relationships between them. Rather than having the
                        <weapon-list> containing the references to all the weapons in the list
                        as in sample.xml, <weapon-list> will be created, empty, then another
                        element will specify what references get added to the <weapon-list>.
                        There can be more than one of these assignment elements for each list,
                        though.

                        Semantically, these read differently. The first example (in sample.xml)
                        says "This is a weapon list, and it contains these weapons". The case
                        I described above says "Here is a weapon list", followed by a number of
                        "Here are some weapons, and the lists they belong in". I don't put the
                        list assignments in the <weapon>s because adding a new list will mean
                        going through and changing all of the <weapon>s to be assigned to that
                        list.

                        That would suck.

                        Instead, I create a new <weapon-list>, then create a <list-entries> that
                        identifies the weapons to put in the list. These can go in a single
                        file where they are easily maintained, and if I want to add weapons from
                        another data set (perhaps a campaign supplement from another publisher),
                        I can simply drop a <list-entries> element in that directory.

                        data/wotc/core/phb/weapon-list.xml:

                        <weapon-list id="weapon-list.martial" name="Martial Weapons" />
                        <list-entries list-id="weapon-list.martial">
                        <ref refid="weapon.longsword"/>
                        <ref refid="weapon.greatsword"/>
                        <!-- etc -->
                        </list-entries>

                        data/wotc/fr/frcs.xml:

                        <list-entries list-id="weapon-list.martial">
                        <ref refid="weapon.slaphammer"/>
                        </list-entries>
                        <weapon id="weapon.slaphammer" name="Slaphammer"/>

                        Semantically, this says "Here is a weapon list, to contain martial
                        weapons (indicated by name; I think I'll add a small description
                        element so people can see what various lists mean). Here are the
                        weapons from the PHB that belong to the list. If you load the FRCS,
                        these weapons are also part of this list."

                        As I said, this means that adding a new list means adding (a minimum)
                        of two elements; it is not necessary to add more -- you don't have to
                        run through adding a .MARTIAL to each and every weapon you want in the
                        list, and you don't have a bunch of people fighting over the same file
                        (the weapon-list.xml file in the example above) so they can add the
                        martial weapons in the books they're working on, they just have to add
                        their own <list-entries> elements to make the association.


                        I expect a mechanism like this to be used a lot. It is reasonably easy
                        to create a transformation that'll run through and create a file like
                        sample.xml that snaps all the references and collapses the structures
                        to a form more convenient to use, or even to load the data in the more
                        complex form and create a structure similar to that in sample.xml.


                        Keith
                        --
                        Keith Davies
                        kjdavies@...

                        Logan: "I don't think it's a good idea."
                        Raven: "The vote is three to one against you -- me, the crystal ball,
                        and the little voices in your head."
                      Your message has been successfully submitted and would be delivered to recipients shortly.