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

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

Expand Messages
  • 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 1 of 8 , Aug 12 1:09 PM
      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 2 of 8 , Aug 12 2:33 PM
        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 3 of 8 , Aug 12 2:55 PM
          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 4 of 8 , Aug 12 3:50 PM
            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.