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

PCGen XML design philosophy

Expand Messages
  • Keith Davies
    Hi All, I ve been examining the data to be encoded and have an interesting question. The simple, straightforward way of tackling this project would be to
    Message 1 of 18 , Jan 10, 2002
    • 0 Attachment
      Hi All,

      I've been examining the data to be encoded and have an interesting
      question.

      The simple, straightforward way of tackling this project would be to
      simply define a schema around what is currently used in the LST files.
      We could be done by the end of the month (<pffft, right>). The other
      is to -- to some extent, at least -- ignore what the LST files hold
      currently and examine the *data* available, the stuff from the books,
      and derive a more object-centric model.

      There are benefits to both. The first, as I mentioned, could probably
      be relatively quickly. A simple translation from 'tabs and tags' to
      XML should be pretty straightforward. It would probably have less
      impact on PCGen because the data relationships would be the same.

      The second requires a lot more thought and design effort. This will
      give us the opportunity to normalize the data (thereby reducing
      redundancy in the data) and -- I think -- give us the ability to make
      the data design a little more general and more easily extensible.
      This will take a great deal longer than the first option, and can have
      a large impact on PCGen because many of the data relationships will
      have changed, in some cases a great deal.

      I've got a preference here, but I'd like to hear from you before stating
      them -- I'd like to try to keep my bias out of it for now.


      Keith
      --
      Keith Davies
      kjdavies@...

      Elarios: "Shade, you showed honor and mercy
      "Raven, you were couragous beyond expectation
      "Logan, you resisted the temptation of knowledge."

      Logan: "That's... good, right?"
    • Mynex
      Okay, to make it easier for everyone, give a quick (in English for new XML folk and the layman just reading to see what s up) overall explanation by what you
      Message 2 of 18 , Jan 10, 2002
      • 0 Attachment
        Okay, to make it easier for everyone, give a quick (in English for new
        XML folk and the layman just reading to see what's up) overall
        explanation by what you mean for both options (as in the steps you'd
        take to do them and why).

        I also have a preference, but, like you, I would prefer to hold it back
        for the moment.

        Mynex

        - Dark Sith Silverback Android, Dark Lord of the Docs, The Sleepless One


        -----Original Message-----
        From: Keith Davies [mailto:kjdavies@...]
        Sent: Friday, January 11, 2002 12:34 AM
        To: pcgen-xml
        Subject: [pcgen-xml] PCGen XML design philosophy

        Hi All,

        I've been examining the data to be encoded and have an interesting
        question.

        The simple, straightforward way of tackling this project would be to
        simply define a schema around what is currently used in the LST files.
        We could be done by the end of the month (<pffft, right>). The other
        is to -- to some extent, at least -- ignore what the LST files hold
        currently and examine the *data* available, the stuff from the books,
        and derive a more object-centric model.

        There are benefits to both. The first, as I mentioned, could probably
        be relatively quickly. A simple translation from 'tabs and tags' to
        XML should be pretty straightforward. It would probably have less
        impact on PCGen because the data relationships would be the same.

        The second requires a lot more thought and design effort. This will
        give us the opportunity to normalize the data (thereby reducing
        redundancy in the data) and -- I think -- give us the ability to make
        the data design a little more general and more easily extensible.
        This will take a great deal longer than the first option, and can have
        a large impact on PCGen because many of the data relationships will
        have changed, in some cases a great deal.

        I've got a preference here, but I'd like to hear from you before stating
        them -- I'd like to try to keep my bias out of it for now.


        Keith
        --
        Keith Davies
        kjdavies@...

        Elarios: "Shade, you showed honor and mercy
        "Raven, you were couragous beyond expectation
        "Logan, you resisted the temptation of knowledge."

        Logan: "That's... good, right?"


        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
        ... Okay. The first option is a simple, straight-forward translation. The files and elements would have exactly the same data they do now, but in a different
        Message 3 of 18 , Jan 10, 2002
        • 0 Attachment
          Mynex wrote on Thu Jan 10 21:51:21 2002:
          >
          > Okay, to make it easier for everyone, give a quick (in English for new
          > XML folk and the layman just reading to see what's up) overall
          > explanation by what you mean for both options (as in the steps you'd
          > take to do them and why).

          Okay.

          The first option is a simple, straight-forward translation. The files
          and elements would have exactly the same data they do now, but in a
          different (XML) format.

          In playershbweapammo.lst, "Axe (Throwing)" would become something like

          <weapon>
          <name>Axe (Throwing)</name>
          <type>Weapon</type>
          <type>Martial</type>
          <type>Melee</type>
          <type>Standard</type>
          <type>Slashing</type>
          <type>Metal</type>
          <cost>8</cost>
          <weight>4</weight>
          <size>S</size>
          <damage>1d6</damage>
          <critrange>1</critrange>
          <critmult>x2</critmult>
          <proficiency>Axe</proficiency>
          </weapon>

          A simple, straight-forward translation. We could make the schema have
          exactly the same tags as are currently present, and creating a script
          to convert things should be fairly easy. It supports the core rules

          The second is more difficult. I would probably do something like:

          <weapon id="weapon.axe.throwing" name="Throwing Axe" basecost="8"
          critrange="1" critmult="2" damage="1d6" size="S" weight="4"
          metal="Y" slashing="Y"/>

          <campaign id="campaign.core" name="Core Rules">
          <weaponset id="core.weapons.martial.melee" name="Martial Melee">
          <ref refid="weapon.axe.throwing"/>
          <ref refid="weapon.sword.short"/>
          <ref refid="weapon.sword.long"/>
          </weaponset>
          </campaign>

          <campaign id="campaign.keith" name="Keith's Rules">
          <weaponset id="keith.weapons.chivalric">
          <ref refid="weapon.sword.long"/>
          <ref refid="weapon.lance.heavy"/>
          <ref refid="weapon.lance.medium"/>
          <ref refid="weapon.mace.light"/>
          </weaponset>
          <weaponset id="keith.weapons.military">
          <ref refid="weapon.sword.short"/>
          <ref refid="weapon.crossbow.light"/>
          <ref refid="weapon.crossbow.heavy"/>
          <ref refid="weapon.longspear"/>
          </weaponset>
          <weaponset id="keith.weapons.mongol">
          <ref refid="weapon.bow.composite.short"/>
          <ref refid="weapon.lance.light"/>
          <ref refid="weapon.sword.scimitar"/>
          <!-- I know that one's wrong, can't be bothered to look it up -->
          </weaponset>
          </campaign>

          Obviously, lots of stuff is being omitted here.

          This has an obvious benefit in that the classification of weapons can
          change from campaign to campaign, and that weapons can have multiple
          classifications. The down side -- and it's a *big* one -- is that this
          will be a lot of work for all involved. I expect the schema will be
          'decentralized', meaning that you'll have to go to more places to find
          all the information about something. OTOH, it'll also be better
          normalized, meaning that each piece of information should only be needed
          once.


          > I also have a preference, but, like you, I would prefer to hold it back
          > for the moment.

          I suppose we could condense it to:

          'do we want it easy for all involved (least amount of work to translate
          and least impact on the program), or do we want to do a lot of work,
          which will lead to a lot of work in the program, but have something
          that will be very flexible and powerful?

          Keith

          > -----Original Message-----
          > From: Keith Davies [mailto:kjdavies@...]
          > Sent: Friday, January 11, 2002 12:34 AM
          > To: pcgen-xml
          > Subject: [pcgen-xml] PCGen XML design philosophy
          >
          > Hi All,
          >
          > I've been examining the data to be encoded and have an interesting
          > question.
          >
          > The simple, straightforward way of tackling this project would be to
          > simply define a schema around what is currently used in the LST files.
          > We could be done by the end of the month (<pffft, right>). The other
          > is to -- to some extent, at least -- ignore what the LST files hold
          > currently and examine the *data* available, the stuff from the books,
          > and derive a more object-centric model.
          >
          > There are benefits to both. The first, as I mentioned, could probably
          > be relatively quickly. A simple translation from 'tabs and tags' to
          > XML should be pretty straightforward. It would probably have less
          > impact on PCGen because the data relationships would be the same.
          >
          > The second requires a lot more thought and design effort. This will
          > give us the opportunity to normalize the data (thereby reducing
          > redundancy in the data) and -- I think -- give us the ability to make
          > the data design a little more general and more easily extensible.
          > This will take a great deal longer than the first option, and can have
          > a large impact on PCGen because many of the data relationships will
          > have changed, in some cases a great deal.
          >
          > I've got a preference here, but I'd like to hear from you before stating
          > them -- I'd like to try to keep my bias out of it for now.
          >
          >
          > Keith
          > --
          > Keith Davies
          > kjdavies@...
          >
          > Elarios: "Shade, you showed honor and mercy
          > "Raven, you were couragous beyond expectation
          > "Logan, you resisted the temptation of knowledge."
          >
          > Logan: "That's... good, right?"
          >
          >
          > 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/
          >
          >
          >
          >
          > 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
          kjdavies@...

          Elarios: "Shade, you showed honor and mercy
          "Raven, you were couragous beyond expectation
          "Logan, you resisted the temptation of knowledge."

          Logan: "That's... good, right?"
        • Ryan Koppenhaver
          ... You re asking the wrong question. I think, and I expect this will make my own bias pretty obvious, that the question is Do we want to do a lot of work
          Message 4 of 18 , Jan 10, 2002
          • 0 Attachment
            --- Keith Davies <kjdavies@...> wrote:
            > I suppose we could condense it to:
            >
            > 'do we want it easy for all involved (least amount of work to
            > translate
            > and least impact on the program), or do we want to do a lot of work,
            > which will lead to a lot of work in the program, but have something
            > that will be very flexible and powerful?

            You're asking the wrong question. I think, and I expect this will make
            my own bias pretty obvious, that the question is "Do we want to do a
            lot of work now to get the schema right, or do we want to do a lot of
            work later, when someone asks for a feature that we didn't plan for,
            and can't easily extend things to include?"


            My vote is for building around the data.

            -Ryan

            __________________________________________________
            Do You Yahoo!?
            Send FREE video emails in Yahoo! Mail!
            http://promo.yahoo.com/videomail/
          • Mynex
            E forgetting something in this... soon (hopefully) all non basic weapons/armor/equipment is going to be gone. The custom button will be filling in all special
            Message 5 of 18 , Jan 10, 2002
            • 0 Attachment
              E forgetting something in this... soon (hopefully) all non basic
              weapons/armor/equipment is going to be gone. The custom button will be
              filling in all special properties (+'s, Keen, Spells, etc) So that
              would actually make #2 a lot easier. We would only need to define the
              base item categories, and make sure the custom button applied the
              correct ones. Much, much simpler.

              Keeping that in mind, it would actually be a lot easier then to combine
              the 2 together. The other thing, I've been pestering Bryan to make all
              the tags that are available into global tags (whether a file uses them
              or not, doesn't matter, so long as it has the capability of using them -
              and let's avoid the argument of whether the VISION tag needs to be in
              the spells list and the like please, it's for simplicities sake that I'm
              asking for this)... If/once this is implemented, making the combination
              of the choices you presented becomes even more feasible.

              It will require some serious planning yes, but the planning should be
              the hardest part, once that's done, implementation should be smooth.

              And my preference was the combination of the 2, barring that, #2 would
              have won. :)

              Mynex

              - Dark Sith Silverback Android, Dark Lord of the Docs, The Sleepless
              One, The Code Badger

              -----Original Message-----
              From: Keith Davies [mailto:kjdavies@...]
              Sent: Friday, January 11, 2002 1:21 AM
              To: pcgen-xml@yahoogroups.com
              Subject: Re: [pcgen-xml] PCGen XML design philosophy

              Mynex wrote on Thu Jan 10 21:51:21 2002:
              >
              > Okay, to make it easier for everyone, give a quick (in English for new
              > XML folk and the layman just reading to see what's up) overall
              > explanation by what you mean for both options (as in the steps you'd
              > take to do them and why).

              Okay.

              The first option is a simple, straight-forward translation. The files
              and elements would have exactly the same data they do now, but in a
              different (XML) format.

              In playershbweapammo.lst, "Axe (Throwing)" would become something like

              <weapon>
              <name>Axe (Throwing)</name>
              <type>Weapon</type>
              <type>Martial</type>
              <type>Melee</type>
              <type>Standard</type>
              <type>Slashing</type>
              <type>Metal</type>
              <cost>8</cost>
              <weight>4</weight>
              <size>S</size>
              <damage>1d6</damage>
              <critrange>1</critrange>
              <critmult>x2</critmult>
              <proficiency>Axe</proficiency>
              </weapon>

              A simple, straight-forward translation. We could make the schema have
              exactly the same tags as are currently present, and creating a script
              to convert things should be fairly easy. It supports the core rules

              The second is more difficult. I would probably do something like:

              <weapon id="weapon.axe.throwing" name="Throwing Axe" basecost="8"
              critrange="1" critmult="2" damage="1d6" size="S" weight="4"
              metal="Y" slashing="Y"/>

              <campaign id="campaign.core" name="Core Rules">
              <weaponset id="core.weapons.martial.melee" name="Martial Melee">
              <ref refid="weapon.axe.throwing"/>
              <ref refid="weapon.sword.short"/>
              <ref refid="weapon.sword.long"/>
              </weaponset>
              </campaign>

              <campaign id="campaign.keith" name="Keith's Rules">
              <weaponset id="keith.weapons.chivalric">
              <ref refid="weapon.sword.long"/>
              <ref refid="weapon.lance.heavy"/>
              <ref refid="weapon.lance.medium"/>
              <ref refid="weapon.mace.light"/>
              </weaponset>
              <weaponset id="keith.weapons.military">
              <ref refid="weapon.sword.short"/>
              <ref refid="weapon.crossbow.light"/>
              <ref refid="weapon.crossbow.heavy"/>
              <ref refid="weapon.longspear"/>
              </weaponset>
              <weaponset id="keith.weapons.mongol">
              <ref refid="weapon.bow.composite.short"/>
              <ref refid="weapon.lance.light"/>
              <ref refid="weapon.sword.scimitar"/>
              <!-- I know that one's wrong, can't be bothered to look it up -->
              </weaponset>
              </campaign>

              Obviously, lots of stuff is being omitted here.

              This has an obvious benefit in that the classification of weapons can
              change from campaign to campaign, and that weapons can have multiple
              classifications. The down side -- and it's a *big* one -- is that this
              will be a lot of work for all involved. I expect the schema will be
              'decentralized', meaning that you'll have to go to more places to find
              all the information about something. OTOH, it'll also be better
              normalized, meaning that each piece of information should only be needed
              once.


              > I also have a preference, but, like you, I would prefer to hold it
              back
              > for the moment.

              I suppose we could condense it to:

              'do we want it easy for all involved (least amount of work to translate
              and least impact on the program), or do we want to do a lot of work,
              which will lead to a lot of work in the program, but have something
              that will be very flexible and powerful?

              Keith

              > -----Original Message-----
              > From: Keith Davies [mailto:kjdavies@...]
              > Sent: Friday, January 11, 2002 12:34 AM
              > To: pcgen-xml
              > Subject: [pcgen-xml] PCGen XML design philosophy
              >
              > Hi All,
              >
              > I've been examining the data to be encoded and have an interesting
              > question.
              >
              > The simple, straightforward way of tackling this project would be to
              > simply define a schema around what is currently used in the LST files.
              > We could be done by the end of the month (<pffft, right>). The other
              > is to -- to some extent, at least -- ignore what the LST files hold
              > currently and examine the *data* available, the stuff from the books,
              > and derive a more object-centric model.
              >
              > There are benefits to both. The first, as I mentioned, could probably
              > be relatively quickly. A simple translation from 'tabs and tags' to
              > XML should be pretty straightforward. It would probably have less
              > impact on PCGen because the data relationships would be the same.
              >
              > The second requires a lot more thought and design effort. This will
              > give us the opportunity to normalize the data (thereby reducing
              > redundancy in the data) and -- I think -- give us the ability to make
              > the data design a little more general and more easily extensible.
              > This will take a great deal longer than the first option, and can have
              > a large impact on PCGen because many of the data relationships will
              > have changed, in some cases a great deal.
              >
              > I've got a preference here, but I'd like to hear from you before
              stating
              > them -- I'd like to try to keep my bias out of it for now.
              >
              >
              > Keith
              > --
              > Keith Davies
              > kjdavies@...
              >
              > Elarios: "Shade, you showed honor and mercy
              > "Raven, you were couragous beyond expectation
              > "Logan, you resisted the temptation of knowledge."
              >
              > Logan: "That's... good, right?"
              >
              >
              > 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/
              >
              >
              >
              >
              > 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
              kjdavies@...

              Elarios: "Shade, you showed honor and mercy
              "Raven, you were couragous beyond expectation
              "Logan, you resisted the temptation of knowledge."

              Logan: "That's... good, right?"


              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/
            • Ryan Koppenhaver
              ... What about specific weapons, like a Flametongue, or a Rapier of Puncturing? Are users going to have to build those themselves? -Ryan
              Message 6 of 18 , Jan 10, 2002
              • 0 Attachment
                --- Mynex <mynex3@...> wrote:
                > E forgetting something in this... soon (hopefully) all non basic
                > weapons/armor/equipment is going to be gone.

                What about specific weapons, like a Flametongue, or a Rapier of
                Puncturing? Are users going to have to build those themselves?

                -Ryan

                __________________________________________________
                Do You Yahoo!?
                Send FREE video emails in Yahoo! Mail!
                http://promo.yahoo.com/videomail/
              • Mynex
                No, the specific weapons/armor/items will remain, they ll be in xxxspecifac.lst files.. at least that s the plan. It may change, but I doubt it. Mynex - Dark
                Message 7 of 18 , Jan 10, 2002
                • 0 Attachment
                  No, the specific weapons/armor/items will remain, they'll be in
                  xxxspecifac.lst files.. at least that's the plan. It may change, but I
                  doubt it.

                  Mynex

                  - Dark Sith Silverback Android, Dark Lord of the Docs, The Sleepless
                  One, The Code Badger


                  -----Original Message-----
                  From: Ryan Koppenhaver [mailto:rlkoppenhaver@...]
                  Sent: Friday, January 11, 2002 1:50 AM
                  To: pcgen-xml@yahoogroups.com
                  Subject: RE: [pcgen-xml] PCGen XML design philosophy

                  --- Mynex <mynex3@...> wrote:
                  > E forgetting something in this... soon (hopefully) all non basic
                  > weapons/armor/equipment is going to be gone.

                  What about specific weapons, like a Flametongue, or a Rapier of
                  Puncturing? Are users going to have to build those themselves?

                  -Ryan
                • Ryan Koppenhaver
                  ... Which means we ll still need the ability to specify customizations in the data files, right? __________________________________________________ Do You
                  Message 8 of 18 , Jan 10, 2002
                  • 0 Attachment
                    --- Mynex <mynex3@...> wrote:
                    > No, the specific weapons/armor/items will remain, they'll be in
                    > xxxspecifac.lst files.. at least that's the plan. It may change, but
                    > I
                    > doubt it.

                    Which means we'll still need the ability to specify customizations in
                    the data files, right?

                    __________________________________________________
                    Do You Yahoo!?
                    Send FREE video emails in Yahoo! Mail!
                    http://promo.yahoo.com/videomail/
                  • Ryan Koppenhaver
                    ... Ok, that s basically what I wanted to make sure of. I thought Mynex was saying that we wouldn t need those things, because we d have the Customize
                    Message 9 of 18 , Jan 11, 2002
                    • 0 Attachment
                      --- Keith Davies <kjdavies@...> wrote:
                      > Ryan Koppenhaver wrote on Thu Jan 10 23:04:23 2002:
                      > >
                      > > --- Mynex <mynex3@...> wrote:
                      > > > No, the specific weapons/armor/items will remain, they'll be in
                      > > > xxxspecifac.lst files.. at least that's the plan. It may change,
                      > but
                      > > > I
                      > > > doubt it.
                      > >
                      > > Which means we'll still need the ability to specify customizations
                      > in
                      > > the data files, right?
                      >
                      > The short answer to this is that we will not *remove* any
                      > functionality
                      > currently in the system. We may well *rearrange* things, though.
                      >
                      > That said, I expect to have a <material> tag (to allow for special
                      > woods
                      > and metals for items), <bonus> tag (to describe various bonuses, even
                      > allowing a sword that adds to the Profession(Harlot) skill), and so
                      > on.
                      > You'll be able to add customizations to the system.

                      Ok, that's basically what I wanted to make sure of. I thought Mynex
                      was saying that we wouldn't need those things, because we'd have the
                      "Customize" button, which, of course, isn't the case.

                      > I also expect to be able to store customized objects (which may have
                      > been
                      > what you were actually asking). These may or may not show up in the
                      > main
                      > lists being displayed. It may also be possible to mark certain items
                      > 'unique' or in limited number; I dunno if we'll go there.

                      I wasn't asking, but I know it's been suggested before.

                      __________________________________________________
                      Do You Yahoo!?
                      Send FREE video emails in Yahoo! Mail!
                      http://promo.yahoo.com/videomail/
                    • Keith Davies
                      ... The short answer to this is that we will not *remove* any functionality currently in the system. We may well *rearrange* things, though. That said, I
                      Message 10 of 18 , Jan 11, 2002
                      • 0 Attachment
                        Ryan Koppenhaver wrote on Thu Jan 10 23:04:23 2002:
                        >
                        > --- Mynex <mynex3@...> wrote:
                        > > No, the specific weapons/armor/items will remain, they'll be in
                        > > xxxspecifac.lst files.. at least that's the plan. It may change, but
                        > > I
                        > > doubt it.
                        >
                        > Which means we'll still need the ability to specify customizations in
                        > the data files, right?

                        The short answer to this is that we will not *remove* any functionality
                        currently in the system. We may well *rearrange* things, though.

                        That said, I expect to have a <material> tag (to allow for special woods
                        and metals for items), <bonus> tag (to describe various bonuses, even
                        allowing a sword that adds to the Profession(Harlot) skill), and so on.
                        You'll be able to add customizations to the system.

                        I also expect to be able to store customized objects (which may have been
                        what you were actually asking). These may or may not show up in the main
                        lists being displayed. It may also be possible to mark certain items
                        'unique' or in limited number; I dunno if we'll go there.

                        I had some other comments to make, but I'll leave them out until a couple
                        more people have responded so I don't influence the comments at this time.


                        Keith
                        --
                        Keith Davies
                        kjdavies@...

                        Elarios: "Shade, you showed honor and mercy
                        "Raven, you were couragous beyond expectation
                        "Logan, you resisted the temptation of knowledge."

                        Logan: "That's... good, right?"
                      • STILES, BRAD
                        ... Ya know, I don t think I even want to know where that came from... Hey, gimme that f*cking sword! How did you know? Anyway, I tend to go with #2,
                        Message 11 of 18 , Jan 11, 2002
                        • 0 Attachment
                          > -----Original Message-----
                          > From: Keith Davies
                          >
                          > describe various bonuses, even allowing a sword that adds
                          > to the Profession(Harlot) skill), and so on.

                          Ya know, I don't think I even want to know where that came from...

                          "Hey, gimme that f*cking sword!"

                          "How did you know?"

                          Anyway, I tend to go with #2, though I think that noone should underestimate
                          the amount of work that will go into that. In the end, though, it should be
                          worth it. Like some others here, I spend a good portion of my day working
                          with databases, and that's what your attempting to build with that option.

                          My general approach is to normalize the *heck* out of the data, without
                          regard to what I think may eventually be needed, then back off in those
                          places where it makes sense to do so, for optimization or maintenence
                          reasons.

                          Brad
                        • samspectre
                          ... stating ... Not being a programmer, I still think the second option sounds best. My only reservation is that I (and probably many other people that are
                          Message 12 of 18 , Jan 11, 2002
                          • 0 Attachment
                            --- In pcgen-xml@y..., Keith Davies <kjdavies@t...> wrote:
                            > I've got a preference here, but I'd like to hear from you before
                            stating
                            > them -- I'd like to try to keep my bias out of it for now.

                            Not being a programmer, I still think the second option sounds best.
                            My only reservation is that I (and probably many other people that
                            are using the program) have made scads of personal .LST files which
                            may have to be re-worked if we go to the new format. Personally, I
                            don't have much of a problem with that, but if we go with anything
                            more complicated than what is there now, we should make a concerted
                            effort to document everything well so that non-programmers
                            can "follow along" without asking "too many" questions.

                            Dennis
                            dennis@...
                          • Karl-Petter Åkesson
                            I also vote for the second option. Flexibile and extensionable is always good! But we should not forget joe and his friends. So we seems to have one or two
                            Message 13 of 18 , Jan 11, 2002
                            • 0 Attachment
                              I also vote for the second option. Flexibile and extensionable is always
                              good! But we should not forget joe and his friends. So we seems to have
                              one or two 'normal users' here but maybe we should actually plan to make
                              some user-trials as well. I would be happy to perform some more in depth
                              tests with some friends once we got something to I can expose them to.

                              Kalle

                              samspectre wrote:
                              >
                              > --- In pcgen-xml@y..., Keith Davies <kjdavies@t...> wrote:
                              > > I've got a preference here, but I'd like to hear from you before
                              > stating
                              > > them -- I'd like to try to keep my bias out of it for now.
                              >
                              > Not being a programmer, I still think the second option sounds best.
                              > My only reservation is that I (and probably many other people that
                              > are using the program) have made scads of personal .LST files which
                              > may have to be re-worked if we go to the new format. Personally, I
                              > don't have much of a problem with that, but if we go with anything
                              > more complicated than what is there now, we should make a concerted
                              > effort to document everything well so that non-programmers
                              > can "follow along" without asking "too many" questions.
                              >
                              > Dennis
                              > dennis@...
                              >
                              >
                              > 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/
                            • jdk_kjdavies
                              ... always ... have ... make ... depth ... to. Heh. I eat a lot of dogfood[1]... I don t release anything into the wild before I know how it behaves and how
                              Message 14 of 18 , Jan 11, 2002
                              • 0 Attachment
                                --- In pcgen-xml@y..., Karl-Petter Åkesson <kalle@s...> wrote:
                                > I also vote for the second option. Flexibile and extensionable is
                                always
                                > good! But we should not forget joe and his friends. So we seems to
                                have
                                > one or two 'normal users' here but maybe we should actually plan to
                                make
                                > some user-trials as well. I would be happy to perform some more in
                                depth
                                > tests with some friends once we got something to I can expose them
                                to.

                                Heh. I eat a lot of dogfood[1]... I don't release anything into the
                                wild before I know how it behaves and how easy it is to use. In this
                                case, I'll be hand-coding a number of examples to see how they fit
                                together -- how easy it is to work with them, how long it takes to
                                create a new object, and so on. We can have Joes doing the same
                                thing.

                                [1] I don't know the origin, but I first saw it in the Jargon File.
                                It means to use your own code/product for real (as opposed to test)
                                for real work, so you can see how it works. For instance, the
                                Mozilla programmers 'eat dogfood' by using the browser they're
                                working on for actually browsing the web, not just testing during
                                development.

                                Keith
                                [posting from web because home connection being upgraded today]
                              • Karl-Petter Åkesson
                                Eating a lot of dog food dont necessarily makes something easy to use. It sure removes bugs and things like that, but you are still an expert on the system
                                Message 15 of 18 , Jan 11, 2002
                                • 0 Attachment
                                  Eating a lot of dog food dont necessarily makes something easy to use.
                                  It sure removes bugs and things like that, but you are still an expert
                                  on the system since you created it and you cant tell how it is
                                  interpreted by a novel user.

                                  Kalle

                                  jdk_kjdavies wrote:
                                  >
                                  > --- In pcgen-xml@y..., Karl-Petter Åkesson <kalle@s...> wrote:
                                  > > I also vote for the second option. Flexibile and extensionable is
                                  > always
                                  > > good! But we should not forget joe and his friends. So we seems to
                                  > have
                                  > > one or two 'normal users' here but maybe we should actually plan to
                                  > make
                                  > > some user-trials as well. I would be happy to perform some more in
                                  > depth
                                  > > tests with some friends once we got something to I can expose them
                                  > to.
                                  >
                                  > Heh. I eat a lot of dogfood[1]... I don't release anything into the
                                  > wild before I know how it behaves and how easy it is to use. In this
                                  > case, I'll be hand-coding a number of examples to see how they fit
                                  > together -- how easy it is to work with them, how long it takes to
                                  > create a new object, and so on. We can have Joes doing the same
                                  > thing.
                                  >
                                  > [1] I don't know the origin, but I first saw it in the Jargon File.
                                  > It means to use your own code/product for real (as opposed to test)
                                  > for real work, so you can see how it works. For instance, the
                                  > Mozilla programmers 'eat dogfood' by using the browser they're
                                  > working on for actually browsing the web, not just testing during
                                  > development.
                                  >
                                  > Keith
                                  > [posting from web because home connection being upgraded today]
                                  >
                                  >
                                  > 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/
                                • jdk_kjdavies
                                  ... use. ... expert ... True, which is why we also have Joes test it. Dogfood helps identify bugs, but the main benefit gained here is identifying when
                                  Message 16 of 18 , Jan 11, 2002
                                  • 0 Attachment
                                    --- In pcgen-xml@y..., Karl-Petter Åkesson <kalle@s...> wrote:
                                    > Eating a lot of dog food dont necessarily makes something easy to
                                    use.
                                    > It sure removes bugs and things like that, but you are still an
                                    expert
                                    > on the system since you created it and you cant tell how it is
                                    > interpreted by a novel user.

                                    True, which is why we also have Joes test it. Dogfood helps identify
                                    bugs, but the main benefit gained here is identifying when something
                                    is a pain in the ass to work with. If *I* find it a hassle to work
                                    with, most Joes would probably gag on it.

                                    Keith
                                  • Scott Ellsworth
                                    ... Kalle: I especially like your suggestion to try out some of this on our intended audience. If we create a few use cases, we will probably find a lot of
                                    Message 17 of 18 , Jan 11, 2002
                                    • 0 Attachment
                                      >I also vote for the second option. Flexibile and extensionable is always
                                      >good! But we should not forget joe and his friends.

                                      Kalle: I especially like your suggestion to try out some of this on
                                      our intended audience. If we create a few use cases, we will
                                      probably find a lot of misthinking before we are committed.

                                      I think we should be very wary of the "joe and his friends" argument.
                                      I have taught completely non technical people how to edit an HTML or
                                      XML file in a surprisingly short time with a plain old text editor, a
                                      provided schema, and a validator - edit the file, run it through the
                                      validator, and if it flies, then your file is at least not junk.
                                      They got it in an amazingly short time.

                                      I had to provide the validator, the summarizer, and the schema for
                                      the above, but core data entry was just not a problem, and these were
                                      utterly computer illiterate people just entering books in a card
                                      catalog. (The summarizer ran through the file and listed the book
                                      titles they had entered, so they could have an easy eyeball check on
                                      the most critical data.)

                                      This does not mean that we should be purposely obscure, or needlessly
                                      complicated, just that when given the choice between clear and
                                      obscure, we should see if there is a clear way to do what the obscure
                                      code was trying for.

                                      The example Keith posted, where acid fog had a refid, was something
                                      that a user could handle, I think, because they are not likely to be
                                      adding a whole new domain the first time out of the gate. As long as
                                      they are adding to something that exists, they have examples they can
                                      follow.

                                      If they are, then they are letting themselves in for a fair amount of
                                      work in any event, and if they have to define the domain separately
                                      from the actual spell, this is probably not going to make them
                                      unhappy.

                                      Thus, I suspect we should do as Kalle suggested - put together a list
                                      of common additions people want, and write a very short howto with
                                      each of our designs, and see if we are asking more of the users than
                                      we want to.

                                      For example:

                                      To customize PCGen for your campaign, you must first ask whether you
                                      have changed any spells, added weapons or armor, or otherwise changed
                                      a core rules set. If you have, then you must tell PCGen that you are
                                      not running in a standard world.

                                      It is easiest if your campaign only adds things to a standard
                                      setting. For example, if you have all of the standard weapons in
                                      your campaign, but have added the Gnome Exploding Watch to the game
                                      as a gnome ranged weapon, then your task is fairly easy.

                                      You first must define the weapon itself.

                                      weapon id="weapon.exploding.watch" name="Exploding Watch">
                                      <basecost>200</basecost>
                                      <size>Tiny</size>
                                      <category>Slashing</category>
                                      </weapon>

                                      ------
                                      Aside: I made "slashing" a category under the weapon element, rather
                                      than an attribute, because weapons can have more than one category,
                                      and it might be handy to be able to list all of the slashing weapons
                                      in a file in one chart.

                                      When I do need to use an attribute or element value as a boolean, I
                                      find that saying "true" or "false" has worked pretty well, since it
                                      then goes more easily into relational dbs if one wants to do so:
                                      reusable="true"

                                      ------

                                      You first must tell PCGen that you have added a new campaign and set
                                      of custom rules. This is how it knows which equipment, races,
                                      spells, and classes are allowed.

                                      <campaign id="campaign.mine" name="My new campaign" based_on="campaign.core">
                                      <weaponset add_to_id="core.weapons.martial.ranged">
                                      <ref refid="weapon.watch.exploding"/>
                                      </weaponset>
                                      </campaign>

                                      This tells PCGen that your campaign is adding a new weapon to the
                                      core martial ranged weapons.

                                      You could have added spellsets, equipmentsets, classsets, domainsets,
                                      or racesets at the same time - each of these would be considered an
                                      ADDITION, not a change.

                                      Now presume that you have a brand new weapon category - gnome
                                      exploding goodies. You could make this entirely new category of
                                      weapons, requiring exotic proficiency, by putting in the following
                                      file:

                                      <campaign id="campaign.mine" name="My new campaign" based_on="campaign.core">
                                      <weaponset add_to_id="mine.weapons.exploding.ranged">
                                      <ref refid="weapon.watch.exploding"/>
                                      </weaponset>
                                      </campaign>

                                      Finally, if your campaign has gotten to the point where you do not
                                      want any of the core weapons loaded, you need to provide your
                                      weaponset without including the core rules.

                                      <campaign id="campaign.mine" name="My new campaign">
                                      <weaponset refid="mine.weapons.exploding.ranged">
                                      <ref refid="weapon.watch.exploding"/>
                                      </weaponset>
                                      <weaponset refid="mine.weapons.martial.melee">
                                      <ref refid="weapon.watch.stabbing"/>
                                      </weaponset>
                                      </campaign>

                                      -------

                                      I think these use cases will serve us well, because if we have a hard
                                      time writing the docs, it probably indicates that we have a confusing
                                      task, and should try to simplify it.
                                      Scott
                                      --
                                    • jdk_kjdavies
                                      ... based_on= campaign.core ... *Very* nice. It was something I was planning to use, cept I was thinking something like
                                      Message 18 of 18 , Jan 11, 2002
                                      • 0 Attachment
                                        --- In pcgen-xml@y..., Scott Ellsworth <scott@a...> wrote:

                                        > <campaign id="campaign.mine" name="My new campaign"
                                        based_on="campaign.core">
                                        > <weaponset add_to_id="mine.weapons.exploding.ranged">
                                        > <ref refid="weapon.watch.exploding"/>
                                        > </weaponset>
                                        > </campaign>

                                        *Very* nice. It was something I was planning to use, 'cept I was
                                        thinking something like

                                        <campaign id="campaign.mine" name="My new campaign"
                                        baseid="campaign.core">
                                        <alter-list refid="core.weapon.martial.ranged">
                                        <insert refid="weapon.watch.exploding"/>
                                        </alter-list>
                                        </campaign>

                                        > Finally, if your campaign has gotten to the point where you do not
                                        > want any of the core weapons loaded, you need to provide your
                                        > weaponset without including the core rules.
                                        >
                                        > <campaign id="campaign.mine" name="My new campaign">
                                        > <weaponset refid="mine.weapons.exploding.ranged">
                                        > <ref refid="weapon.watch.exploding"/>
                                        > </weaponset>
                                        > <weaponset refid="mine.weapons.martial.melee">
                                        > <ref refid="weapon.watch.stabbing"/>
                                        > </weaponset>
                                        > </campaign>

                                        <campaign id="campaign.mine" name="My new campaign"
                                        baseid="campaign.core">
                                        <omit refid="core.weapon.martial.ranged"/>
                                        <omit refid="spell.fireball"/>
                                        </campaign>

                                        > I think these use cases will serve us well, because if we have a
                                        hard
                                        > time writing the docs, it probably indicates that we have a
                                        confusing
                                        > task, and should try to simplify it.

                                        I've generally found the same thing -- if I can't describe something,
                                        I'm going to find it hard to build... implementation should
                                        (generally, and in my experience it does) fall out of the earlier
                                        stages. If you're having trouble implementing, your design is
                                        probably wrong, and if you can't describe your stuff, you won't be
                                        able to to design it properly.

                                        Keith
                                      Your message has been successfully submitted and would be delivered to recipients shortly.