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

Re: [pcgen-xml] Re: Getting back on track?

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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.