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

Getting back on track?

Expand Messages
  • Peter Kahle
    Hi Folks, 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. So I m
    Message 1 of 8 , Aug 8, 2002
    • 0 Attachment
      Hi Folks,
      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. 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'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)

      Anybody have any comments on this?
      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/ ||
      ##===============================##======================================##
    • 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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.