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

RE: [pcgen-xml] Prototype internal XML schema

Expand Messages
  • mynex3@comcast.net
    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
    Message 1 of 15 , Feb 19, 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)

      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: Tuesday, February 19, 2002 1:28 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:
      > >
      > > 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).
      >
      > Hello? No comments or questions? Shall I continue in this vein,
      then?
      >
      >
      > 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
      ... 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
      Message 2 of 15 , Feb 19, 2002
        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."
      • 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 3 of 15 , Feb 19, 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.)
          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 4 of 15 , Feb 19, 2002
            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 5 of 15 , Feb 19, 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....

              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 6 of 15 , Feb 19, 2002
                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 7 of 15 , Feb 19, 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.

                  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 8 of 15 , Feb 19, 2002
                    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 9 of 15 , Feb 20, 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 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 10 of 15 , Feb 20, 2002
                        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 11 of 15 , Feb 22, 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.
                          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 12 of 15 , Feb 22, 2002
                            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.