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

Prototype internal XML schema

Expand Messages
  • Keith Davies
    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
    Message 1 of 15 , Feb 17, 2002
    • 0 Attachment
      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).

      The elements inside the <reference> elements (<armor>, <weapon>, etc)
      are as I expect them to be later (attribute-based, and so on), but the
      data is way far from complete... not only have I not completed the
      design of these things, but I didn't want to spend too much time on it
      and have to throw it away... and I already had a bunch of this from
      another project.

      As I said, this is the internal representation of the data (although
      the implementation of this is not defined -- if I were doing this in
      C++, I might be inclined to replace the <ref> elements with hard links
      to the actual elements, rather than having to look up the referenced
      element each time) during run time. The data files would *not* look
      like this, although I think that an exported campaign file or
      character file might.

      The exported files would contain enough information to fully describe
      a character or campaign... all rules used, all objects referenced, and
      so on, though I would want it to contain only the minimum subset
      needed to describe the major elements (campaign or character). It
      would be possible to create an XSLT script to produce a character
      sheet or campaign reference document, depending on the type of export.

      An export file like this is an *output* format (though of course it
      can be loaded and used); it does not describe how the data comes to be
      in these formats. There will be a transformation step between the
      mostly normalized, easily-modified lists and references and this
      document; this is (close-to) a fully-denormalized document. It is not
      meant to be edited by the user... while I created this one by hand,
      that's only because it was faster than working out the transformations
      I'd need right now. The redundancy in this document to make it simple
      also makes it unreasonable to maintain manually.

      I think this framework (incomplete...) will do the job. If this is
      so, we can have something like this as the target of the
      transformations that'll be used when the data's loaded.

      Thoughts, comments? To minimize bandwidth use (and make it easier to
      read while I'm at work, away from simple access of attachments),
      please just quote the DTD or sample XML file where you've got a
      comment or suggestion.

      (and yes, I know there's a lot of redundancy and repetition in this
      message... these points are important, and I'm way tired right now...)


      Thanks,
      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."
    • Keith Davies
      ... Heh, this is mildly embarassing... I should ve validated the DTD before posting There are a couple of syntax errors in it; I ve put a corrected
      Message 2 of 15 , Feb 18, 2002
      • 0 Attachment
        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."
      • Keith Davies
        ... Hello? No comments or questions? Shall I continue in this vein, then? Keith -- Keith Davies kjdavies@telus.net Logan: I don t think it s a good idea.
        Message 3 of 15 , Feb 19, 2002
        • 0 Attachment
          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."
        • 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 4 of 15 , Feb 19, 2002
          • 0 Attachment
            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 5 of 15 , Feb 19, 2002
            • 0 Attachment
              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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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 15 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.