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

Various Comments

Expand Messages
  • Stephen Gryphon
    1. Including the type in the name of elements Many examples have used a prefix in the name of elements describing the type, e.g. ... In all these examples the
    Message 1 of 10 , Aug 29, 2002
      1. Including the type in the name of elements

      Many examples have used a prefix in the name of elements describing the
      type, e.g.

      > <feat id="feat.weapon-specialization">
      > <prelevel classref="class.fighter" min="4"/>
      > <prereq type="skill" ref="skill.jump" min="10"/>
      > <prereq type="save" ref="save.fortitude" min="6"/>
      > <spell id="spell.fireball"/>

      In all these examples the prefix is redundant, when desribing a feat it
      simply does not make sense to have any type other than "feat.", e.g. <feat
      id="skill.jump"> is just plain silly. If anyone has a compelling case why
      the verbosity is required, please explain.

      > > <depends href="srd/phb.xml"/>
      > > <spells>
      > > <mod ref="spell.fireball">
      > > <range common="medium"/>
      > > </mod>
      > > </spells>

      Note that this is one example where it appears the name is required to be
      qualified, however in reality it is only possible for it to be a spell,
      because it is inside the spell block, i.e.
      <spells>
      <mod ref="class.fighter">...
      does not make sense as it is inside the <spells> block.


      2. Generic pre-requisite element, vs element per type

      > habit, probably. IIRC, LST files currently have specific tags for the
      > different types of prereqs and I carried it over. Also, I was
      > envisioning the different types of prerequisites as inherently
      > different, even if they were very similar. I wanted the option of
      > having different attribute lists and whatnot. I also have never cared
      > for having to examine members of an object to figure out
      > exactly what it

      My current draft of a suggeted schema (draft-gryphon-d20xml-d20ref-00.txt),
      available in the d20-xml Yahoo group files section (and the PCGEN CVS
      repository) has the generic pre-requisite approach, and also a generic bonus
      approach... HOWEVER my more recent work (not yet in the document) abandons
      this approach in favor of element per type for the reasons:

      (a) As above, when mapping to OO components you want a separate class per
      concept (to avoid switch statements). They would, of course, all be derived
      from a base type/interface. (In XML they could be part of a substitution
      group).

      (b) In general pre-reqs (and bonuses) need to be implemented within code. By
      making them part of the XML schema it provides better alignment between
      schema versions and code versions. Essentially when you add a new type of
      pre-requisite you need to both update the schema and write code to handle
      the new type -- otherwise, if the pre-req type is an attribute, then, you
      end up with valid XML, but where there may not be any code to handle it.


      3. On namespaces

      > Note that our work *will* make significant use of namespaces,
      > which I'm
      > largely ignoring in my examples. Generally, any grouping of
      > data found
      > in a pcgen file (the elements just below the root, not counting
      > <depend>s and other meta information) will have its own
      > namespace. The
      > formal definition above might be

      IMHO, the proliferation of namespaces suggested seemed a little excessive
      (separate namespace for feats, skills, etc). I would think that there are
      not many elements that are repeated between the different types, and that it
      would be simpler to code by using a single namespace (which would be the
      default).

      Note that some items, such as pre-reqs, may appear for both feats and
      (prestige-)classes, however in this case they would probably actually refer
      to the same thing and correspond to the same objects within a program.
      Similarly a <Name> element would probably just map to text, without having
      to distinguish types between a spell's <Name> and a skill's <Name>.

      One possible example that does come to mind is "size" which can apply in
      different contexts: creature size, weapon size, etc. I don't think that
      different tags (<CreatureSize> and <WeaponSize>), if necessary, would be too
      much trouble, and much easier than separate namespaces (i.e. <Creature:Size>
      and <Weapon:Size>, plus having to put Creature: and Weapon: in front of
      everything else).

      > <class id="class.ranger">
      > <class id="class.ranger.monte-cook">

      Note also that, although rarely done, namespaces can be applied to
      TOKENesque values through the QName type, for example the above may be
      better written as:
      <class id="srd:ranger">
      <class id="mc:ranger">

      You can then define the namespaces at the top of the XML document as
      normal --this means that, in another document, id="monte:ranger", would
      actually be the same ID (provide "monte" resolves to the same name space URI
      as "mc").

      - Sly
    • retarded_dm
      ... In my experience, using a . character in an XML attribute value can be an indication of a poorly-defined schema. For each of the above items, the value
      Message 2 of 10 , Aug 30, 2002
        > <feat id="feat.weapon-specialization">
        > <prelevel classref="class.fighter" min="4"/>
        > <prereq type="skill" ref="skill.jump" min="10"/>
        > <prereq type="save" ref="save.fortitude" min="6"/>
        > <spell id="spell.fireball"/>


        In my experience, using a "." character in an XML attribute value can
        be an indication of a poorly-defined schema.

        For each of the above items, the value before the "." is redundant.
        They could perhaps be better defined as:

        <feat id="weapon-specialization">
        ..<prereq type="class-level" ref="fighter" min="4" />
        </feat>
        <prereq type="skill" ref="jump" min="10" />
        <prereq type="save" ref="fortitude" min="6" />
        <spell id="fireball"/>
      • Keith Davies
        ... I could use *numbers* for all the program will care, but this is meant to be human readable. In PCGen right now, all IDs are the name strings and
        Message 3 of 10 , Aug 30, 2002
          On Fri, Aug 30, 2002 at 01:15:51PM +1000, Stephen Gryphon wrote:
          >
          > 1. Including the type in the name of elements
          >
          > Many examples have used a prefix in the name of elements describing the
          > type, e.g.
          >
          > > <feat id="feat.weapon-specialization">
          > > <prelevel classref="class.fighter" min="4"/>
          > > <prereq type="skill" ref="skill.jump" min="10"/>
          > > <prereq type="save" ref="save.fortitude" min="6"/>
          > > <spell id="spell.fireball"/>
          >
          > In all these examples the prefix is redundant, when desribing a feat it
          > simply does not make sense to have any type other than "feat.", e.g. <feat
          > id="skill.jump"> is just plain silly. If anyone has a compelling case why
          > the verbosity is required, please explain.

          <shrug> I could use *numbers* for all the program will care, but this is
          meant to be human readable. In PCGen right now, all IDs are the name
          strings and there have been conflicts and problems in the past. Now,
          this merely argues for the use of explicit and unchanging IDs instead of
          the labels used for names. However, these files are also meant to be
          human-readable -- while we plan to to have the program generate and
          modify the values, the software for that won't be ready until after
          people have started using the schema.

          I agree that the way the IDs are used above, there is redundancy -- that
          as long as the string used ('fighter', 'jump', 'fortitude') uniquely
          identifies the type of the object pointed at, and in the example above
          the element name or the type attribute identifies what it's pointing at,
          I don't want a human reader to rely on those indicators. I want to be
          able to look at an ID and know what it sort of thing it's pointing at.
          By prefacing the ID with a string identifying that type, I can determine
          this without having to examine it in context.

          The type preface has very little -- no -- meaning, really, other than as
          an indicator for the reader. It could be safely dropped if desired --
          if you want to do it differently in your own files, feel free. However,
          for the purposes of readability I find the prefaced form more useful and
          will, unless a better option comes along, be recommending it as a
          convention.

          heh. The original suggestion was even more verbose, and had other
          problems -- 'publisher.source.type.name'.

          > > > <depends href="srd/phb.xml"/>
          > > > <spells>
          > > > <mod ref="spell.fireball">
          > > > <range common="medium"/>
          > > > </mod>
          > > > </spells>
          >
          > Note that this is one example where it appears the name is required to be
          > qualified, however in reality it is only possible for it to be a spell,
          > because it is inside the spell block, i.e.
          > <spells>
          > <mod ref="class.fighter">...
          > does not make sense as it is inside the <spells> block.

          Yes, true.

          > 2. Generic pre-requisite element, vs element per type

          <snip>

          > (b) In general pre-reqs (and bonuses) need to be implemented within code. By
          > making them part of the XML schema it provides better alignment between
          > schema versions and code versions. Essentially when you add a new type of
          > pre-requisite you need to both update the schema and write code to handle
          > the new type -- otherwise, if the pre-req type is an attribute, then, you
          > end up with valid XML, but where there may not be any code to handle it.

          I've actually considered doing it this way simply to make it *harder*
          for ad hoc changes to be made. I've used (written) business systems
          that do that -- make things less flexible and convenient for the user in
          an effort to simplify the code[1], but mostly to require them to use it
          in a particular way[2].

          And, while I expect to use a validating parser, an unknown element type
          is a lot more dramatic -- a lot more likely to fail obviously -- than an
          unknown attribute value.

          In later consideration, though, I think the generic prereq structure can
          still work. I'm still thinking about it, though.

          [1] not always -- sometimes it's harder to do it this way
          [2] legislated, so it *had* to be done a certain way for legal reasons

          > 3. On namespaces
          >
          > IMHO, the proliferation of namespaces suggested seemed a little excessive
          > (separate namespace for feats, skills, etc). I would think that there are
          > not many elements that are repeated between the different types, and that it
          > would be simpler to code by using a single namespace (which would be the
          > default).

          My thinking so far has been that there are many element names that would
          likely be reused in different contexts -- or else, a fairly huge number
          of element names. For instance, people would use <feat> to define a
          feat, and the same element name to add it to a character sheet. As
          such, I wanted at least *something* to differentiate them, and rather
          than having <feat-def> and <feat>, sort of thing, using the single name
          would be easier for them.

          I think, now, that that's somewhat bogus. I think we could get by with
          two, and one of them would usually be defaulted. Thus:

          <pcgen xmlns="http://www.pcgen.org/schema/v1.0.0"
          xmlns:def="http://www.pcgen.org/schema/v1.0.0/def">

          <def:attributes>
          <def:attribute id="att.str" />
          <def:attribute id="att.dex" />
          <def:attribute id="att.con" />
          <def:attribute id="att.int" />
          <def:attribute id="att.wis" />
          <def:attribute id="att.cha" />
          </def:attributes>
          <def:feats>
          <def:feat id="feat.skill.focus" />
          </def:feats>
          <def:skills>
          <def:skill id="skill.jump"/>
          </def:skill>

          <def:characters>
          <def:character id="char.andrathomas">
          <attributes>
          <attribute ref="att.str" value="10"/>
          <attribute ref="att.dex" value="12"/>
          <attribute ref="att.con" value="8"/>
          <attribute ref="att.int" value="22"/>
          <attribute ref="att.wis" value="19"/>
          <attribute ref="att.cha" value="17"/>
          </attributes>
          <!-- ... -->
          </def:character>
          </def:characters>
          </pcgen>

          The reasoning here is that references to things will always be more
          common than their definitions, and used rather consistently. That is,
          that <attributes> always means the same thing when found *inside* a
          definition, but <def:attributes> is the other way of using that element
          name.

          > Note that some items, such as pre-reqs, may appear for both feats and
          > (prestige-)classes, however in this case they would probably actually refer
          > to the same thing and correspond to the same objects within a program.
          > Similarly a <Name> element would probably just map to text, without having
          > to distinguish types between a spell's <Name> and a skill's <Name>.

          yep, thus the change.

          > One possible example that does come to mind is "size" which can apply in
          > different contexts: creature size, weapon size, etc. I don't think that
          > different tags (<CreatureSize> and <WeaponSize>), if necessary, would be too
          > much trouble, and much easier than separate namespaces (i.e. <Creature:Size>
          > and <Weapon:Size>, plus having to put Creature: and Weapon: in front of
          > everything else).

          actually, weapon size and creature size use the same values so 'size'
          probably will be a single attribute. It's just that a 'large' weapon is
          a bunch smaller than a 'large' creature. I can live with it.

          > > <class id="class.ranger">
          > > <class id="class.ranger.monte-cook">
          >
          > Note also that, although rarely done, namespaces can be applied to
          > TOKENesque values through the QName type, for example the above may be
          > better written as:
          > <class id="srd:ranger">
          > <class id="mc:ranger">
          >
          > You can then define the namespaces at the top of the XML document as
          > normal --this means that, in another document, id="monte:ranger", would
          > actually be the same ID (provide "monte" resolves to the same name space URI
          > as "mc").

          That's a possibility. I'll consider it, but I'm not comfortable with
          IDs that change, even if only apparently. I'd really rather assign a
          single string to it that is *always* used, in total, rather than have
          'monte:ranger' and 'mc:ranger' -- two apparently different strings --
          referring to the same thing.

          Now, while I wouldn't do it that way, I probably *could* be talked into
          having the prefaces replaced with namespaces, so that instead of
          'class.ranger' we use 'class:ranger'. While this does contradict what I
          said above about wanting IDs to stay the same, always, it does still
          meet my requirement that I can determine the type of element by looking
          at the ID, if the ID is fully-qualified. I'm not *entirely* comfortable
          with it (yet), but I could probably be pursuaded.


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

          PCGen: <reaper/>, smartass
          "While information might or might not want to be free, it definitely
          doesn't want to live under a DRM" -- Jonas, on PCGen
        • Keith Davies
          ... Possibly, but I *want* the information presented by that prefix when I m reading the file. While the software doesn t need it -- as I said in another
          Message 4 of 10 , Aug 30, 2002
            On Fri, Aug 30, 2002 at 12:47:48PM +0000, retarded_dm wrote:
            > > <feat id="feat.weapon-specialization">
            > > <prelevel classref="class.fighter" min="4"/>
            > > <prereq type="skill" ref="skill.jump" min="10"/>
            > > <prereq type="save" ref="save.fortitude" min="6"/>
            > > <spell id="spell.fireball"/>
            >
            >
            > In my experience, using a "." character in an XML attribute value can
            > be an indication of a poorly-defined schema.
            >
            > For each of the above items, the value before the "." is redundant.
            > They could perhaps be better defined as:
            >
            > <feat id="weapon-specialization">
            > ..<prereq type="class-level" ref="fighter" min="4" />
            > </feat>
            > <prereq type="skill" ref="jump" min="10" />
            > <prereq type="save" ref="fortitude" min="6" />
            > <spell id="fireball"/>

            Possibly, but I *want* the information presented by that prefix when I'm
            reading the file. While the software doesn't need it -- as I said in
            another message, I could numbers for all the software cares -- having a
            convention of including that makes it much easier for people to make
            sense of.

            It's not going to cause that much more memory to be used (they get
            thrown away when the pointers are snapped on loading) during runtime,
            disks are big, cheap, and fast, and it makes life easier for humans
            reading the file. It also avoids the (potential, admittedly) problem of
            having two objects of different types having the same name.


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

            PCGen: <reaper/>, smartass
            "While information might or might not want to be free, it definitely
            doesn't want to live under a DRM" -- Jonas, on PCGen
          • CC Americas 1 Carstensen James
            ... Could something like this be valuable because we do have name redundancy in the list files right now. In some cases, people will only want one, but in
            Message 5 of 10 , Aug 30, 2002
              Keith Davies wrote:
              > heh. The original suggestion was even more verbose, and had other
              > problems -- 'publisher.source.type.name'.

              Could something like this be valuable because we do have name redundancy in the list files right now. In some cases, people will only want one, but in some cases both are available. For example, does "feat.shadow" refer to the WotC one or the T&T (???) one? Same with class.ranger - WotC or Monte?

              I was about to say that publisher /should/ be enough, though the tangent I'm about to go off on may show where that isn't the case.

              OA changes several of the PHB/SRD classes. Biggest is the monk, but some of the others (like ranger IIRC) change too. I assume that would be a mod, not a overwritten class. If that is the case, can a DM set up a campaign where both the PHB and PHB-base-OA-modded source are active? (BTW, I know OA isn't currently on the publisher approved to create list - I was just using it as an example of what a publisher could do.)

              What about cases like this - OA (which has a dependency on PHB and mods the ranger) in a game using Monte's ranger. Do the mods attempt to apply to Monte's ranger because the ref is "class.ranger"?

              I think we need to be careful, especially with all of the publishers out there who may be putting out books at the same time as other publishers and as such can't check for duplication, that we can deal with same-name same-type items.

              > <def:characters>
              > <def:character id="char.andrathomas">
              > <attributes>
              > <attribute ref="att.str" value="10"/>
              > <attribute ref="att.dex" value="12"/>
              > <attribute ref="att.con" value="8"/>
              > <attribute ref="att.int" value="22"/>
              > <attribute ref="att.wis" value="19"/>
              > <attribute ref="att.cha" value="17"/>
              > </attributes>
              > <!-- ... -->
              > </def:character>
              > </def:characters>
              > </pcgen>
              >
              >The reasoning here is that references to things will always be more
              >common than their definitions, and used rather consistently.

              Just as a side note, I know that while lots of people will be using the thousands of XML editors out there for every platform, some folks will be using vi/emacs/notepad/ultraedit/whatever. I bring that up to mention that making the most commonly used definitions longer introduces more keystrokes and more possible typos.

              Cheers,
              Blue

              P.S. Like I mentioned - I'm good at breaking things. You should of seen my toys* when I was young. 8) Don't take this as an attack in the slightest - hopefully it's constructive criticism. And please DO tell me "enough, give me a break".

              * Someone else once said something close to: "Unbreakable toys are great for breaking non-unbreakable toys".
            • Keith Davies
              ... In cases like this, I d probably either 1. merge the two definitions if they were substantively equivalent (that is, they did exactly the same thing as far
              Message 6 of 10 , Aug 30, 2002
                On Fri, Aug 30, 2002 at 04:02:35PM -0400, CC Americas 1 Carstensen James wrote:
                > Keith Davies wrote:
                > > heh. The original suggestion was even more verbose, and had other
                > > problems -- 'publisher.source.type.name'.
                >
                > Could something like this be valuable because we do have name redundancy
                > in the list files right now. In some cases, people will only want one,
                > but in some cases both are available. For example, does "feat.shadow"
                > refer to the WotC one or the T&T (???) one? Same with class.ranger -
                > WotC or Monte?

                In cases like this, I'd probably either
                1. merge the two definitions if they were substantively equivalent (that
                is, they did exactly the same thing as far as our model is concerned,
                which IIRC the Shadow feat does); this would cause both source
                documents to be listed as sources.
                2. create two different feats, give them different IDs (feat.shadow and
                feat.shadow.tnt); they'd both show up (if both files loaded, neither
                was excluded, etc.) and could be used. That they share a name really
                isn't relevent.

                > OA changes several of the PHB/SRD classes. Biggest is the monk, but
                > some of the others (like ranger IIRC) change too. I assume that would
                > be a mod, not a overwritten class. If that is the case, can a DM set
                > up a campaign where both the PHB and PHB-base-OA-modded source are
                > active? (BTW, I know OA isn't currently on the publisher approved to
                > create list - I was just using it as an example of what a publisher
                > could do.)

                The way I'm looking at it, Monk would either be overridden (the original
                behavior masked) or, perhaps better, another Monk class with the same
                name created that has the base behavior of the previous. For instance,
                we could have:

                PHB:

                <class id="class.monk">
                <name>Monk</name>
                <!-- ... stuff ... -->
                </class>

                FRCS:

                <class id="class.monk.fr" base-class="class.monk">
                <!-- changes -->
                </class>

                <mod ref="class.monk">
                <name>Monk (PHB)</name>
                </mod>

                OA:
                <class id="class.monk.oa" base-class="class.monk">
                <name>Monk</name>
                <!-- changes -->
                </class>

                <mod ref="class.monk">
                <name>Monk (PHB)</name>
                </mod>


                (I'd put some thought into changing the <class> to something else,
                because it behaves differently -- clones the base class then overrides
                items of the base class in the new one. OTOH, if 'base-class' exists
                only in this case, it could probably be used like this.

                > What about cases like this - OA (which has a dependency on PHB and mods
                > the ranger) in a game using Monte's ranger. Do the mods attempt to
                > apply to Monte's ranger because the ref is "class.ranger"?

                I was thinking about this last night, but in context of the sources.
                I'm considering how to extend <depend>s so substitutions can be made.
                For instance, in my options file I might have

                <source-key id="phb" ref="book.players-handbook"/>

                which could be replaced with

                <source-key id="phb" ref="book.players-handbook-2p"/>

                which is the second printing. There could be a master index that
                shows what sources are equivalent (phb, core 1, phb2, etc.), then the
                user can configure which he wants to use. In the data files, there
                could be:

                <depend ref="phb"/>
                <depend ref="dmg"/>

                and so on (IDs are much shorter than would normally be used, of course).
                A similar mechanism could be used for classes and the like.

                > I think we need to be careful, especially with all of the publishers
                > out there who may be putting out books at the same time as other
                > publishers and as such can't check for duplication, that we can deal
                > with same-name same-type items.

                Yep. So far we've been going with 'first come, first serve', and I see
                no real reason not to continue. From time to time there *may* be a
                collision, but it seems unlikely that that two sources will come out
                with items of the same type with the same name at the same time... and
                if it does happen, it'll be caught by our internal file review process
                before publication anyway.

                > > <def:characters>
                > > <def:character id="char.andrathomas">
                > > <attributes>
                > > <attribute ref="att.str" value="10"/>
                > > <attribute ref="att.dex" value="12"/>
                > > <attribute ref="att.con" value="8"/>
                > > <attribute ref="att.int" value="22"/>
                > > <attribute ref="att.wis" value="19"/>
                > > <attribute ref="att.cha" value="17"/>
                > > </attributes>
                > > <!-- ... -->
                > > </def:character>
                > > </def:characters>
                > > </pcgen>
                > >
                > >The reasoning here is that references to things will always be more
                > >common than their definitions, and used rather consistently.
                >
                > Just as a side note, I know that while lots of people will be using the
                > thousands of XML editors out there for every platform, some folks will
                > be using vi/emacs/notepad/ultraedit/whatever. I bring that up to
                > mention that making the most commonly used definitions longer introduces
                > more keystrokes and more possible typos.

                Of course. That's why the definitions have the namespace and the uses
                do not -- <def:feat> defines the feat and how it works (in the program),
                while <feat> is its use in something else, like a character or creature.

                > P.S. Like I mentioned - I'm good at breaking things. You should of
                > seen my toys* when I was young. 8) Don't take this as an attack in
                > the slightest - hopefully it's constructive criticism. And please DO
                > tell me "enough, give me a break".

                Sure. For now, though, you're stimulating good thoughts. Because of
                traffic over the last couple days I've been reworking certain aspects of
                the schema because of the questions raised, and it's becoming more
                flexible as we go. And simpler, in some ways, because instead of having
                to define so many types and whatnot I give the users/source producers
                ways to do it themselves. The generalization can also make the code
                simpler.

                So, all in all, it's a productive thing. Keep it up.

                > * Someone else once said something close to: "Unbreakable toys are
                > great for breaking non-unbreakable toys".

                I've got a five-year old and a one-year old (Happy Birthday Naomi!), so
                I know the truth of this one *way* too well.


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

                PCGen: <reaper/>, smartass
                "While information might or might not want to be free, it definitely
                doesn't want to live under a DRM" -- Jonas, on PCGen
              • CC Americas 1 Carstensen James
                ... Ooh, I like this. Cloning seems custom made for lots of uses, like many of the custom races in FR which are separate, but mostly the same. ... This I
                Message 7 of 10 , Aug 30, 2002
                  Keith wrote:
                  > The way I'm looking at it, Monk would either be overridden (the original
                  > behavior masked) or, perhaps better, another Monk class with the same
                  > name created that has the base behavior of the previous. For instance,
                  > we could have:
                  >
                  > [ examples deleted ]
                  >
                  > (I'd put some thought into changing the <class> to something else,
                  > because it behaves differently -- clones the base class then overrides
                  > items of the base class in the new one. OTOH, if 'base-class' exists
                  > only in this case, it could probably be used like this.

                  Ooh, I like this. Cloning seems custom made for lots of uses, like many of the custom races in FR which are separate, but mostly the same.

                  >I was thinking about this last night, but in context of the sources.
                  >I'm considering how to extend <depend>s so substitutions can be made.
                  >For instance, in my options file I might have
                  >
                  > <source-key id="phb" ref="book.players-handbook"/>
                  >
                  >which could be replaced with
                  >
                  > <source-key id="phb" ref="book.players-handbook-2p"/>
                  >
                  >which is the second printing. There could be a master index that
                  >shows what sources are equivalent (phb, core 1, phb2, etc.), then the
                  >user can configure which he wants to use. In the data files, there
                  >could be:
                  >
                  > <depend ref="phb"/>
                  > <depend ref="dmg"/>
                  >
                  >and so on (IDs are much shorter than would normally be used, of course).
                  >A similar mechanism could be used for classes and the like.

                  This I think fits.

                  I know you don't want multiple names for the same thing (the "monte:ranger" and "mc:ranger" from an earlier example), but I can see a use for it. Ponder this - if we give everything a FQID (fully qualified ID, heh) like "class.ranger.wotc.srd" and "class.ranger.monte.web", and then put in that equivalence list you mention above that "class.ranger" is the same as "class.ranger.wotc.srd", I think we can:

                  A) always have a unique way to describe anything. For example, the OA ranger mods effect class.ranger.wotc.srd, and will never touch class.ranger.monte.web, or a different class.ranger that the user has made custom.
                  B) we only have to worry about "which came first" in that equivalence list
                  C) we still have a short way to type it
                  D) work out cloning nicely still, and end up with "class.ranger.wotc.srd" and "class.ranger.wotc.oa".
                  E) eliminate conflicts with users who make their own "class.ranger" because they didn't read the docs, or didn't realize that dragon #299 (or other "obscure" reference they may have loaded) had a feat with an identical name to the one they were creating.

                  A&E are also important if you are doing things like loading sources that aren't part of the official distribution. I make a data set for my campaign, with a feat called "confidence" (feat.confidence), and later publisher X comes up with a confidence feat and since it's the first in the official distribution it gets the name "feat.confidence").

                  I'm not sure about "C". Need to let that sit for a bit.

                  Take a second to think about that suggestion, because I think I'm about to step on a sacred cow with my next. *moo*

                  If everything has a verifiable unique ID, then any dependence tags can just become recommendations.

                  Take this for example. The user *only* loads a custom campaign source. It has a modification to the class.monk.wotc.oa. So it loads the class.monk.wotc.oa (and nothing else from OA). That mentions a bunch of weapon proficiencies in that source, which also get loaded. class.monk.wotc.oa is a mod (or a clone & mod, depending on something) of the class.monk.wotc.srd, so that and dependencies (and only those) gets pulled up from the srd files.

                  This, of course, assumes that PCGen can go from id to determining data files, and that can't be a static mapping between program loads because sources may change, be added, etc. This is non-trivial from a coding perspective. 8)

                  > I've got a five-year old and a one-year old (Happy Birthday Naomi!), so
                  > I know the truth of this one *way* too well.

                  Congratulations. We're hoping to start "real soon now". *knocks on wood*

                  Cheers,
                  Blue
                • Keith Davies
                  ... heh heh, you said wood Sorry.... In the meantime, keep practicing! I skimmed your notes, it looks good -- very interesting, almost
                  Message 8 of 10 , Aug 30, 2002
                    On Fri, Aug 30, 2002 at 05:49:25PM -0400, CC Americas 1 Carstensen James wrote:
                    >
                    > > I've got a five-year old and a one-year old (Happy Birthday Naomi!), so
                    > > I know the truth of this one *way* too well.
                    >
                    > Congratulations. We're hoping to start "real soon now". *knocks on wood*

                    <butthead>heh heh, you said 'wood'</butthead>

                    Sorry.... In the meantime, keep practicing!


                    I skimmed your notes, it looks good -- very interesting, almost exciting
                    (but I'm not sure I'd want to have to implement that... [realization! I
                    think I see a way to reuse another mechanism, at least at the conceptual
                    level]).

                    I'll try to post something more intelligent (almost *anything* is more
                    intelligent than what I put above...) tonight.


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

                    PCGen: <reaper/>, smartass
                    "While information might or might not want to be free, it definitely
                    doesn't want to live under a DRM" -- Jonas, on PCGen
                  • CC Americas 1 Carstensen James
                    ... Like I said, implementing it would be non-trivial . 8) I don t know of the abilities of JDOM (or whatever the Code Monkey s go with), and they might do
                    Message 9 of 10 , Aug 30, 2002
                      > I skimmed your notes, it looks good -- very interesting, almost exciting
                      > (but I'm not sure I'd want to have to implement that... [realization! I
                      > think I see a way to reuse another mechanism, at least at the conceptual
                      > level]).

                      Like I said, implementing it would be "non-trivial". 8)

                      I don't know of the abilities of JDOM (or whatever the Code Monkey's go with), and they might do an end run around the entire problem. In not, one solution is to do it as a two-pass load. First pass builds a list of id vs. files, second loads what is needed. The id to file map can be discarded after sources are loaded. It does slow down loading sources, but hopefully that's not happening too often. If you wanted to keep it you could just do it at initial program load and assume that sources aren't changing while the program is open, but that slows program start, uses more memory (both of which are issues) and also means you need to constantly open and close PCGen to test changes in sources. Hmm, maybe writing out the map to a file along with a date/time stamp, and updating any sections where the base files are have a more recent modification time then listed in the map file, or there are new sources or sources deleted. That assumes Java gives you a good platform independent way to access modification times on files, which I don't know is true.

                      *shrug* I can see ways to implement it, and I'm sure those familiar with JAVA and JDOM may see more. Then the question comes up of if it is worth it.

                      Cheers,
                      Blue
                    • David
                      I tend to agree with this assessment. Although I wouldn t call it poorly defined, rather just redundant. I can tell by the tag that it is a feat. ;] dB
                      Message 10 of 10 , Oct 3, 2002
                        I tend to agree with this assessment. Although I wouldn't call it
                        poorly defined, rather just redundant. I can tell by the tag that it
                        is a feat. ;]

                        dB



                        --- In pcgen-xml@y..., "retarded_dm" <retarded_dm@y...> wrote:
                        > > <feat id="feat.weapon-specialization">
                        > > <prelevel classref="class.fighter" min="4"/>
                        > > <prereq type="skill" ref="skill.jump" min="10"/>
                        > > <prereq type="save" ref="save.fortitude" min="6"/>
                        > > <spell id="spell.fireball"/>
                        >
                        >
                        > In my experience, using a "." character in an XML attribute value
                        can
                        > be an indication of a poorly-defined schema.
                        >
                        > For each of the above items, the value before the "." is
                        redundant.
                        > They could perhaps be better defined as:
                        >
                        > <feat id="weapon-specialization">
                        > ..<prereq type="class-level" ref="fighter" min="4" />
                        > </feat>
                        > <prereq type="skill" ref="jump" min="10" />
                        > <prereq type="save" ref="fortitude" min="6" />
                        > <spell id="fireball"/>
                      Your message has been successfully submitted and would be delivered to recipients shortly.