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

Re: Getting back on track?

Expand Messages
  • adnd-pcgen@eec.com
    ... Hi, Peter. ... You don t know me; I ve been a lurker here for awhile. I m interested in doing some XML development as a learning process, and I have a
    Message 1 of 8 , Aug 9, 2002
    • 0 Attachment
      On 9 Aug 2002 pcgen-xml@yahoogroups.com wrote:
      > Date: Thu, 8 Aug 2002 13:46:54 -0500
      > From: Peter Kahle <pkahle@...>
      >
      > Hi Folks,

      Hi, Peter.

      > Well, I've gotten my interest in this part of the project re-kindled by
      > the discussion of LST-Editors and the discussion on the d20-xml list.

      You don't know me; I've been a lurker here for awhile. I'm interested in
      doing some XML development as a learning process, and I have a great
      interest in PCGen and Java (and programming, in general).

      However, I also don't have a lot of time right now -- business will be
      busy until the early November timeframe. :-(

      > So I'm trying to think of how we should go about attacking this monster of
      > a project. What I'm thinking is, it may be best to implement it
      > piecemeal, even as we're refining the schema we want to use. Perhaps we
      > should start with something simple and somewhat out of the scope of
      > actual character representation, maybe XML based .pcc files (.pccx?).
      > I think that might be a good place to start, as it's got a relatively
      > simple format at the moment, it's got a proposal/new implementation to
      > handle campaign options from it, and if we convert it, we can maintain
      > both .lst and .lstx loading from within the same .pccx file as we
      > complete the conversion.

      I agree -- that sounds like a good place to start.

      I'm guessing that your last statement was referring to the XML ability to
      include other XML document content?

      > I'll try to knock out a schema, pcc to pccx and
      > pccx to pcc converter, and the code needed to get pcgen to run with it
      > sometime soon, but I doubt I'll have much to show in the next week or
      > so. (houseguests)

      Will your converter be just an XSLT processor (I presume it will)?

      > Anybody have any comments on this?
      > P

      Regards,
      --
      Frank J. Edwards
      <adnd-pcgen@...>
    • Peter Kahle
      ... Heh, We all know how that goes. ... Well, that s one way to do it, and probably the way to go in the end, but for a first step, I was more thinking of
      Message 2 of 8 , Aug 9, 2002
      • 0 Attachment
        On Fri, Aug 09, 2002 at 11:58:42AM -0400, adnd-pcgen@... wrote:
        > On 9 Aug 2002 pcgen-xml@yahoogroups.com wrote:
        > > Date: Thu, 8 Aug 2002 13:46:54 -0500
        > > From: Peter Kahle <pkahle@...>
        > >
        > > Hi Folks,
        >
        > Hi, Peter.
        >
        > > Well, I've gotten my interest in this part of the project re-kindled by
        > > the discussion of LST-Editors and the discussion on the d20-xml list.
        >
        > You don't know me; I've been a lurker here for awhile. I'm interested in
        > doing some XML development as a learning process, and I have a great
        > interest in PCGen and Java (and programming, in general).
        >
        > However, I also don't have a lot of time right now -- business will be
        > busy until the early November timeframe. :-(

        Heh, We all know how that goes.

        > > I think that might be a good place to start, as it's got a relatively
        > > simple format at the moment, it's got a proposal/new implementation to
        > > handle campaign options from it, and if we convert it, we can maintain
        > > both .lst and .lstx loading from within the same .pccx file as we
        > > complete the conversion.
        >
        > I agree -- that sounds like a good place to start.
        >
        > I'm guessing that your last statement was referring to the XML ability to
        > include other XML document content?

        Well, that's one way to do it, and probably the way to go in the end,
        but for a first step, I was more thinking of creating something that
        goes thru the .pccx file and calls loader functions for each type of
        file (say we've got <class-lst file='playershbclass.lst' /> in the
        .pccx file, or maybe <file type='class' href='playershbclass.lst' />.
        For each class file it finds, it would call a method, say
        loadClassesFromLST("playershbclass.lst") that would handle the actual
        loading. Then, after we implement class functionality from an XML file,
        we'd change it to <lstx file='playershbclass.lstx'/> or <file type='xml'
        href='playershbclass.lstx'/> and it would instead call
        loadFromXML("playershbclass.lstx"). Calling it this way seems like it
        might provide better performance than parsing it all into one big tree
        (though SAX might fix some of the problems, but I'm more familiar with
        DOM, so that's what I'm thinking about.)

        Anyway, it's all up in the air, and can be done any number of ways,
        we'll see what works as we try it out.

        > > I'll try to knock out a schema, pcc to pccx and
        > > pccx to pcc converter, and the code needed to get pcgen to run with it
        > > sometime soon, but I doubt I'll have much to show in the next week or
        > > so. (houseguests)
        >
        > Will your converter be just an XSLT processor (I presume it will)?

        Well, the pccx to pcc converter will be, but I already wrote a little
        python script to do pcc to pccx conversion (slow day at work yesterday).
        If it's possible to use XSLT to go from pcc to pccx somebody please let
        me know, but I was under the impression it wasn't.

        P
        --

        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://www.kahlilia.org/~pkahle/ ||
        ##===============================##======================================##
      • Keith Davies
        ... I m thinking more of logging dependencies between files. For instance, we could have (much data elided): wotc/core_rules/players_handbook/classes.xml:
        Message 3 of 8 , Aug 12, 2002
        • 0 Attachment
          On Fri, Aug 09, 2002 at 01:20:20PM -0500, Peter Kahle wrote:
          > On Fri, Aug 09, 2002 at 11:58:42AM -0400, adnd-pcgen@... wrote:
          > > On 9 Aug 2002 pcgen-xml@yahoogroups.com wrote:
          > > > Date: Thu, 8 Aug 2002 13:46:54 -0500
          > > > From: Peter Kahle <pkahle@...>
          > > >
          > Well, that's one way to do it, and probably the way to go in the end,
          > but for a first step, I was more thinking of creating something that
          > goes thru the .pccx file and calls loader functions for each type of
          > file (say we've got <class-lst file='playershbclass.lst' /> in the
          > .pccx file, or maybe <file type='class' href='playershbclass.lst' />.
          > For each class file it finds, it would call a method, say
          > loadClassesFromLST("playershbclass.lst") that would handle the actual
          > loading. Then, after we implement class functionality from an XML file,
          > we'd change it to <lstx file='playershbclass.lstx'/> or <file type='xml'
          > href='playershbclass.lstx'/> and it would instead call
          > loadFromXML("playershbclass.lstx"). Calling it this way seems like it
          > might provide better performance than parsing it all into one big tree
          > (though SAX might fix some of the problems, but I'm more familiar with
          > DOM, so that's what I'm thinking about.)


          I'm thinking more of logging dependencies between files. For instance,
          we could have (much data elided):

          wotc/core_rules/players_handbook/classes.xml:

          <pcgen>
          <!-- stuff -->
          <classes>
          <class id="class.barbarian"/>
          <class id="class.bard"/>
          <!-- more stuff -->
          </classes>
          </pcgen>


          custom/kjdavies/campaign.xml:

          <pcgen>
          <depends href="wotc/core_rules/players_handbook/classes.xml"/>
          <depends href="wotc/core_rules/players_handbook/equipment.xml"/>
          <depends href="wotc/core_rules/players_handbook/spells.xml"/>
          <!-- stuff - new definitions, classes, whatever -->
          </pcgen>


          During load, the system could follow dependencies while loading; if it
          finds a <depends> pointing to a file that hasn't been loaded yet, it
          gets loaded immediately. This has several effects:

          1. establishes relationships between files
          2. resolves current problem with unknown dependencies between files
          (the "why can't it find /x/?" problem).
          3. can be used to define rulesets/campaigns fairly easily. You'd get
          something like:

          <pcgen>
          <!-- lots of depends -->
          <!-- lots of <remove>s and/or <mod>s -->
          </pcgen>

          > Anyway, it's all up in the air, and can be done any number of ways,
          > we'll see what works as we try it out.

          yep.

          > Well, the pccx to pcc converter will be, but I already wrote a little
          > python script to do pcc to pccx conversion (slow day at work yesterday).
          > If it's possible to use XSLT to go from pcc to pccx somebody please let
          > me know, but I was under the impression it wasn't.

          It could be. I certainly won't volunteer. I'm not a huge fan on
          functional programming (never really got a handle on LISP) and there are
          a bunch of things I don't like about trying to use XSLT. I still *use*
          it, mind; it works okay for reasonably straight-forward transformations.
          More complex transformations, though, I often find easier to do with
          other tools, and converting other, arbitrary text to XML is almost
          always more easily done with something such as, say, Perl.


          Keith
          --
          Keith Davies
          keith.davies@...

          "I'm happy to do the tracker stuff since our Microsoft Poxy Server (that's
          poxy, not proxy) won't let me connect to sourcesafe's CVS..."
          -- Karianna, pcgen mailing list
        • Peter Kahle
          ... I believe we re saying pretty much the same thing, I m just beginning with a smaller step, using XML to pretty much directly replace the PCC and LST files
          Message 4 of 8 , Aug 12, 2002
          • 0 Attachment
            On Mon, Aug 12, 2002 at 08:24:58AM -0700, Keith Davies wrote:
            > On Fri, Aug 09, 2002 at 01:20:20PM -0500, Peter Kahle wrote:
            >
            > I'm thinking more of logging dependencies between files. For instance,
            > we could have (much data elided):
            >

            I believe we're saying pretty much the same thing, I'm just beginning
            with a smaller step, using XML to pretty much directly replace the PCC
            and LST files as they exist now. We end up in the same place, down the
            road.

            incidentally, how would you go about ordering the loading within a file?
            I was initially thinking you'd parse the whole of the file, generating a
            list of files to load as you go, then load those files sequentially
            afterwards, but now that you mention <mod> and <exclude> tags, I'm
            figuring generating some sort of list of actions from a DOM tree,
            disposing of the tree, then performing those actions in order would be
            the way to go, assuming the use of DOM at all (again, I don't really
            know SAX, and don't know how good it would be at this sort of thing. I'd
            guess pretty well, but I have some nagging questions about it.) This
            isn't particularly important at the moment, but I figured I'd ask.
            P

            --

            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://www.kahlilia.org/~pkahle/ ||
            ##===============================##======================================##
          • Keith Davies
            ... s would appear very early in the file -- they are used to link to other files, and would be useful for meta-information as well (such as
            Message 5 of 8 , Aug 12, 2002
            • 0 Attachment
              On Mon, Aug 12, 2002 at 03:09:38PM -0500, Peter Kahle wrote:
              > On Mon, Aug 12, 2002 at 08:24:58AM -0700, Keith Davies wrote:
              > > On Fri, Aug 09, 2002 at 01:20:20PM -0500, Peter Kahle wrote:
              > >
              > > I'm thinking more of logging dependencies between files. For instance,
              > > we could have (much data elided):
              > >
              >
              > I believe we're saying pretty much the same thing, I'm just beginning
              > with a smaller step, using XML to pretty much directly replace the PCC
              > and LST files as they exist now. We end up in the same place, down the
              > road.
              >
              > incidentally, how would you go about ordering the loading within a file?
              > I was initially thinking you'd parse the whole of the file, generating a
              > list of files to load as you go, then load those files sequentially
              > afterwards, but now that you mention <mod> and <exclude> tags, I'm
              > figuring generating some sort of list of actions from a DOM tree,
              > disposing of the tree, then performing those actions in order would be
              > the way to go, assuming the use of DOM at all (again, I don't really
              > know SAX, and don't know how good it would be at this sort of thing. I'd
              > guess pretty well, but I have some nagging questions about it.) This
              > isn't particularly important at the moment, but I figured I'd ask.


              <depend>s would appear very early in the file -- they are used to link
              to other files, and would be useful for meta-information as well (such
              as publishers, code monkeys, etc). When loading (and SAX could be used
              for this fairly nicely, btw), the algorithm would be something like:

              load_file( const std::string &filename) {
              // do loading stuff
              loaded_set.insert( filename);
              }

              on_start_element() {
              if ((element.name == "depend") &&
              (!loaded_set.find( element.attrib["href"])) {
              load_file( element.attrib[ "href"]);
              } else {
              // other processing
              }
              }


              Hope that makes sense... basically, load the identified file. If you
              find a <depend>, and you haven't already loaded that file, load that one
              *before* continuing. While a single file may depend on many, and many
              files may depend on a particular one (such as, say, the PHB), I don't
              expect the depth of the recursion to get too deep, and thus there
              shouldn't be any significant problem with file handles or the like.
              Each file gets loaded only once, and we can be certain that things like
              MODs and the like will actually find something to latch onto. It can
              also be really helpful for those trying to extract a subset (I might
              want to create a campaign file for my players to use -- all I have to do
              here is grab the particular pieces I want, and the program can walk the
              tree identifying and grabbing all files required). It can also be
              helpful in identifying what can be used -- if I don't have /Book X/, I
              could conceivably say "don't use anything that requires /X/" and reduce
              the tree. For instance, if I were to say "don't use SW PHB", all
              SW-related files would probably drop out. It also helps avoid the
              problem of game modes. Somewhat, at least.


              Keith
              --
              Keith Davies
              keith.davies@...

              "I'm happy to do the tracker stuff since our Microsoft Poxy Server (that's
              poxy, not proxy) won't let me connect to sourcesafe's CVS..."
              -- Karianna, pcgen mailing list
            • Peter Kahle
              ... Cool. Makes sense. I m going to do my homework on SAX before I ask any stupid questions about it. Though I will ask one stupid question about type
              Message 6 of 8 , Aug 12, 2002
              • 0 Attachment
                On Mon, Aug 12, 2002 at 02:33:58PM -0700, Keith Davies wrote:
                > On Mon, Aug 12, 2002 at 03:09:38PM -0500, Peter Kahle wrote:
                > > On Mon, Aug 12, 2002 at 08:24:58AM -0700, Keith Davies wrote:
                > > > On Fri, Aug 09, 2002 at 01:20:20PM -0500, Peter Kahle wrote:
                > > >
                > > > I'm thinking more of logging dependencies between files. For instance,
                > > > we could have (much data elided):
                > > >
                > >
                > > I believe we're saying pretty much the same thing, I'm just beginning
                > > with a smaller step, using XML to pretty much directly replace the PCC
                > > and LST files as they exist now. We end up in the same place, down the
                > > road.
                > >
                > > incidentally, how would you go about ordering the loading within a file?
                > > I was initially thinking you'd parse the whole of the file, generating a
                > > list of files to load as you go, then load those files sequentially
                > > afterwards, but now that you mention <mod> and <exclude> tags, I'm
                > > figuring generating some sort of list of actions from a DOM tree,
                > > disposing of the tree, then performing those actions in order would be
                > > the way to go, assuming the use of DOM at all (again, I don't really
                > > know SAX, and don't know how good it would be at this sort of thing. I'd
                > > guess pretty well, but I have some nagging questions about it.) This
                > > isn't particularly important at the moment, but I figured I'd ask.
                >
                >
                > <depend>s would appear very early in the file -- they are used to link
                > to other files, and would be useful for meta-information as well (such
                > as publishers, code monkeys, etc). When loading (and SAX could be used
                > for this fairly nicely, btw), the algorithm would be something like:
                >
                > load_file( const std::string &filename) {
                > // do loading stuff
                > loaded_set.insert( filename);
                > }
                >
                > on_start_element() {
                > if ((element.name == "depend") &&
                > (!loaded_set.find( element.attrib["href"])) {
                > load_file( element.attrib[ "href"]);
                > } else {
                > // other processing
                > }
                > }

                Cool. Makes sense. I'm going to do my homework on SAX before I ask any
                stupid questions about it.

                Though I will ask one stupid question about <mod> type tags. Since we've
                talked about using references for classes and the like, and since we'd
                be using unique identifiers for them (thus allowing both the PHB and
                the Monte Cook Ranger to be named "Ranger" if we desire) would a moded
                class have it's own unique identifier, and the use would say, roughly,
                "Use the base tag as the starting point, modify by whatever's in this
                tag, then make the base tag invisible/unselectable/whatever"? Kind
                of like inheritance. Or, maybe require an <exclude> tag to say
                to hide the original. So if I did a <class-mod ref='srd1.ranger'
                refid='my.ranger'>...</class-mod> without <exclude ref='srd1.ranger'/>,
                for example, two different Ranger classes would show up in the Classes
                list inside the program.

                Anyway, again, this stuff is a ways away, but I was thinking about it,
                so I figured I'd put it out there.

                Thanks,
                Peter

                --

                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://www.kahlilia.org/~pkahle/ ||
                ##===============================##======================================##
              • Keith Davies
                ... I haven t done much (anything, really) with DOM, but I have done some SAX. ... For the case you ve described, I don t know that I d use a MOD. There are
                Message 7 of 8 , Aug 12, 2002
                • 0 Attachment
                  On Mon, Aug 12, 2002 at 04:55:26PM -0500, Peter Kahle wrote:
                  >
                  > Cool. Makes sense. I'm going to do my homework on SAX before I ask any
                  > stupid questions about it.

                  I haven't done much (anything, really) with DOM, but I have done some
                  SAX.

                  > Though I will ask one stupid question about <mod> type tags. Since we've
                  > talked about using references for classes and the like, and since we'd
                  > be using unique identifiers for them (thus allowing both the PHB and
                  > the Monte Cook Ranger to be named "Ranger" if we desire) would a moded
                  > class have it's own unique identifier, and the use would say, roughly,
                  > "Use the base tag as the starting point, modify by whatever's in this
                  > tag, then make the base tag invisible/unselectable/whatever"? Kind
                  > of like inheritance. Or, maybe require an <exclude> tag to say
                  > to hide the original. So if I did a <class-mod ref='srd1.ranger'
                  > refid='my.ranger'>...</class-mod> without <exclude ref='srd1.ranger'/>,
                  > for example, two different Ranger classes would show up in the Classes
                  > list inside the program.

                  For the case you've described, I don't know that I'd use a MOD. There
                  are basically two or three cases to be handled.

                  1. minor change or extension of an existing element. For instance,
                  adding or changing some values, but the item is otherwise the same.
                  For instance, I give a +3 to those who take Skill Focus rather than
                  +2, so I might do:

                  custom/kjdavies/feats.xml:

                  <pcgen>
                  <depend href="wotc/core_rules/players_handbook/feats.xml"/>
                  <!-- stuff -->
                  <feats xmlns:feat="http://www.pcgen.org/schema/feat.dtd">
                  <mod featref="feat.skill-focus" xpath="effects/bonus/@value">+3</mod>
                  </feats>
                  </pcgen>

                  (code still rough...)

                  This says to grab the feat identified by 'feat.skill-focus', find the
                  bonus, and change its value from +2 to +3. This causes load order to
                  be quite significant, and is why I've got <depend>

                  2. Adding an element that is and should stay based on another:

                  malhavoc/classes/ranger.xml:

                  <pcgen>
                  <classes xmlns:class="http://www.pcgen.org/schema/class.dtd">
                  <class id="class.ranger.monte" baseclassref="class.ranger">
                  <name>Ranger (Monte's)</name>
                  <!-- differences -->
                  </class>
                  </classes>
                  </pcgen>

                  The above creates a new class that is based closely on the base
                  class, but has some differences. Both would be visible.

                  3. Element that replaces the other:

                  malhavoc/classes/ranger.xml:

                  <pcgen>
                  <classes xmlns:class="http://www.pcgen.org/schema/class.dtd">
                  <class id="class.ranger.monte" baseclassref="class.ranger">
                  <name>Ranger (Monte's)</name>
                  <!-- differences -->
                  </class>
                  <exclude classref="class.ranger"/>
                  </classes>
                  </pcgen>

                  When loading the above, it is expected that the values will be taken
                  from id("class.ranger"), then changes made. Bad example, I think,
                  because the classes aren't really all that similar IIRC. Anyway,
                  id("class.ranger") would be added to a delete list; when the end of
                  loading is reached, the IDs in the delete list will be removed.

                  Or something like that. I haven't put a lot of thought into exactly how
                  MODding will be done. Yet. I'm still thinking about more static
                  things.


                  Keith
                  --
                  Keith Davies
                  keith.davies@...

                  "I'm happy to do the tracker stuff since our Microsoft Poxy Server (that's
                  poxy, not proxy) won't let me connect to sourcesafe's CVS..."
                  -- Karianna, pcgen mailing list
                Your message has been successfully submitted and would be delivered to recipients shortly.