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

Nested Prerequisites (Was: Examples)

Expand Messages
  • Jenni A. Merrifield
    ... Is there any particular reason, with this *internal* data representation, to avoid using
    Message 1 of 29 , Apr 13, 2004
    • 0 Attachment
      <quote who="Frugal" when=" Tue, 6 Apr 2004 11:56:32 +0100 (BST)">
      > <quote who="Keith Davies">
      > > On Mon, Apr 05, 2004 at 02:41:20PM +0100, Frugal wrote:
      > > > > <prereq kind="mult" operand="1">
      > > > > <prereq kind="alignment" key="lawful.good"/>
      > > > > <prereq kind="alignment" key="lawful.neutral"/>
      > > > > <prereq kind="alignment" key="lawful.evil"/>
      > > > > </prereq>
      > > >
      > > > I had this as
      > > >
      > > > <prereq min='1' max='1'>
      > > > <prereq kind='alignment' key='lawful.good' /> <!-- align.lg -->
      > > > <prereq kind='alignment' key='lawful.neutral' /> <!-- align.ln -->
      > > > <prereq kind='alignment' key='lawful.evil' /> <!-- align.le -->
      > > > </prereq>
      > > >
      > > > Basically, any time they nest, they implicitly form a mult-kind of
      > > > prereq... that's one only one that makes sense. After that you just
      > > > have to indicate how many of the child prereqs must be satisfied.
      > >
      > > I am 'implicit-phobic' I have been bitten by implitic too many times to
      > > trust it (or anyone else implimentation of it) saying that I missed out
      > > the 'operator="="' attribute ;O)
      >

      Is there any particular reason, with this *internal* data representation,
      to avoid using traditional Boolean operators such as "AND", "OR", "XOR" and
      "NOT"? Using it, we could be quite sure of what prerequisites were being
      requested and their relationships to each other.

      Examples:

      <prereq kind="mult" operand="XOR">
      <!-- Any Lawful or true neutral -->
      <prereq kind="alignment" key="lawful.good"/>
      <prereq kind="alignment" key="lawful.neutral"/>
      <prereq kind="alignment" key="lawful.evil"/>
      <prereq kind="alignment" key="neutral.neutral"/>
      </prereq>
      <!-- XOR is the most accurate option here, though OR would also work here
      because no object should ever have more than one alignment anyway -->

      <prereq kind="mult" operand="AND">
      <prereq kind="alignment" key="lawful.good" />
      <prereq kind="mult" operand="OR">
      <prereq kind="feat" key="feat.eschew-materials" />
      <prereq kind="feat" key="feat.silent-spell" />
      </prereq>

      I recognize that many non-programmers get confused by Boolean logic
      (especially when doing searches because it contradicts standard language
      conventions - e.g., find boys AND girls) and so I wouldn't recommend Boolean
      logic for an *external* representation, but why not use it *internally*?

      > I'm not generally fond of implicit behavior... though in this case I see
      > it as something of an 'explicit implicit' -- it's part of the defined
      > behavior. Still, it doesn't *hurt* to say <prereq kind='mult'>, either.

      Can't you define both forms as valid? Full syntax requires kind="mult" but
      if kind is for some reason omitted then kind="mult" is assumed?

      Jenni


      --
      Jenni A. M. Merrifield (strawberry @ jamm . com)
      Software User Experience Professional
      Designing to Requirements and walking on Water is EASY. . .
      . . . So long as both are Frozen.
      --

      > -----Original Message-----
      > From: pcgen-xml@yahoogroups.com [mailto:pcgen-xml@yahoogroups.com]
      > Sent: Wednesday, April 07, 2004 2:34 AM
      > To: pcgen-xml@yahoogroups.com
      > Subject: [pcgen-xml] Digest Number 221
      >
      >
      > There are 5 messages in this issue.
      >
      > Topics in this digest:
      >
      > 1. Re: Examples
      > From: "Frugal" <frugal@...>
      > 2. RE: Examples
      > From: "Frugal" <frugal@...>
      > 3. Re: Examples
      > From: Keith Davies <keith.davies@...>
      > 4. Re: Examples
      > From: Keith Davies <keith.davies@...>
      > 5. RE: Examples
      > From: "Steven Bethard" <bediviere@...>
      >
      >
      > ________________________________________________________________________
      > ________________________________________________________________________
      >
      > Message: 1
      > Date: Tue, 6 Apr 2004 11:56:32 +0100 (BST)
      > From: "Frugal" <frugal@...>
      > Subject: Re: Examples
      >
      >
      > <quote who="Keith Davies">
      > > On Mon, Apr 05, 2004 at 02:41:20PM +0100, Frugal wrote:
      > > Looking this over, is this intended as a representation of a cooked form
      > > of the data (that is, after it's been loaded, how it might look in the
      > > program)? The XML itself could be very much simplified for use in data
      > > files and a translation between the two forms should not be particularly
      > > scary... and the XML you've described below would require a fair amount
      > > of sophistication for data entry.
      >
      > It is a representation of the cooked XML.
      >
      > When I first came up with a schema that converted the LST data into XML
      > everyone told me that we could not possibly use that system as it was too
      > system dependent. Are we now saying that the progression, rank, entity
      > structures are actually Java structures that we map the high level XML
      > onto? Or are we planning to map from high level XML to low level XML to
      > java structures? I am getting very confused about what people actually
      > want from this project.
      >
      > >> - I have not done any repetition on ranks other than usnig "all" as a
      > >> catch all. We could have something like <rank min="x" max="y"> to
      > >> indicate
      > >> all ranks between x and y, or put s formula on it with $rank as an
      > >> implicit variable <rank level="floor($rank/3)"> for "every 3 ranks
      > >> starting at level 3"
      > >
      > > I've hit this one a few times and considered several possibilities.
      > > Probably the simplest was to put min and max attributes on the effect,
      > > and a formula that resolves to 'non-zero' on levels it should apply (for
      > > instance, 'not($level % 3)' would trip on 3, 6, 9, ...).
      >
      > You are quite correct, not(x) will have far mroe effect than floor(x) ;O)
      >
      > If we have a formula we do not need 'min' and 'max'.
      >
      > "not($level % 3 == 0) && $level>6 && $level<20"
      >
      > >> <progression id="skill.balance">
      > >> <name>Balance</name>
      > >> <description>Long formatted description of balance skill text from
      > >> SRD</description>
      > >
      > > What about a short description, the one-liners as on feats and spells?
      > > I used the <desc> element to contain those, or 'brief' (in another piece
      > > of work I'm doing).
      >
      > Yeah, that works. Or even nest them:
      >
      > <description>
      > <brief>One line desc</brief>
      > <detailed><h3>Description</h3><p>This is the long desc</p></detailed>
      >
      > >> <source page="Skills1.rtf"></source>
      > >
      > > I had this as a set of attributes (source namespace) on the entity
      > > rather than a child element; style difference.
      >
      > It really make no difference.
      >
      > As a style question (and something I have just never "got"): Why use all
      > of the namespaces? None of them make sense without the others so shouldn't
      > they all be part of the same thing? Under what circumstances would a
      > namespace consisting of nothing but 4 attributes be useful? I can
      > understand the use of namespaces with things like Schema, XSLT, XSL-FO as
      > they are all encapsulating different things and each can be use
      > independently, or in conjunction with each other, but I can not see how
      > this works with the PCGen namespaces.
      >
      > >> <attributes>
      > >> <!-- Attributes are constants on an entity that are not numbers -->
      > >> <attribute key="armour.check.applies" value="true"/>
      > >> <attribute key="usable-untrained" value="true" />
      > >
      > > <attribute key='key.ability' value='stat.dex' />
      > >
      > >> </attributes>
      > >> <types>
      > >> <type>Dexterity</type>
      > >> </types>
      > >
      > > Descriptive type used for classification?
      >
      > I did it this way for a couple of reasons:
      >
      > I did not see the point in having a 'key.ability' attribute as the stat
      > bonus is explicitly encoded in the effects of the progression.
      >
      > I added the <type>Dexterity</type> so that the progression can be searched
      > and indexed. If all entities (and progressions) have a series of types
      > that describe them then we can search for all entities that have type
      > 'FEAT' and type 'FIGHTER', or type 'SKILL' and type 'Dexterity'. If we
      > have half of this information in object specific attributes then this
      > becomes more difficult.
      >
      > I have just noticed that all of the skills need <type>Skill</type> added
      > to them.
      >
      > >> <ranks>
      > >> <rank level="all">
      > >> <!-- All levels give a +1 rank -->
      > >> <effects>
      > >> <variable-bonus targetid="skill.balance.ranks" stacks="true"
      > >> value="1"/>
      > >> </effects>
      > >> </rank>
      > >> <rank level="1">
      > >> <!-- Level 1 give a stat bonus -->
      > >> <effects>
      > >> <variable-bonus targetid="skill.balance"
      > >> value="$skill.balance.ranks
      > >> + $skill.balance.ranks.bonus + $skill.balance.stat +
      > >> $skill.balance.misc + $skill.balance.synergy" />
      > >> <variable-bonus targetid="skill.balance.stat"
      > value="$stat.dex.mod"
      > >> />
      > >
      > > statmod($skill.balance.stat) instead, since it doesn't use Dex directly?
      >
      > I did not use this structure as it requires a statmod() function and the
      > ability to lookup from $skill.balance.stat to 'stat.dex' and from there to
      > an explicit number.
      >
      > I would much rather have a series of variables in the character object:
      >
      > stat.dex
      > stat.dex.mod
      >
      > and then a formula:
      >
      > <variable-bonus targtrid="stat.dex.mod" value="floor($stat.dex/2)-5"/>
      >
      > > Hmm... no, you're more or less doing that... but it looks like you need
      > > to be able to process the effects in arbitrary order.
      >
      > I am working on the assumption that the client can either set up
      > dependencies on the variables and calculate them in order, or the client
      > can set up a notification system such that variable 'a' is notified when
      > variable 'b' is changed.
      >
      > > You had this in <rank level='1'> in Balance, but in <rank level='all'>
      > > here. Was that on purpose?
      >
      > Nope, completely messed it up ;O)
      >
      > I had originally thought about putting the stat modifiers in the first
      > rank for skills that were not useable untrained and in 'all' for untrained
      > skills. After I sent it out I realised that 'all' was a really stupid
      > place to put it, and it should go in the top level <effects> rather than
      > under a rank so that if you have 0 ranks you still get the bonus...
      >
      > I am now undecided as to wether all the stat bonuses should go under the
      > top level <effects>, or if the untraned=no skills should have their stat
      > bonus under rank 1...
      >
      > >> <variable-bonus targetid="var.save.reflex.base"
      > >> value="ranks.class.fighter/2"/>
      > >
      > > Should be ranks.class.fighter/3, no? And need values for Fort and Will.
      >
      > Oh, more than likely. I was doing this off of the top of my head and
      > trying to remember the progressions rather than bothering to look them up
      > ;O)
      >
      > Yes, you are right, Fortitude and Willpower bonuses also need to go in
      > there
      >
      > >> <entity id="feat.toughness">
      > >> <name>Toughness</name>
      > >> <description>
      > >> <b>Benefit:</b>You gain +3 hit points.<br />
      > >> <b>Special:</b> A character may gain this feat multiple times. Its
      > >> effects stack.
      > >> </description>
      > >> <attributes>
      > >> <attribute key="allow.multiple" value="true"></attribute>
      > >> </attributes>
      > >> <types>
      > >> <type>feat</type>
      > >> <type>general</type>
      > >> </types>
      > >> <effects>
      > >> <variable-bonus targetid="hitpoints" value="3"/>
      > >> </effects>
      > >> </entity>
      > >
      > > Is it necessary to indicate that the feat stacks? Or is that the
      > > default?
      >
      > You are quite right, I put an 'allows-mutiples' attribute in, but I forgot
      > the 'multiples.stack' attribute.
      >
      > >> <entity id="item.dagger">
      > >> <name>Dagger</name>
      > >> <attributes>
      > >> <attribute key="wield" value="light"/>
      > >> <attribute key="default-size" value="m"/>
      > >> </attributes>
      > >> <types>
      > >> <type>item</type>
      > >> <type>weapon</type>
      > >> <type>melee</type>
      > >> <type>finesseable</type>
      > >> <type>ranged</type>
      > >> <type>thrown</type>
      > >> <type>simple</type>
      > >> <type>standard</type>
      > >> <type>piercing</type>
      > >> <type>slashing</type>
      > >> <type>dagger</type>
      > >> </types>
      > >> <effects>
      > >> <variable-bonus targetid="combat.to-hit.dagger.melee"
      > >> value="$combat.to-hit.melee + $combat.to-hit.dagger.melee.prof-penalty"
      > >> stacks="false"/>
      > >> <variable-bonus targetid="combat.to-hit.dagger.melee.prof-penalty"
      > >> value="-4" stacks="false">
      > >> <prereq kind="feat" key="feat.weapon-prof.dagger" operator="<"
      > >> operand="1"/>
      > >> </variable-bonus>
      > >> <variable-bonus targetid="combat.to-hit.dagger.ranged"
      > >> value="$combat.to-hit.ranged +
      > >> $combat.to-hit.dagger.ranged.prof-penalty" stacks="false"/>
      > >> <variable-bonus targetid="combat.to-hit.dagger.ranged.prof-penalty"
      > >> value="-4" stacks="false">
      > >> <prereq kind="feat" key="feat.weapon-prof.dagger" operator="<"
      > >> operand="1"/>
      > >> </variable-bonus>
      > >> <variable-bonus targetid="item.dagger.range-increment" value="10"/>
      > >> <variable-bonus targetid="item.dagger.critmult" value="2"/>
      > >> <variable-bonus targetid="item.dagger.critrange" value="2" />
      > >> <variable-bonus targetid="item.dagger.damage.die-size" value="4" />
      > >> <variable-bonus targetid="item.dagger.damage.die-count" value="1"/>
      > >> <variable-bonus targetid="item.dagger.range" value="10"/>
      > >> <variable-bonus targetid="item.dagger.weight" value="1"/>
      > >> <variable-bonus targetid="item.dagger.cost" value="2"/>
      > >> <add-entity refid="eqmod.steel"/>
      > >> </effects>
      > >> </entity>
      > >
      > > The variable-bonus... does it apply to the entity being described, or to
      > > the character/entity it is being applied to? With a feat, it looks like
      > > it gets applied to the character, but with the dagger it... looks like
      > > it gets applied to the character, but should actually be describing the
      > > dagger. This is unclear to me.
      >
      > I am working on everything apliying to the character. I guess it is the
      > difference between asking the character "how much damage do you do with a
      > dagger" and asking the dagger: "how much damage to you do when weilded by
      > the character". this is why all of the variables are prefexed with the
      > item id.
      >
      > If you wanted to give a feat that increased the damage dice to a d6 rather
      > than a d4 you would apply this to the character:
      >
      > <variable-bonus targetid="item.dagger.damage.die-size" value="2"
      > stacks="true"/>
      >
      > or
      >
      > <variable-bonus targetid="item.dagger.damage.die-size" value="6"
      > stacks="false"/>
      >
      >
      > > Also, 'variable-bonus' looks deceptive. Is it a bonus to the 'real'
      > > value of the variable (in which case there are rules about how they
      > > stack, etc.) or is it a direct modification of the real value?
      >
      > It is a modification to the variable. I guess it is badly named, it should
      > be named something like: <variable-modification>.
      >
      > I would say that the rules on <variable-modification> are:
      >
      > - If (there are any modifications that have replaces="true")
      > then use the highest one
      > else
      > Take the highest modification that does not have
      > stacks="true" or replaces="true".
      > - add all of the modifications that have stacks="true"
      >
      >
      >
      > > Is this intended to be an 'intermediate form' (for instance, how it
      > > might look after being loaded? The XML itself can probably be very much
      > > simplified and the data translated to this form automatically without a
      > > lot of scariness from a simpler form, something like
      > >
      > > <equipment id='item.dagger'>
      > > <name>Dagger</name>
      > > <types>
      > > <type>item</type>
      > > <type>weapon</type>
      > > <type>melee</type>
      > > <type>dagger</type>
      > > <type>standard</type>
      > > </types>
      > > <effects /> <!-- how it changes the character goes here -->
      > > <physical-info size='medium' weight='2' cost='2' />
      > > <weapon-info>
      > > <usage light='yes' finesseable='yes' ranged='thrown' />
      > > <damage roll='1d4' critmult='2' critrange='2'>
      > > <type>piercing</type>
      > > <type>slashing</type>
      > > </damage>
      > > <ranged range-increment='10' max-increments='5' />
      > > </weapon-info>
      > > </equipment>
      >
      > as I said at the top of this email: I did not do any kind of high level
      > XML as everytime I have suggested it over ht epast year someone has shot
      > me down.
      >
      >
      > > <!-- not sure how to indicate that it's made of steel, though your
      > > '<add-entity refid="eqmod.steel" />' seems likely. I didn't include
      > > it because it *looks* like it's supposed to be added to the character
      > > who receives the dagger.
      >
      > This is the part where my "everything applies to the character" system
      > falls apart ;O(
      >
      > > Proficiency is better determined and indicated by feats and class
      > > abilities, not the item itself, I think. This may also be subject to
      > > reclassification in different campaigns.
      > >
      > > <type>simple</type>
      >
      > I put the proficiency bonuses in the item because I did not want to go
      > down the road of having to lookup bonuses from unrelated things.
      >
      > I guess that you can have a dagger.prof variable made up of the highest of
      > weaponprof.dagger bonus, weaponprof.martial bonus and weaponprof.dagger
      > bonus.
      >
      > >> <prereq kind="mult" operand="1">
      > >> <prereq kind="alignment" key="lawful.good"/>
      > >> <prereq kind="alignment" key="lawful.neutral"/>
      > >> <prereq kind="alignment" key="lawful.evil"/>
      > >> </prereq>
      > >
      > > I had this as
      > >
      > > <prereq min='1' max='1'>
      > > <prereq kind='alignment' key='lawful.good' /> <!-- align.lg -->
      > > <prereq kind='alignment' key='lawful.neutral' /> <!-- align.ln -->
      > > <prereq kind='alignment' key='lawful.evil' /> <!-- align.le -->
      > > </prereq>
      > >
      > > Basically, any time they nest, they implicitly form a mult-kind of
      > > prereq... that's one only one that makes sense. After that you just
      > > have to indicate how many of the child prereqs must be satisfied.
      >
      > I am 'implicit-phobic' I have been bitten by implitic too many times to
      > trust it (or anyone else implimentation of it) saying that I missed out
      > the 'operator="="' attribute ;O)
      >
      > Having used my prereq syntax in the current version of PCGen I know that
      > it copes with all cases without needed other syntax.
      >
      > >> <ranks>
      > >> <rank level="1">
      > >> <effects>
      > >> <add-entity refid="sa.literacy"/>
      > >> <add-entity refid="skill.balance"/>
      > >
      > > Add 'skill.balance' to the character? As a class skill, you mean? This
      > > isn't entirely clear to me.
      >
      > Yes. It isn't entirly clear to me now that I reread it. We are back to
      > skills being a pain to implement.
      >
      > >> <add-entity refid="feat.weapon-prof" choice="club"/>
      > >
      > > I'd put these in a separate list ('monk weapon proficiencies') outside
      > > the class and add them later, something like an 'invisible feat' as
      > > they're currently used.
      >
      > Again, purely a style issue.
      >
      > > I would instead create a 'monk unarmed combat' progression that lives
      > > outside the monk class. The monk class adds a rank in that progression
      > > at each of its own ranks... then other classes can also do the same (a
      > > monk-based prestige class could then say 'unarmed combat stacks with
      > > that from monk' very easily).
      >
      > After I sent out the email I realised that doing the unarmed combat as a
      > progression would be easier.
      >
      > the one thing I have not figured out how to do is replace the progression
      > with a completely different one. Some of the complex monk classes/feats
      > allow you to "use one size larger for unarmed damage", "use 1 size smaller
      > for damage", "use this other progression for unarmed damage".
      >
      > > Incidentally, I would do the same with
      > > spellcasters; each level of wizard adds one level of 'wizard
      > > spellcasting', which in turn adds 'one level of wizard spells per day';
      > > each level of sorcerer adds one level of 'sorcerer spellcasting', which
      > > in turn adds a rank each of 'sorcerer spells per day' and 'sorcerer
      > > spells known'.
      >
      > That would make spellcasting prestige classes a lot easier.
      >
      > --
      > regards,
      > Frugal
      > -OS Chimp
      >
      >
      > ________________________________________________________________________
      > ________________________________________________________________________
      >
      > Message: 2
      > Date: Tue, 6 Apr 2004 12:34:40 +0100 (BST)
      > From: "Frugal" <frugal@...>
      > Subject: RE: Examples
      >
      >
      > <quote who="Steven Bethard">
      > > Some questions (hopefully I'm not repeating anything Keith asked):
      > >
      > > Why does the stat bonus occur at rank 1? Shouldn't it be assigned at
      > rank
      > > 0
      > > of a skill (so that a character with no ranks in Balance still gets
      > their
      > > stat adjustment)?
      >
      > Ermmm. Good, you passed the test, move along now, nothing to see here ;O)
      >
      > It should be a child of the progression/effects rather than
      > progression/ranks/rank/effects
      >
      > > How do we deal with synergy bonuses for things like Diplomacy? From the
      > > RSRD:
      > > "Synergy: If you have 5 or more ranks in Bluff, Knowledge (nobility and
      > > royalty), or Sense Motive, you get a +2 bonus on Diplomacy checks"
      > > I read this as a boolean OR, such that if you have 5 ranks in Bluff and
      > 5
      > > ranks in Sense Motive, you still only get a +2 Synergy bonus to
      > Diplomacy.
      > > Regardless of whether my reading is right or wrong :), can we support
      > > something like this?
      >
      > Unfortunately the SRD authors did not right everything in pseudocode, if
      > they had our life would be a lot easier. I believe that this has been
      > FAQed to state that this in fact uses the other english usage of 'or'. You
      > get the synergy bonuses for each and every skill with 5 ranks.
      >
      > In any case we can handle both cases:
      >
      > Do not stack:
      >
      > <variable-modification targetid="skill.diplomacy.synergy"
      > stacks="false"
      > value="2">
      > <prereq kind="var" key="skill.bluff.ranks" operand="5"
      > operator=">="/>
      > </variable-modification>
      > <variable-modification targetid="skill.diplomacy.synergy"
      > stacks="false"
      > value="2">
      > <prereq kind="var" key="skill.sense-motive.ranks" operand="5"
      > operator=">="/>
      > </variable-modification>
      >
      > Do Stack:
      >
      > <variable-modification targetid="skill.diplomacy.synergy"
      > stacks="true"
      > value="2">
      > <prereq kind="var" key="skill.bluff.ranks" operand="5"
      > operator=">="/>
      > </variable-modification>
      > <variable-modification targetid="skill.diplomacy.synergy"
      > stacks="true"
      > value="2">
      > <prereq kind="var" key="skill.sense-motive.ranks" operand="5"
      > operator=">="/>
      > </variable-modification>
      >
      >
      > The only difference is the 'stacks="true"' or 'stacks="false"'.
      >
      >
      > > Just to clarify, but this means a player chooses a Race at each level,
      > > right? I assume this is to make monster levels/classes simpler...
      >
      > Correct.
      >
      > > Also, is there a reason why you used 'value="-3"' here instead of
      > > 'replaces="true" value="1"'?
      >
      > absolutely none, it is just a style thing. I wanted to show that you can
      > do things either way.
      >
      > >> <progression id="race.human">
      > >> ...
      > >> <add-entity type="feat" />
      > >> ...
      > >> </progression>
      > >> ...
      > >> <progression id="characterlevel">
      > >> ...
      > >> <add-rank type="class"/>
      > >> ...
      > >> </progression>
      > >
      > > Is the assumption with 'type' that any time it selects more than one
      > item
      > > the user must make a choice? If this is the case, to specify that the
      > > user
      > > gets all the feats of a certain type, we would have to enumerate them
      > all
      > > in
      > > <add-entity />s, which might be annoying for the weapon-proficiency
      > > feats...
      >
      > The assumption is that with <add-rank type="class"/> the client will look
      > for all progressions with a <type>class</type> child element and ask the
      > user to choose one. Likewise <add-entity type="feat" /> will look for all
      > entitiess with a <type>feat</type>.
      >
      > I imagine that <add-entity type="feat,fighter"/> will look for all
      > entities with a type of 'feat' && a type of 'fighter'.
      >
      > I guess we do need some way to add more than one entity at a time.
      >
      > <add-entity type="feat,weapon-prof,martial" count="all"/>
      >
      > to add all entities that have the 'feat', 'weapon-prof' and 'martial'
      > types.
      >
      > <add-entity type="feat,meta-magic" count="2"/>
      >
      > To add any 2 meta-magic feats.
      >
      > >> <variable-bonus targetid="combat.to-hit.dagger.melee.prof-penalty"
      > >> value="-4"
      > >> stacks="false">
      > >> <prereq kind="feat"
      > >> key="feat.weapon-prof.dagger"
      > >> operator="<"
      > >> operand="1"/>
      > >> </variable-bonus>
      > >> <variable-bonus targetid="combat.to-hit.dagger.ranged"
      > >> value="$combat.to-hit.ranged +
      > >> $combat.to-hit.dagger.ranged.prof-penalty"
      > >> stacks="false"/>
      > >
      > > This reads a little weird to me. Is the prereq for the variable-bonus
      > to
      > > apply, or not to apply?
      >
      > the prereq says: if you do not have the dagger proficiency then the
      > prof-penalty is -4. I now realise that I forgot to put the replaces="true"
      > tag in the variable-bonus.
      >
      > > If it's for it to apply, should the prof-penalty
      > > be
      > > subtracted from the second variable-bonus value instead of added?
      >
      > No, because the prof-penalty is either '0' or '-4'.
      >
      > > How do you intend this to be handled? That is, how do we know how to
      > > check
      > > "wield"? I can see how to check entity presence and variable values
      > based
      > > on the data descriptions so far. Can this be done with "wield" too, or
      > is
      > > this one of the things we'll have to leave to program logic?
      >
      > All of the prerequisites will need to be done in code, even the variable
      > ones.
      >
      > --
      > regards,
      > Frugal
      > -OS Chimp
      >
      >
      > ________________________________________________________________________
      > ________________________________________________________________________
      >
      > Message: 3
      > Date: Tue, 06 Apr 2004 08:36:57 -0700
      > From: Keith Davies <keith.davies@...>
      > Subject: Re: Examples
      >
      > On Tue, Apr 06, 2004 at 11:56:32AM +0100, Frugal wrote:
      > >
      > > <quote who="Keith Davies">
      > > > On Mon, Apr 05, 2004 at 02:41:20PM +0100, Frugal wrote:
      > > > Looking this over, is this intended as a representation of a cooked
      > form
      > > > of the data (that is, after it's been loaded, how it might look in the
      > > > program)? The XML itself could be very much simplified for use in
      > data
      > > > files and a translation between the two forms should not be
      > particularly
      > > > scary... and the XML you've described below would require a fair
      > amount
      > > > of sophistication for data entry.
      > >
      > > It is a representation of the cooked XML.
      >
      > Ah, okay.
      >
      > > When I first came up with a schema that converted the LST data into XML
      > > everyone told me that we could not possibly use that system as it was
      > too
      > > system dependent. Are we now saying that the progression, rank, entity
      > > structures are actually Java structures that we map the high level XML
      > > onto? Or are we planning to map from high level XML to low level XML to
      > > java structures? I am getting very confused about what people actually
      > > want from this project.
      >
      > I think rank, entity, and progression are abstractions well-suited to
      > representing RPG information. I think it's a difference in levels of
      > interpretation -- in my XML I say that particular things *are* entities
      > or progressions; in your intermediate form they have been rendered *as*
      > entities and progressions.
      >
      > Does that make sense? I hope so; I was up late last night.
      >
      > > > I've hit this one a few times and considered several possibilities.
      > > > Probably the simplest was to put min and max attributes on the effect,
      > > > and a formula that resolves to 'non-zero' on levels it should apply
      > (for
      > > > instance, 'not($level % 3)' would trip on 3, 6, 9, ...).
      > >
      > > You are quite correct, not(x) will have far mroe effect than
      > floor(x) ;O)
      > >
      > > If we have a formula we do not need 'min' and 'max'.
      > >
      > > "not($level % 3 == 0) && $level>6 && $level<20"
      > >
      > > >> <progression id="skill.balance">
      > > >> <name>Balance</name>
      > > >> <description>Long formatted description of balance skill text from
      > > >> SRD</description>
      > > >
      > > > What about a short description, the one-liners as on feats and spells?
      > > > I used the <desc> element to contain those, or 'brief' (in another
      > piece
      > > > of work I'm doing).
      > >
      > > Yeah, that works. Or even nest them:
      > >
      > > <description>
      > > <brief>One line desc</brief>
      > > <detailed><h3>Description</h3><p>This is the long desc</p></detailed>
      >
      > Don't embed specific headings in it like this, I think. I can't think
      > of *too* many cases where entities will be complex enough to have their
      > own headings. The few that do would probably be better off with a more
      > generic <h> -- that can be picked up and formatted as needed for
      > whatever level it appears at. For instance, if we were dumping
      > everything to HTML and each class gets its own page, we might make them
      > <h2> (<h3> for nested ones); if they all go on a single page, they might
      > be <h3> or <h4> (with corresponding values for nested ones).
      >
      > > >> <source page="Skills1.rtf"></source>
      > > >
      > > > I had this as a set of attributes (source namespace) on the entity
      > > > rather than a child element; style difference.
      > >
      > > It really make no difference.
      > >
      > > As a style question (and something I have just never "got"): Why use
      > > all of the namespaces? None of them make sense without the others so
      > > shouldn't they all be part of the same thing? Under what circumstances
      > > would a namespace consisting of nothing but 4 attributes be useful? I
      > > can understand the use of namespaces with things like Schema, XSLT,
      > > XSL-FO as they are all encapsulating different things and each can be
      > > use independently, or in conjunction with each other, but I can not
      > > see how this works with the PCGen namespaces.
      >
      > Different levels of abstraction, plus shared behavior. The meta
      > namespace describes the structure of game entities and related
      > information. It is used by the engine so it knows how to map the XML to
      > the internal representation. A namespace for each rule set makes it
      > explicit what rules are being loaded and how to map them -- and clears
      > the way to having different games using the same element names (not
      > loaded at the same time, probably -- though there'd be nothing making it
      > impossible, I think it'd be way more trouble than it's worth). For
      > instance, d20 <skill> and Hero <skill> look different, etc. Without
      > using namespaces for this, we'll end up with <d20skill> and <heroskill>,
      > or some ungodly creation that tries to merge the behavior for both.
      > Source has common behavior regardless of game or system; it's not
      > metadata (in the sense that it doesn't describe the structure of the
      > data being manipulated), but it is data about where entity manipulation
      > being read came from. It's not part of d20, it's not part of Hero, but
      > it can reasonably be used by both.
      >
      > Namespaces are still useful and appropriate IMO, in other words.
      >
      > > >> <attributes>
      > > >> <!-- Attributes are constants on an entity that are not numbers --
      > >
      > > >> <attribute key="armour.check.applies" value="true"/>
      > > >> <attribute key="usable-untrained" value="true" />
      > > >
      > > > <attribute key='key.ability' value='stat.dex' />
      > > >
      > > >> </attributes>
      > > >> <types>
      > > >> <type>Dexterity</type>
      > > >> </types>
      > > >
      > > > Descriptive type used for classification?
      > >
      > > I did it this way for a couple of reasons:
      > >
      > > I did not see the point in having a 'key.ability' attribute as the stat
      > > bonus is explicitly encoded in the effects of the progression.
      >
      > We still present it, don't we? While functionally you are correct, I
      > think there are expectations that it be easily presented.
      >
      > > I added the <type>Dexterity</type> so that the progression can be
      > > searched and indexed. If all entities (and progressions) have a series
      > > of types that describe them then we can search for all entities that
      > > have type 'FEAT' and type 'FIGHTER', or type 'SKILL' and type
      > > 'Dexterity'. If we have half of this information in object specific
      > > attributes then this becomes more difficult.
      >
      > I was really hoping to get away from TYPE, but even so this is a better
      > representation than the current concatenated string... and it might not
      > be visible in data since this is an internal representation.
      >
      > > I have just noticed that all of the skills need <type>Skill</type> added
      > > to them.
      > >
      > > >> <ranks>
      > > >> <rank level="all">
      > > >> <!-- All levels give a +1 rank -->
      > > >> <effects>
      > > >> <variable-bonus targetid="skill.balance.ranks" stacks="true"
      > > >> value="1"/>
      > > >> </effects>
      > > >> </rank>
      > > >> <rank level="1">
      > > >> <!-- Level 1 give a stat bonus -->
      > > >> <effects>
      > > >> <variable-bonus targetid="skill.balance"
      > > >> value="$skill.balance.ranks
      > > >> + $skill.balance.ranks.bonus + $skill.balance.stat +
      > > >> $skill.balance.misc + $skill.balance.synergy" />
      > > >> <variable-bonus targetid="skill.balance.stat"
      > value="$stat.dex.mod"
      > > >> />
      > > >
      > > > statmod($skill.balance.stat) instead, since it doesn't use Dex
      > directly?
      > >
      > > I did not use this structure as it requires a statmod() function and the
      > > ability to lookup from $skill.balance.stat to 'stat.dex' and from there
      > to
      > > an explicit number.
      > >
      > > I would much rather have a series of variables in the character object:
      > >
      > > stat.dex
      > > stat.dex.mod
      > >
      > > and then a formula:
      > >
      > > <variable-bonus targtrid="stat.dex.mod" value="floor($stat.dex/2)-5"/>
      >
      > That's not a bonus, though, that's a calculation. If it were to be done
      > that way, I'd rather see something like
      >
      > <variable key='stat.dex' />
      > <function key='stat.dex.mod' calc='floor($stat.dex/2)-5' />
      >
      > > > Hmm... no, you're more or less doing that... but it looks like you
      > need
      > > > to be able to process the effects in arbitrary order.
      > >
      > > I am working on the assumption that the client can either set up
      > > dependencies on the variables and calculate them in order, or the client
      > > can set up a notification system such that variable 'a' is notified when
      > > variable 'b' is changed.
      >
      > That can be done.
      >
      > > > You had this in <rank level='1'> in Balance, but in <rank level='all'>
      > > > here. Was that on purpose?
      > >
      > > Nope, completely messed it up ;O)
      > >
      > > I had originally thought about putting the stat modifiers in the first
      > > rank for skills that were not useable untrained and in 'all' for
      > > untrained skills. After I sent it out I realised that 'all' was a
      > > really stupid place to put it, and it should go in the top level
      > > <effects> rather than under a rank so that if you have 0 ranks you
      > > still get the bonus...
      >
      > I'd figured <effects> would only happen when it got applied. Untrained
      > would never see it anyway.
      >
      > > I am now undecided as to wether all the stat bonuses should go under
      > > the top level <effects>, or if the untraned=no skills should have
      > > their stat bonus under rank 1...
      >
      > Mmm... I can see why you're doing this for skills -- in order to present
      > a character's total bonus to the roll for each skill you need to know
      > about both the character and every skill you want the roll bonus for.
      > It seems to depart from the normal model, though; feats don't have
      > effect unless they're applied to the character, classes don't have
      > effect unless they're applied to the character, etc. Making skills
      > behave differently here adds complication, I think, that isn't quite
      > needed.
      >
      > > >> <variable-bonus targetid="var.save.reflex.base"
      > > >> value="ranks.class.fighter/2"/>
      > > >
      > > > Should be ranks.class.fighter/3, no? And need values for Fort and
      > Will.
      > >
      > > Oh, more than likely. I was doing this off of the top of my head and
      > > trying to remember the progressions rather than bothering to look them
      > up
      > > ;O)
      > >
      > > Yes, you are right, Fortitude and Willpower bonuses also need to go in
      > there
      > >
      > Fair enough; I know I elide things (don't put in all saves, etc.) and
      > make mistakes on what I do put in. It's enough to show the structure, I
      > just wanted to check.
      >
      > > >> <entity id="item.dagger">
      > > >> <name>Dagger</name>
      > > >> <attributes>
      > > >> <attribute key="wield" value="light"/>
      > > >> <attribute key="default-size" value="m"/>
      > > >> </attributes>
      > > >> <types>
      > > >> <type>item</type>
      > > >> <type>weapon</type>
      > > >> <type>melee</type>
      > > >> <type>finesseable</type>
      > > >> <type>ranged</type>
      > > >> <type>thrown</type>
      > > >> <type>simple</type>
      > > >> <type>standard</type>
      > > >> <type>piercing</type>
      > > >> <type>slashing</type>
      > > >> <type>dagger</type>
      > > >> </types>
      > > >> <effects>
      > > >> <variable-bonus targetid="combat.to-hit.dagger.melee"
      > > >> value="$combat.to-hit.melee + $combat.to-hit.dagger.melee.prof-
      > penalty"
      > > >> stacks="false"/>
      > > >> <variable-bonus targetid="combat.to-hit.dagger.melee.prof-penalty"
      > > >> value="-4" stacks="false">
      > > >> <prereq kind="feat" key="feat.weapon-prof.dagger" operator="<"
      > > >> operand="1"/>
      > > >> </variable-bonus>
      > > >> <variable-bonus targetid="combat.to-hit.dagger.ranged"
      > > >> value="$combat.to-hit.ranged +
      > > >> $combat.to-hit.dagger.ranged.prof-penalty" stacks="false"/>
      > > >> <variable-bonus targetid="combat.to-hit.dagger.ranged.prof-
      > penalty"
      > > >> value="-4" stacks="false">
      > > >> <prereq kind="feat" key="feat.weapon-prof.dagger" operator="<"
      > > >> operand="1"/>
      > > >> </variable-bonus>
      > > >> <variable-bonus targetid="item.dagger.range-increment"
      > value="10"/>
      > > >> <variable-bonus targetid="item.dagger.critmult" value="2"/>
      > > >> <variable-bonus targetid="item.dagger.critrange" value="2" />
      > > >> <variable-bonus targetid="item.dagger.damage.die-size" value="4"
      > />
      > > >> <variable-bonus targetid="item.dagger.damage.die-count"
      > value="1"/>
      > > >> <variable-bonus targetid="item.dagger.range" value="10"/>
      > > >> <variable-bonus targetid="item.dagger.weight" value="1"/>
      > > >> <variable-bonus targetid="item.dagger.cost" value="2"/>
      > > >> <add-entity refid="eqmod.steel"/>
      > > >> </effects>
      > > >> </entity>
      > > >
      > > > The variable-bonus... does it apply to the entity being described, or
      > to
      > > > the character/entity it is being applied to? With a feat, it looks
      > like
      > > > it gets applied to the character, but with the dagger it... looks like
      > > > it gets applied to the character, but should actually be describing
      > the
      > > > dagger. This is unclear to me.
      > >
      > > I am working on everything apliying to the character. I guess it is the
      > > difference between asking the character "how much damage do you do with
      > a
      > > dagger" and asking the dagger: "how much damage to you do when weilded
      > by
      > > the character". this is why all of the variables are prefexed with the
      > > item id.
      >
      > Best watch this; characters in my design are not particularly 'special';
      > the same mechanisms are used for other entities (such as equipment and
      > whatnot -- adding an equipmod to a sword is much the same as adding a
      > feat to a character).
      >
      > If you'll be prefixing the item ID to the variable modified, you'll need
      > to parse it out at some point to determine the values. However, I have
      > an idea.
      >
      > <variable-mod target='self' key='varname' value='n' />
      >
      > Hmm... actually, that doesn't make a lot of sense -- why would something
      > need to modify itself? Most modifications would implicitly be to what
      > the item is applied to... so.
      >
      > <variable key='varname' value='n' />
      >
      > defines the field (in concrete terms that'd be <cost> or <critmult> or
      > whatever)
      >
      > <variable-mod key='varname' value='formula' />
      >
      > would describe (in part) what happens when you apply the modifier to the
      > receiving entity:
      >
      > <equipmod id='eqmod.masterwork'>
      > <variable-mod key='toHit' value='+1' />
      > </equipmod>
      >
      > should (in theory) increase the toHit value of the item of equipment it
      > is applied to... though in this case it should probably be treated as a
      > bonus rather than a modifier.
      >
      > Oh, right -- we probably need to be able to piggyback effects, too.
      > Adding one entity to another might modify the recipient so it passes an
      > effect on to what *it* is applied to.
      >
      > > If you wanted to give a feat that increased the damage dice to a d6
      > > rather than a d4 you would apply this to the character:
      > >
      > > <variable-bonus targetid="item.dagger.damage.die-size" value="2"
      > > stacks="true"/>
      > >
      > > or
      > >
      > > <variable-bonus targetid="item.dagger.damage.die-size" value="6"
      > > stacks="false"/>
      >
      > how would you increase the damage of a particular dagger, though?
      > Create a new 'sharper dagger' entity?
      >
      > > > Also, 'variable-bonus' looks deceptive. Is it a bonus to the 'real'
      > > > value of the variable (in which case there are rules about how they
      > > > stack, etc.) or is it a direct modification of the real value?
      > >
      > > It is a modification to the variable. I guess it is badly named, it
      > should
      > > be named something like: <variable-modification>.
      > >
      > > I would say that the rules on <variable-modification> are:
      > >
      > > - If (there are any modifications that have replaces="true")
      > > then use the highest one
      > > else
      > > Take the highest modification that does not have
      > > stacks="true" or replaces="true".
      > > - add all of the modifications that have stacks="true"
      > >
      > >
      > >
      > > > Is this intended to be an 'intermediate form' (for instance, how it
      > > > might look after being loaded? The XML itself can probably be very
      > much
      > > > simplified and the data translated to this form automatically without
      > a
      > > > lot of scariness from a simpler form, something like
      > > >
      > > > <equipment id='item.dagger'>
      > > > <name>Dagger</name>
      > > > <types>
      > > > <type>item</type>
      > > > <type>weapon</type>
      > > > <type>melee</type>
      > > > <type>dagger</type>
      > > > <type>standard</type>
      > > > </types>
      > > > <effects /> <!-- how it changes the character goes here -->
      > > > <physical-info size='medium' weight='2' cost='2' />
      > > > <weapon-info>
      > > > <usage light='yes' finesseable='yes' ranged='thrown' />
      > > > <damage roll='1d4' critmult='2' critrange='2'>
      > > > <type>piercing</type>
      > > > <type>slashing</type>
      > > > </damage>
      > > > <ranged range-increment='10' max-increments='5' />
      > > > </weapon-info>
      > > > </equipment>
      > >
      > > as I said at the top of this email: I did not do any kind of high level
      > > XML as everytime I have suggested it over ht epast year someone has shot
      > > me down.
      > >
      > >
      > > > <!-- not sure how to indicate that it's made of steel, though your
      > > > '<add-entity refid="eqmod.steel" />' seems likely. I didn't include
      > > > it because it *looks* like it's supposed to be added to the
      > character
      > > > who receives the dagger.
      > >
      > > This is the part where my "everything applies to the character" system
      > > falls apart ;O(
      >
      > I like the use of the steel equipmod, though; this is much better than
      > 'TYPE: STEEL'.
      >
      > How's this: change your targetid attribute to 'key' [which is safer
      > anyway; ID should be unique in the system, which means that only a
      > single character is being modeled (targetid *is* unique) or it isn't
      > (and targetid is lying about this implication]. Give the variable-mod
      > (or any other effect) an implicit target of 'the recipient'; this can be
      > overridden (target='self') for those cases where you want it to be able
      > to apply something (variable modification, equipment modification, etc.)
      > to itself instead. So
      >
      > <entity id='item.dagger'>
      > <!-- name, variable identification and initialization , etc. -->
      > <add-entity target='self' refid='eqmod.steel' />
      > </entity>
      >
      > Or for a truly nifty item:
      >
      > <entity id='item.dagger.steelbody'>
      > <!-- name, variable identification and initialization , etc. -->
      > <add-entity refid='eqmod.steel' />
      > <!-- turns wielder into steel, oops... -->
      > </entity>
      >
      > > > Proficiency is better determined and indicated by feats and class
      > > > abilities, not the item itself, I think. This may also be subject to
      > > > reclassification in different campaigns.
      > > >
      > > > <type>simple</type>
      > >
      > > I put the proficiency bonuses in the item because I did not want to go
      > > down the road of having to lookup bonuses from unrelated things.
      > >
      > > I guess that you can have a dagger.prof variable made up of the highest
      > of
      > > weaponprof.dagger bonus, weaponprof.martial bonus and weaponprof.dagger
      > > bonus.
      > >
      > > >> <prereq kind="mult" operand="1">
      > > >> <prereq kind="alignment" key="lawful.good"/>
      > > >> <prereq kind="alignment" key="lawful.neutral"/>
      > > >> <prereq kind="alignment" key="lawful.evil"/>
      > > >> </prereq>
      > > >
      > > > I had this as
      > > >
      > > > <prereq min='1' max='1'>
      > > > <prereq kind='alignment' key='lawful.good' /> <!-- align.lg -
      > ->
      > > > <prereq kind='alignment' key='lawful.neutral' /> <!-- align.ln -
      > ->
      > > > <prereq kind='alignment' key='lawful.evil' /> <!-- align.le -
      > ->
      > > > </prereq>
      > > >
      > > > Basically, any time they nest, they implicitly form a mult-kind of
      > > > prereq... that's one only one that makes sense. After that you just
      > > > have to indicate how many of the child prereqs must be satisfied.
      > >
      > > I am 'implicit-phobic' I have been bitten by implitic too many times to
      > > trust it (or anyone else implimentation of it) saying that I missed out
      > > the 'operator="="' attribute ;O)
      >
      > I'm not generally fond of implicit behavior... though in this case I see
      > it as something of an 'explicit implicit' -- it's part of the defined
      > behavior. Still, it doesn't *hurt* to say <prereq kind='mult'>, either.
      >
      > > Having used my prereq syntax in the current version of PCGen I know that
      > > it copes with all cases without needed other syntax.
      > >
      > > >> <ranks>
      > > >> <rank level="1">
      > > >> <effects>
      > > >> <add-entity refid="sa.literacy"/>
      > > >> <add-entity refid="skill.balance"/>
      > > >
      > > > Add 'skill.balance' to the character? As a class skill, you mean?
      > This
      > > > isn't entirely clear to me.
      > >
      > > Yes. It isn't entirly clear to me now that I reread it. We are back to
      > > skills being a pain to implement.
      >
      > yep.
      >
      > > >> <add-entity refid="feat.weapon-prof" choice="club"/>
      > > >
      > > > I'd put these in a separate list ('monk weapon proficiencies') outside
      > > > the class and add them later, something like an 'invisible feat' as
      > > > they're currently used.
      > >
      > > Again, purely a style issue.
      > >
      > > > I would instead create a 'monk unarmed combat' progression that lives
      > > > outside the monk class. The monk class adds a rank in that
      > progression
      > > > at each of its own ranks... then other classes can also do the same (a
      > > > monk-based prestige class could then say 'unarmed combat stacks with
      > > > that from monk' very easily).
      > >
      > > After I sent out the email I realised that doing the unarmed combat as a
      > > progression would be easier.
      > >
      > > the one thing I have not figured out how to do is replace the
      > progression
      > > with a completely different one. Some of the complex monk classes/feats
      > > allow you to "use one size larger for unarmed damage", "use 1 size
      > smaller
      > > for damage", "use this other progression for unarmed damage".
      >
      > Hmm... this is one of those 'it's easy to design it this way from the
      > front' sort of deals, where we make the association *between* the
      > character and the class -- in RDBMS terms, something like
      >
      > Character
      > |
      > ^
      > CharClass (this contains things like 'effective monk damage size', ick)
      > v
      > |
      > Class
      >
      > But I'm not happy with *that*, either.
      >
      > It's a damn shame that the monk progressions aren't *quite* size bumps
      > (at /n/ level you are treated as /x/ sizes larger than normal)...
      > they're *close* in RSRD, IIRC, but not *quite* right. Dammit.
      >
      > Hmm... I think I'll note that for my campaign, actually; it'll simplify
      > things.
      >
      > > > Incidentally, I would do the same with
      > > > spellcasters; each level of wizard adds one level of 'wizard
      > > > spellcasting', which in turn adds 'one level of wizard spells per
      > day';
      > > > each level of sorcerer adds one level of 'sorcerer spellcasting',
      > which
      > > > in turn adds a rank each of 'sorcerer spells per day' and 'sorcerer
      > > > spells known'.
      > >
      > > That would make spellcasting prestige classes a lot easier.
      >
      > That's why <g>
      >
      > --
      > Keith Davies I gave my 2yo daughter a strawberry
      > keith.davies@... Naomi: "Strawberry!"
      > me: "What do you say?"
      > Naomi: "*MY* strawberry!"
      >
      >
      > ________________________________________________________________________
      > ________________________________________________________________________
      >
      > Message: 4
      > Date: Tue, 06 Apr 2004 08:45:21 -0700
      > From: Keith Davies <keith.davies@...>
      > Subject: Re: Examples
      >
      > On Tue, Apr 06, 2004 at 12:34:40PM +0100, Frugal wrote:
      > >
      > > <quote who="Steven Bethard">
      > > > Just to clarify, but this means a player chooses a Race at each level,
      > > > right? I assume this is to make monster levels/classes simpler...
      > >
      > > Correct.
      >
      > To be more precise (at least about my design, which I think Frugal was
      > trying to model), each race has or is a progression; the character (or
      > creature) adds a rank in that progression and it (may) end up adding a
      > class level. Specifically, the race is chosen once, ranks are added
      > many times... he doesn't get to choose a new race at each level (which
      > is how I first read your question).
      >
      > > >> <progression id="race.human">
      > > >> ...
      > > >> <add-entity type="feat" />
      > > >> ...
      > > >> </progression>
      > > >> ...
      > > >> <progression id="characterlevel">
      > > >> ...
      > > >> <add-rank type="class"/>
      > > >> ...
      > > >> </progression>
      > > >
      > > > Is the assumption with 'type' that any time it selects more than one
      > > > item the user must make a choice? If this is the case, to specify
      > > > that the user gets all the feats of a certain type, we would have to
      > > > enumerate them all in <add-entity />s, which might be annoying for
      > > > the weapon-proficiency feats...
      > >
      > > The assumption is that with <add-rank type="class"/> the client will
      > look
      > > for all progressions with a <type>class</type> child element and ask the
      > > user to choose one. Likewise <add-entity type="feat" /> will look for
      > all
      > > entitiess with a <type>feat</type>.
      > >
      > > I imagine that <add-entity type="feat,fighter"/> will look for all
      > > entities with a type of 'feat' && a type of 'fighter'.
      > >
      > > I guess we do need some way to add more than one entity at a time.
      > >
      > > <add-entity type="feat,weapon-prof,martial" count="all"/>
      > >
      > > to add all entities that have the 'feat', 'weapon-prof' and 'martial'
      > types.
      >
      > If you're saying what I think you are here, I suspect it's backward --
      > feats grant proficiency, but they're not the *only* thing that grants
      > proficiency.
      >
      > > <add-entity type="feat,meta-magic" count="2"/>
      > >
      > > To add any 2 meta-magic feats.
      >
      > I think we need to specify some sort of query syntax to deal with this
      > sort of thing... you're working around the edges of one, but we should
      > do something more explicit. 'sides, I'll need it for extracting
      > entities from the system to be written to file.
      >
      > > > How do you intend this to be handled? That is, how do we know how
      > > > to check "wield"? I can see how to check entity presence and
      > > > variable values based on the data descriptions so far. Can this be
      > > > done with "wield" too, or is this one of the things we'll have to
      > > > leave to program logic?
      > >
      > > All of the prerequisites will need to be done in code, even the variable
      > > ones.
      >
      > Described in data, tested in code, you mean?
      >
      >
      > Keith
      > --
      > Keith Davies I gave my 2yo daughter a strawberry
      > keith.davies@... Naomi: "Strawberry!"
      > me: "What do you say?"
      > Naomi: "*MY* strawberry!"
      >
      >
      > ________________________________________________________________________
      > ________________________________________________________________________
      >
      > Message: 5
      > Date: Tue, 6 Apr 2004 10:36:52 -0600
      > From: "Steven Bethard" <bediviere@...>
      > Subject: RE: Examples
      >
      > <quote who="Frugal">
      > > Are we now saying that the progression, rank, entity
      > > structures are actually Java structures that we map
      > > the high level XML onto? Or are we planning to map
      > > from high level XML to low level XML to java
      > > structures?
      >
      > My preference is to have one XML standard that looks something like what
      > Frugal's presented. This standard should be as system-independent as
      > possible, and as much as possible should map directly into Java objects.
      > If
      > this standard is still too low-level for people, I think we should allow a
      > higher-level standard that can be mapped to this standard, but I think
      > this
      > step should be completely optional.
      >
      > I've been pushing to keep the one standard as simple as possible, which is
      > why we discussed using just Entities and Effects for a while. I think I'm
      > more or less convinced now that this very general approach won't work for
      > D&D, and that we'll have to move to something that encodes a little more
      > about the system into the code, like what Frugal's done.
      >
      > In general, I'd prefer that we never have elements or attributes named
      > with
      > something specific to one game system, so that we would never have:
      > <progression id="skill.balance" usable-untrained="true" />
      > or:
      > <skill id="balance" usable-untrained="true" />
      > but instead, something like what Frugal's done:
      > <progression id="skill.balance">
      > <attribute key="usable-untrained" value="true" />
      > </progression
      > This may be what Keith already intended, but it's hard for me to tell how
      > the UML diagrams were supposed to translate into XML.
      >
      >
      > Steve
      > _____
      >
      > You can wordify anything if you just verb it.
      > - Bucky Katt, Get Fuzzy
      >
      >
      > ________________________________________________________________________
      > ________________________________________________________________________
      >
      >
      >
      > ------------------------------------------------------------------------
      > Yahoo! Groups Links
      >
      >
      >
      >
      > ------------------------------------------------------------------------
      >
      >
    • David Finch
      ... I totally agree, the other way is more confusing (well to me anyway). -- David Allan Finch - Unix/X/C++/Java Programmer, and Sys/Mail/DB/Net Admin Sun(tm)
      Message 2 of 29 , Apr 13, 2004
      • 0 Attachment
        Jenni A. Merrifield wrote:
        > Is there any particular reason, with this *internal* data representation,
        > to avoid using traditional Boolean operators such as "AND", "OR", "XOR" and
        > "NOT"? Using it, we could be quite sure of what prerequisites were being
        > requested and their relationships to each other.

        I totally agree, the other way is more confusing (well to me anyway).

        --
        David Allan Finch - Unix/X/C++/Java Programmer, and Sys/Mail/DB/Net Admin
        Sun(tm) Certified System Administrator for Solaris(tm) 2.6
        Development Department - IPA Systems Ltd - Salfords England EU
      • Keith Davies
        ... I d be willing to use this for the external data representation; I was using min and max to allow for at least two of the following (or no more than
        Message 3 of 29 , Apr 13, 2004
        • 0 Attachment
          On Tue, Apr 13, 2004 at 07:06:51AM -0700, Jenni A. Merrifield wrote:
          >
          > Is there any particular reason, with this *internal* data representation,
          > to avoid using traditional Boolean operators such as "AND", "OR", "XOR" and
          > "NOT"? Using it, we could be quite sure of what prerequisites were being
          > requested and their relationships to each other.

          I'd be willing to use this for the external data representation; I was
          using 'min' and 'max' to allow for 'at least two of the following' (or
          'no more than two of the following', for that matter) cases. The same
          mechanism would successfully deal with the cases described below, so I
          didn't bother persuing your suggestion (I *did* think of it, but numbers
          served the same purpose across more cases).

          > Examples:
          >
          > <prereq kind="mult" operand="XOR">
          > <!-- Any Lawful or true neutral -->
          > <prereq kind="alignment" key="lawful.good"/>
          > <prereq kind="alignment" key="lawful.neutral"/>
          > <prereq kind="alignment" key="lawful.evil"/>
          > <prereq kind="alignment" key="neutral.neutral"/>
          > </prereq>
          > <!-- XOR is the most accurate option here, though OR would also work here
          > because no object should ever have more than one alignment anyway -->
          >
          > <prereq kind="mult" operand="AND">
          > <prereq kind="alignment" key="lawful.good" />
          > <prereq kind="mult" operand="OR">
          > <prereq kind="feat" key="feat.eschew-materials" />
          > <prereq kind="feat" key="feat.silent-spell" />
          > </prereq>

          <prereq>
          <prereq kind='alignment' key='align.lg' />
          <prereq min='1'>
          <prereq kind='feat' key='feat.eschew-materials' />
          <prereq kind='feat' key='feat.silent-spell' />
          </prereq>
          </prereq>

          This is a little shorter, but not enough to really care about.

          Your suggestion is probably simpler in most cases; I'd be willing to use
          it. The only thing it fails to handle (as written) is the 'n of m'
          case, and even that can be handled by another operand

          <prereq kind='mult' operand='select' min='2'>
          <prereq kind='alignment' key='lawful.good' />
          <prereq kind='feat' key='feat.eschew-materials' />
          <prereq kind='feat' key='feat.silent-spell' />
          </prereq>

          'select' is a lousy operand name, need a better one.

          Still, I like the numbers version better -- it's a little clearer what's
          going on and can be implemented using a single chain of logic:

          min = numChildren;
          max = numChildren;
          if (minSet) {
          min = attribs.getAttrib( "min");
          }
          if (maxSet) {
          max = attribs.getAttrib( "max");
          }
          childrenMatched = checkPrereqs( entity, children);
          if ((min <= childrenMatched) &&
          (childrenMatched <= max)) {
          doWePassed();
          } else {
          doWeFailed();
          }

          This does not require string examination of the operand attribute, nor
          the logic necessary to handle the various cases. The 'and' case is
          implicit (if min and max aren't set, it requires all children to pass),
          the 'or' case is handled as '1 of m', and it handles both 'n of m' and
          'no more than n of m' cases consistently.

          I'd be willing to use 'and' or 'or' operands, but this is, IMO, more
          elegant, consistent, and simpler to implement and use.

          > I recognize that many non-programmers get confused by Boolean logic
          > (especially when doing searches because it contradicts standard language
          > conventions - e.g., find boys AND girls) and so I wouldn't recommend Boolean
          > logic for an *external* representation, but why not use it *internally*?

          For something like this I think I'd like to keep it consistent between
          internal and external. While I don't mind transforming data to make it
          suit our purposes better (smashing all entity element types to an
          <entity> structure on load, for example), minor cosmetic differences
          complicate things without adding much.

          A friend of mine has spent a fair amount of time in Canada, Japan, and
          the US over the last few years (is Canadian, has been teaching in Japan,
          and his fiancee is from the US). He has fewer problems dealing with yen
          vs. Canadian dollars than US dollars vs. Canadian dollars simply because
          they had a different name.

          > > I'm not generally fond of implicit behavior... though in this case I see
          > > it as something of an 'explicit implicit' -- it's part of the defined
          > > behavior. Still, it doesn't *hurt* to say <prereq kind='mult'>, either.
          >
          > Can't you define both forms as valid? Full syntax requires
          > kind="mult" but if kind is for some reason omitted then kind="mult" is
          > assumed?

          That's what I was doing (in practice, if not in implementation). The
          only thing this leaves us vulnerable to is a change in interpretation,
          but I don't *expect* that to happen -- there are really no other
          reasonable interpretations of *any* prereq that has child prereqs; if
          the prereq doesn't have children, 'mult' is not an appropriate @kind
          anyway.


          Keith
          --
          Keith Davies I gave my 2yo daughter a strawberry
          keith.davies@... Naomi: "Strawberry!"
          me: "What do you say?"
          Naomi: "*MY* strawberry!"
        • Frugal
          ... There are 2 reasons I can think of: 1 - As you said yourself boolean logic is not easily comprehended by most people. 2 -
          Message 4 of 29 , Apr 14, 2004
          • 0 Attachment
            <quote who="Jenni A. Merrifield">
            > Is there any particular reason, with this *internal* data
            > representation,
            > to avoid using traditional Boolean operators such as "AND", "OR", "XOR"
            > and
            > "NOT"? Using it, we could be quite sure of what prerequisites were being
            > requested and their relationships to each other.

            There are 2 reasons I can think of:

            1 - As you said yourself boolean logic is not easily comprehended by most
            people.

            2 - There are cases where boolean logic will not suffice. A prime example
            is "you must have 2 of these following 3 feats".

            I used the syntax of:

            <prereq kind=""
            key=""
            subkey=""
            operator="=,!=,<,<=,>,>="
            operand=""
            countmultiples="true|false" />

            Because it copes with every single case. It also allows for things like:

            <prereq kind="feat"
            key="weapon focus"
            operator=">="
            operand="2"
            countmultiples="true" />

            For "You must have taken weapon focus with at least 2 weapons.

            --
            regards,
            Frugal
            -OS Chimp
          • Jenni Merrifield
            {Bah. I apologize if this shows up twice - I tried to use the Yahoo! Post function last night and even though it said it had been posted, I don t see this
            Message 5 of 29 , Apr 15, 2004
            • 0 Attachment

                {Bah.  I apologize if this shows up twice – I tried to use the Yahoo ! "Post" function last night and even though it said it had been posted, I don't see this or the other message I'm about to send on the web site.

              =JAMM}

               

              <quote who="Frugal" when="Wed, 14 Apr, 2004  12:50 +0100 (BST)">

              > <quote who="Jenni A. Merrifield">

              > >   Is there any particular reason, with this *internal* data

              > > representation, to avoid using traditional Boolean operators

              > > such as "AND", "OR", "XOR" and "NOT"?  Using it, we could be

              > > quite sure of what prerequisites were being requested and their

              > > relationships to each other.

              >

              > There are 2 reasons I can think of:

              >

              > 1 - As you said yourself boolean logic is not easily comprehended

              > by most people.

               

                True, but "most people" won't be working with the *internal* data structure right?  Programmers work with it, so *external* data can be converted into it and it can be loaded by the application, but I'd be willing to hazzard a guess that "most programmers" do understand boolean logic.

               

                Nonetheless, Keith did make some very good arguments about his min/max method and I would have to agree that it is more elegant, consistent, and less complicated.

               

              > 2 - There are cases where boolean logic will not suffice. A prime

              > example is "you must have 2 of these following 3 feats".

               

                Technically, "2 of the following 3 feats" is possible with strict Boolean, although in a very long, annoying out manner:

               

                (A && B && !C) || (A && !B && C) || (!A && B && C)

               

                Of course, as Keith pointed out, adding a "select/pick/choose" option would provide a more straightforward mechanism.

               

                Of course, he didn't bother to mention that such a "pick" option is really identical to his basic min/max recommendation, as it defaults to "AND" and can be used for "OR", "XOR" as well as all the other options such as "n of m", "at least n", "no more than n", "between n and m".  So I agree with Keith - why implement it as Boolean logic when a min/max implementation will do it all.

               

              > I used the syntax of:

              >

              > <prereq kind=""

              >         key=""

              >         subkey=""

              >         operator="=,!=,<,<=,>,>="

              >         operand=""

              >         countmultiples="true|false" />

              >

              > Because it copes with every single case.

               

                True, but it also suffers from the need to do string comparisons just like Boolean operands, whereas Keith's numerical method does not and is (as he explained) more straightforward to implement.

               

                Each of your operators can also be acheived using his method:

               

              *** Frugal's operator method:

               

                <!-- Any N of the following M items -->

                <prereq [...] operator="=" operand="n">

                  <option 1 .../>

                    [...]

                  <option M .../>

                </prereq>

               

                <!-- Not equal to N of the following M items -->

                <!-- Note: both < N and > N will be allowed -->

                <prereq [...] operator="!=" operand="n">

                  <option 1 .../>

                    [...]

                  <option M .../>

                </prereq>

               

                <!-- Less than N of the following M items -->

                <prereq [...] operator="<" operand="n">

                  <option 1 .../>

                    [...]

                  <option M .../>

                </prereq>

               

                <!-- No more than N of the following M items -->

                <prereq [...] operator="<=" operand="n">

                  <option 1 .../>

                    [...]

                  <option M .../>

                </prereq>

               

                <!-- More than N of the following M items -->

                <prereq [...] operator=">" operand="n">

                  <option 1 .../>

                    [...]

                  <option M .../>

                </prereq>

               

                <!-- No less than N of the following M items -->

                <prereq [...] operator=">=" operand="n">

                  <option 1 .../>

                    [...]

                  <option M .../>

                </prereq>

               

               

              *** Kieth's min/max method:

               

                <!-- Any N of the following M items -->

                <prereq [...] min="n">

                  <option 1 .../>

                    [...]

                  <option M .../>

                </prereq>

               

                <!-- Not equal to N of the following M items -->

                <!-- Note: does need a way to specify "not" -->

                <prereq [...] not="1" min="n" max="n">

                  <option 1 .../>

                    [...]

                  <option M .../>

                </prereq>

               

                <!-- Less than N of the following M items -->

                <prereq [...] max="n-1">

                  <option 1 .../>

                    [...]

                  <option M .../>

                </prereq>

               

                <!-- No more than N of the following M items -->

                <prereq [...] max="n">

                  <option 1 .../>

                    [...]

                  <option M .../>

                </prereq>

               

                <!-- More than N of the following M items -->

                <prereq [...] min="n+1">

                  <option 1 .../>

                    [...]

                  <option M .../>

                </prereq>

               

                <!-- No less than N of the following M items -->

                <prereq [...] min="n">

                  <option 1 .../>

                    [...]

                  <option M .../>

                </prereq>

               

                PLUS it also easily handles

               

                <!-- between N and M of the following Q items -->

                <prereq [...] min="n" max="m">

                  <option 1 .../>

                    [...]

                  <option Q .../>

                </prereq>

               

                <!-- less than N or more than M of the following Q items -->

                <!-- Note: also needs a way to specify "not" -->

                <prereq [...] not="1" min="n" max="m">

                  <option 1 .../>

                    [...]

                  <option Q .../>

                </prereq>

               

              > It also allows for things like:

              >

              > <prereq kind="feat"

              >         key="weapon focus"

              >         operator=">="

              >         operand="2"

              >         countmultiples="true" />

              >

              > For "You must have taken weapon focus with at least 2 weapons.

               

                <prereq kind="feat" key="weapon-focus" min="2" countmult="1">

               

                ;-)

               

              Questions:

               

              To all:  Can we find a better name for an attribute than "countmultiples" or "countmult"?  They're both kind of long...

               

              To Frugal:  What is the "subkey" attribute meant to be used for?

               

              Jenni

               

              --

              Jenni A. M. Merrifield (strawberry @ jamm . com)

              Software User Experience Professional

              Designing to Requirements and walking on Water is EASY. . .

              . . . So long as both are Frozen.

              --

               

              --
              Jenni A. M. Merrifield (JenniM @ microsoft . com)
              User Experience PM - TrustBridge - Windows Security Core
              Designing to Requirements and walking on Water is EASY. . .
              . . . So long as both are Frozen.
              ----------
              E-Mail & WinIM: [jennim @ microsoft.com]
              V-Mail: [425/707-8150 (x78150)] | Fax: [425/936-7329]
              Office: [40/6213]
              --

               

            • Keith Davies
              ... heh, doublespaced, too... that s odd. ... Though this will fail if all three conditions are met; you ve implemented two and only two . The fix is pretty
              Message 6 of 29 , Apr 15, 2004
              • 0 Attachment
                On Thu, Apr 15, 2004 at 11:56:02AM -0700, Jenni Merrifield wrote:
                > {Bah. I apologize if this shows up twice - I tried to use the Yahoo!
                > "Post" function last night and even though it said it had been posted, I
                > don't see this or the other message I'm about to send on the web site.
                >
                > =JAMM}

                heh, doublespaced, too... that's odd.


                > <quote who="Frugal" when="Wed, 14 Apr, 2004 12:50 +0100 (BST)">
                >
                > > <quote who="Jenni A. Merrifield">
                >
                > > > Is there any particular reason, with this *internal* data
                > > > representation, to avoid using traditional Boolean operators
                > > > such as "AND", "OR", "XOR" and "NOT"? Using it, we could be
                > > > quite sure of what prerequisites were being requested and their
                > > > relationships to each other.
                > >
                > > There are 2 reasons I can think of:
                > >
                > > 1 - As you said yourself boolean logic is not easily comprehended
                > > by most people.
                >
                > True, but "most people" won't be working with the *internal* data
                > structure right? Programmers work with it, so *external* data can be
                > converted into it and it can be loaded by the application, but I'd be
                > willing to hazzard a guess that "most programmers" do understand boolean
                > logic.
                >
                > Nonetheless, Keith did make some very good arguments about his min/max
                > method and I would have to agree that it is more elegant, consistent,
                > and less complicated.
                >
                > > 2 - There are cases where boolean logic will not suffice. A prime
                > > example is "you must have 2 of these following 3 feats".
                >
                > Technically, "2 of the following 3 feats" is possible with strict
                > Boolean, although in a very long, annoying out manner:
                >
                > (A && B && !C) || (A && !B && C) || (!A && B && C)

                Though this will fail if all three conditions are met; you've
                implemented 'two and only two'. The fix is pretty obvious.

                This gets *really* ugly if the conditions are complex.

                > Of course, as Keith pointed out, adding a "select/pick/choose" option
                > would provide a more straightforward mechanism.
                >
                > Of course, he didn't bother to mention that such a "pick" option is
                > really identical to his basic min/max recommendation, as it defaults to
                > "AND" and can be used for "OR", "XOR" as well as all the other options
                > such as "n of m", "at least n", "no more than n", "between n and m". So
                > I agree with Keith - why implement it as Boolean logic when a min/max
                > implementation will do it all.
                >
                >
                > > I used the syntax of:
                > >
                > > <prereq kind=""
                > > key=""
                > > subkey=""
                > > operator="=,!=,<,<=,>,>="
                > > operand=""
                > > countmultiples="true|false" />
                > >
                > > Because it copes with every single case.
                >
                > True, but it also suffers from the need to do string comparisons just
                > like Boolean operands, whereas Keith's numerical method does not and is
                > (as he explained) more straightforward to implement.
                >
                > Each of your operators can also be acheived using his method:
                >
                > *** Frugal's operator method:
                >
                > <!-- Any N of the following M items -->
                > <prereq [...] operator="=" operand="n">
                > <option 1 .../>
                > [...]
                > <option M .../>
                > </prereq>
                >
                > <!-- Not equal to N of the following M items -->
                > <!-- Note: both < N and > N will be allowed -->
                >
                > <prereq [...] operator="!=" operand="n">
                > <option 1 .../>
                > [...]
                > <option M .../>
                > </prereq>
                >
                > <!-- Less than N of the following M items -->
                > <prereq [...] operator="<" operand="n">
                > <option 1 .../>
                > [...]
                > <option M .../>
                > </prereq>
                >
                > <!-- No more than N of the following M items -->
                > <prereq [...] operator="<=" operand="n">
                > <option 1 .../>
                > [...]
                > <option M .../>
                > </prereq>
                >
                > <!-- More than N of the following M items -->
                > <prereq [...] operator=">" operand="n">
                > <option 1 .../>
                > [...]
                > <option M .../>
                > </prereq>
                >
                > <!-- No less than N of the following M items -->
                > <prereq [...] operator=">=" operand="n">
                > <option 1 .../>
                > [...]
                > <option M .../>
                > </prereq>
                >
                >
                > *** Kieth's min/max method:
                >
                > <!-- Any N of the following M items -->
                > <prereq [...] min="n">
                > <option 1 .../>
                > [...]
                > <option M .../>
                > </prereq>
                >
                > <!-- Not equal to N of the following M items -->
                > <!-- Note: does need a way to specify "not" -->
                > <prereq [...] not="1" min="n" max="n">
                > <option 1 .../>
                > [...]
                > <option M .../>
                > </prereq>

                I don't see this case coming up, to be honest. If I were encoding such
                a thing (and the 'not' attribute wasn't there) I'd either lean toward an
                operator attribute (which I was *never* happy with, or just wrap it
                thus:

                <prereq max='0'>
                <prereq min='n' max='n'>
                <!-- n+m children -->
                </prereq>
                </prereq>

                or I might do

                <prereq min='1'>
                <prereq min='n+1' />
                <prereq max='n-1' />
                </prereq>

                Hmm... I think I like this one better, though I suppose it depends on
                how ugly the child lists are.

                These are a bit hackish and kludgey, but follows the simple model without
                introducing more. I try to design for the common case; something I
                don't *really* expect to happen, I don't mind having be a little more
                work.

                > <!-- Less than N of the following M items -->
                > <!-- No more than N of the following M items -->
                > <!-- More than N of the following M items -->
                > <!-- No less than N of the following M items -->
                >
                > PLUS it also easily handles
                >
                > <!-- between N and M of the following Q items -->

                All correct.

                > <!-- less than N or more than M of the following Q items -->
                > <!-- Note: also needs a way to specify "not" -->
                > <prereq [...] not="1" min="n" max="m">
                > <option 1 .../>
                > [...]
                > <option Q .../>
                > </prereq>

                We don't have '<option>' at this point, they're still <prereq>. Nit.

                As above, that can be split into two tests "((x < n) || (x > m))".

                It's a little odd, but I *might* consider allowing a special case where
                min > max, that it treats it in the way you're describing:

                <prereq min='m' max='n'>
                <!-- stuff -->
                </prereq>

                could be treated as equivalent to

                <prereq min='1'>
                <prereq min='m' />
                <prereq max='n' />
                </prereq>

                I don't *like* special cases, though.

                Does this sort of thing come up often enough to actually make it worth
                adding other operators, attributes, or special cases? I'm not
                specifically against doing so, but when something can and does do the
                job, I like to question changing it.

                > > It also allows for things like:
                > >
                > > <prereq kind="feat"
                > > key="weapon focus"
                > > operator=">="
                > > operand="2"
                > > countmultiples="true" />
                > >
                > > For "You must have taken weapon focus with at least 2 weapons.
                >
                > <prereq kind="feat" key="weapon-focus" min="2" countmult="1">

                'countmult'? I'm still not quite sure what that actually means.

                <prereq kind='feat' key='feat.weapon-focus' min='2' />

                means in my schema 'the entity has the Weapon Focus feat at least
                twice'.

                > Questions:
                >
                > To all: Can we find a better name for an attribute than
                > "countmultiples" or "countmult"? They're both kind of long...

                Attribute length isn't that important, I think. Long attributes are a
                bit inconvenient when typing, but meaningful names are more important.

                > To Frugal: What is the "subkey" attribute meant to be used for?

                Weapon Focus (Longsword), Spell Focus(Alteration), etc.

                key='feat.weapon-focus' means "Weapon Focus with some weapon"

                key='feat.weapon-focus' subkey='equip.longsword' means "Weapon Focus
                with longsword".


                Keith
                --
                Keith Davies I gave my 2yo daughter a strawberry
                keith.davies@... Naomi: "Strawberry!"
                me: "What do you say?"
                Naomi: "*MY* strawberry!"
              • Frugal
                ... It was to cope with prerequisites like: You must have a total of 20 ranks in jump , balance and Tumble combined.
                Message 7 of 29 , Apr 16, 2004
                • 0 Attachment
                  <quote who="Keith Davies">
                  > On Thu, Apr 15, 2004 at 11:56:02AM -0700, Jenni Merrifield wrote:
                  >> <quote who="Frugal" when="Wed, 14 Apr, 2004 12:50 +0100 (BST)">
                  >> > <quote who="Jenni A. Merrifield">
                  >>
                  >> > > Is there any particular reason, with this *internal* data
                  >> > > representation, to avoid using traditional Boolean operators
                  >> > > such as "AND", "OR", "XOR" and "NOT"? Using it, we could be
                  >> > > quite sure of what prerequisites were being requested and their
                  >> > > relationships to each other.
                  >> >
                  >> > There are 2 reasons I can think of:
                  >> >
                  >> > 1 - As you said yourself boolean logic is not easily comprehended
                  >> > by most people.
                  >>
                  >> True, but "most people" won't be working with the *internal* data
                  >> structure right? Programmers work with it, so *external* data can be
                  >> converted into it and it can be loaded by the application, but I'd be
                  >> willing to hazzard a guess that "most programmers" do understand boolean
                  >> logic.
                  >>
                  >> Nonetheless, Keith did make some very good arguments about his min/max
                  >> method and I would have to agree that it is more elegant, consistent,
                  >> and less complicated.
                  >>
                  >> > 2 - There are cases where boolean logic will not suffice. A prime
                  >> > example is "you must have 2 of these following 3 feats".
                  >>
                  >> Technically, "2 of the following 3 feats" is possible with strict
                  >> Boolean, although in a very long, annoying out manner:
                  >>
                  >> (A && B && !C) || (A && !B && C) || (!A && B && C)
                  >
                  > Though this will fail if all three conditions are met; you've
                  > implemented 'two and only two'. The fix is pretty obvious.
                  >
                  > This gets *really* ugly if the conditions are complex.
                  >
                  >> Of course, as Keith pointed out, adding a "select/pick/choose" option
                  >> would provide a more straightforward mechanism.
                  >>
                  >> Of course, he didn't bother to mention that such a "pick" option is
                  >> really identical to his basic min/max recommendation, as it defaults to
                  >> "AND" and can be used for "OR", "XOR" as well as all the other options
                  >> such as "n of m", "at least n", "no more than n", "between n and m". So
                  >> I agree with Keith - why implement it as Boolean logic when a min/max
                  >> implementation will do it all.
                  >>
                  >>
                  >> > I used the syntax of:
                  >> >
                  >> > <prereq kind=""
                  >> > key=""
                  >> > subkey=""
                  >> > operator="=,!=,<,<=,>,>="
                  >> > operand=""
                  >> > countmultiples="true|false" />
                  >> >
                  >> > Because it copes with every single case.
                  >>
                  >> True, but it also suffers from the need to do string comparisons just
                  >> like Boolean operands, whereas Keith's numerical method does not and is
                  >> (as he explained) more straightforward to implement.
                  >>
                  >> Each of your operators can also be acheived using his method:
                  >>
                  >> *** Frugal's operator method:
                  >>
                  >> <!-- Any N of the following M items -->
                  >> <prereq [...] operator="=" operand="n">
                  >> <option 1 .../>
                  >> [...]
                  >> <option M .../>
                  >> </prereq>
                  >>
                  >> <!-- Not equal to N of the following M items -->
                  >> <!-- Note: both < N and > N will be allowed -->
                  >>
                  >> <prereq [...] operator="!=" operand="n">
                  >> <option 1 .../>
                  >> [...]
                  >> <option M .../>
                  >> </prereq>
                  >>
                  >> <!-- Less than N of the following M items -->
                  >> <prereq [...] operator="<" operand="n">
                  >> <option 1 .../>
                  >> [...]
                  >> <option M .../>
                  >> </prereq>
                  >>
                  >> <!-- No more than N of the following M items -->
                  >> <prereq [...] operator="<=" operand="n">
                  >> <option 1 .../>
                  >> [...]
                  >> <option M .../>
                  >> </prereq>
                  >>
                  >> <!-- More than N of the following M items -->
                  >> <prereq [...] operator=">" operand="n">
                  >> <option 1 .../>
                  >> [...]
                  >> <option M .../>
                  >> </prereq>
                  >>
                  >> <!-- No less than N of the following M items -->
                  >> <prereq [...] operator=">=" operand="n">
                  >> <option 1 .../>
                  >> [...]
                  >> <option M .../>
                  >> </prereq>
                  >>
                  >>
                  >> *** Kieth's min/max method:
                  >>
                  >> <!-- Any N of the following M items -->
                  >> <prereq [...] min="n">
                  >> <option 1 .../>
                  >> [...]
                  >> <option M .../>
                  >> </prereq>
                  >>
                  >> <!-- Not equal to N of the following M items -->
                  >> <!-- Note: does need a way to specify "not" -->
                  >> <prereq [...] not="1" min="n" max="n">
                  >> <option 1 .../>
                  >> [...]
                  >> <option M .../>
                  >> </prereq>
                  >
                  > I don't see this case coming up, to be honest. If I were encoding such
                  > a thing (and the 'not' attribute wasn't there) I'd either lean toward an
                  > operator attribute (which I was *never* happy with, or just wrap it
                  > thus:
                  >
                  > <prereq max='0'>
                  > <prereq min='n' max='n'>
                  > <!-- n+m children -->
                  > </prereq>
                  > </prereq>
                  >
                  > or I might do
                  >
                  > <prereq min='1'>
                  > <prereq min='n+1' />
                  > <prereq max='n-1' />
                  > </prereq>
                  >
                  > Hmm... I think I like this one better, though I suppose it depends on
                  > how ugly the child lists are.
                  >
                  > These are a bit hackish and kludgey, but follows the simple model without
                  > introducing more. I try to design for the common case; something I
                  > don't *really* expect to happen, I don't mind having be a little more
                  > work.
                  >
                  >> <!-- Less than N of the following M items -->
                  >> <!-- No more than N of the following M items -->
                  >> <!-- More than N of the following M items -->
                  >> <!-- No less than N of the following M items -->
                  >>
                  >> PLUS it also easily handles
                  >>
                  >> <!-- between N and M of the following Q items -->
                  >
                  > All correct.
                  >
                  >> <!-- less than N or more than M of the following Q items -->
                  >> <!-- Note: also needs a way to specify "not" -->
                  >> <prereq [...] not="1" min="n" max="m">
                  >> <option 1 .../>
                  >> [...]
                  >> <option Q .../>
                  >> </prereq>
                  >
                  > We don't have '<option>' at this point, they're still <prereq>. Nit.
                  >
                  > As above, that can be split into two tests "((x < n) || (x > m))".
                  >
                  > It's a little odd, but I *might* consider allowing a special case where
                  > min > max, that it treats it in the way you're describing:
                  >
                  > <prereq min='m' max='n'>
                  > <!-- stuff -->
                  > </prereq>
                  >
                  > could be treated as equivalent to
                  >
                  > <prereq min='1'>
                  > <prereq min='m' />
                  > <prereq max='n' />
                  > </prereq>
                  >
                  > I don't *like* special cases, though.
                  >
                  > Does this sort of thing come up often enough to actually make it worth
                  > adding other operators, attributes, or special cases? I'm not
                  > specifically against doing so, but when something can and does do the
                  > job, I like to question changing it.
                  >
                  >> > It also allows for things like:
                  >> >
                  >> > <prereq kind="feat"
                  >> > key="weapon focus"
                  >> > operator=">="
                  >> > operand="2"
                  >> > countmultiples="true" />
                  >> >
                  >> > For "You must have taken weapon focus with at least 2 weapons.
                  >>
                  >> <prereq kind="feat" key="weapon-focus" min="2" countmult="1">
                  >
                  > 'countmult'? I'm still not quite sure what that actually means.
                  >
                  > <prereq kind='feat' key='feat.weapon-focus' min='2' />
                  >
                  > means in my schema 'the entity has the Weapon Focus feat at least
                  > twice'.

                  It was to cope with prerequisites like: You must have a total of 20 ranks
                  in "jump", "balance" and "Tumble" combined.

                  count-multiples="true" effectively means: Instead of returning '1' for
                  pass and '0' for fail, return 'n' for pass and '0' for fail where 'n' is
                  the total value of the prerequisite:

                  <prereq min="20">
                  <prereq kind="skill_rank" key="jump" min="1" count-multiples="true"/>
                  <prereq kind="skill_rank" key="balance" min="1" count-multiples="true"/>
                  <prereq kind="skill_rank" key="tumble" min="1" count-multiples="true"/>
                  </prereq>

                  --
                  regards,
                  Frugal
                  -OS Chimp
                • Keith Davies
                  ... [bigsnip] ... Ah, okay. ... Hmm... I m not sure like changing prereq semantics so they no longer return pass (true) or fail (false). ... I had a different
                  Message 8 of 29 , Apr 16, 2004
                  • 0 Attachment
                    On Fri, Apr 16, 2004 at 09:48:16AM +0100, Frugal wrote:
                    >
                    > <quote who="Keith Davies">

                    [bigsnip]

                    > > 'countmult'? I'm still not quite sure what that actually means.
                    > >
                    > > <prereq kind='feat' key='feat.weapon-focus' min='2' />
                    > >
                    > > means in my schema 'the entity has the Weapon Focus feat at least
                    > > twice'.
                    >
                    > It was to cope with prerequisites like: You must have a total of 20 ranks
                    > in "jump", "balance" and "Tumble" combined.

                    Ah, okay.

                    > count-multiples="true" effectively means: Instead of returning '1' for
                    > pass and '0' for fail, return 'n' for pass and '0' for fail where 'n' is
                    > the total value of the prerequisite:

                    Hmm... I'm not sure like changing prereq semantics so they no longer
                    return pass (true) or fail (false).

                    > <prereq min="20">
                    > <prereq kind="skill_rank" key="jump" min="1" count-multiples="true"/>
                    > <prereq kind="skill_rank" key="balance" min="1" count-multiples="true"/>
                    > <prereq kind="skill_rank" key="tumble" min="1" count-multiples="true"/>
                    > </prereq>

                    I had a different syntax for this sort of thing, but buggered if I can
                    remember what it was. Probably something like

                    <prereq kind='cumulative-ranks' min='20'>
                    <progression-ref key='skill.jump' />
                    <progression-ref key='skill.balance' />
                    <progression-ref key='skill.tumble' />
                    </prereq>

                    I know it wasn't progression-ref (I've never seen it before in my life,
                    and it's a lousy name). Still, I think this probably represents the
                    'cumulative total' behavior a little more clearly than by nesting
                    prereqs with changed semantics.


                    Keith
                    --
                    Keith Davies I gave my 2yo daughter a strawberry
                    keith.davies@... Naomi: "Strawberry!"
                    me: "What do you say?"
                    Naomi: "*MY* strawberry!"
                  • Jenni A. Merrifield
                    {Double-Bah. I just realized this other message, which was actually written before either of my last two, never showed up on the list. If any of my comments
                    Message 9 of 29 , Apr 16, 2004
                    • 0 Attachment
                      {Double-Bah. I just realized this other message, which was actually written
                      before either of my last two, never showed up on the list. If any of my
                      comments referring to my own previous comments seemed confusing, this might
                      explain why. :-P }

                      <quote who="Keith Davies" when="Tue, 13 Apr 2004 12:04:53 -0700">
                      > On Tue, Apr 13, 2004 at 07:06:51AM -0700, Jenni A. Merrifield wrote:
                      > >
                      > > Is there any particular reason, with this *internal* data
                      > > representation, to avoid using traditional Boolean operators such as
                      > > "AND", "OR", "XOR" and "NOT"? Using it, we could be quite sure of what
                      > > prerequisites were being requested and their relationships to each other.
                      >
                      > I'd be willing to use this for the external data representation; I was
                      > using 'min' and 'max' to allow for 'at least two of the following' (or
                      > 'no more than two of the following', for that matter) cases. The same
                      > mechanism would successfully deal with the cases described below, so I
                      > didn't bother pursuing your suggestion (I *did* think of it, but numbers
                      > served the same purpose across more cases).

                      [...SNIP...]

                      > Your suggestion is probably simpler in most cases; I'd be willing to use
                      > it. The only thing it fails to handle (as written) is the 'n of m'
                      > case, and even that can be handled by another operand
                      >
                      > <prereq kind='mult' operand='select' min='2'>
                      > <prereq kind='alignment' key='lawful.good' />
                      > <prereq kind='feat' key='feat.eschew-materials' />
                      > <prereq kind='feat' key='feat.silent-spell' />
                      > </prereq>
                      >
                      > 'select' is a lousy operand name, need a better one.

                      How about one of:

                      * "selection"
                      * "pick" <-- I like this one
                      * "choose" <-- this would be familiar to LST writers
                      * "choice"
                      * "subset"

                      > Still, I like the numbers version better -- it's a little clearer what's
                      > going on and can be implemented using a single chain of logic:
                      >
                      > min = numChildren;
                      > max = numChildren;
                      > if (minSet) {
                      > min = attribs.getAttrib( "min");
                      > }
                      > if (maxSet) {
                      > max = attribs.getAttrib( "max");
                      > }
                      > childrenMatched = checkPrereqs( entity, children);
                      > if ((min <= childrenMatched) &&
                      > (childrenMatched <= max)) {
                      > doWePassed();
                      > } else {
                      > doWeFailed();
                      > }
                      >
                      > This does not require string examination of the operand attribute, nor
                      > the logic necessary to handle the various cases.

                      Your algorithmic argument is a fairly good one - the lack of a need to do
                      string examination would probably make it somewhat more performant.

                      > The 'and' case is
                      > implicit (if min and max aren't set, it requires all children to pass),
                      > the 'or' case is handled as '1 of m', and it handles both 'n of m' and
                      > 'no more than n of m' cases consistently.

                      With Boolean terms "and" would still be implicit if there is no operator
                      and no min or max. In addition "pick"/"choose" is almost implicit if there
                      is no operator but there is a min and/or a max (e.g., a subset of the options
                      must apply for the prereq to apply)

                      > I'd be willing to use 'and' or 'or' operands, but this is, IMO, more
                      > elegant, consistent, and simpler to implement and use.

                      Perhaps you are right. It would definitely seem to be more consistent.

                      Two remaining questions:

                      1) How does one negate the numerical version for prerequisites? I can think
                      of three options:

                      A. A "not" or "inv" attribute set to "1" when it applies:

                      <!-- Not this -->
                      <prereq kind='feat' inv='1' key='feat.eschew-materials' />

                      <!-- Not both -->
                      <prereq kind='mult' inv='1'>
                      <prereq kind='feat' key='feat.eschew-materials' />
                      <prereq kind='feat' key='feat.silent-spell' />
                      </prereq>

                      <!-- Neither -->
                      <prereq kind='mult' min='1' max='1' inv='1'>
                      <prereq kind='feat' key='feat.eschew-materials' />
                      <prereq kind='feat' key='feat.silent-spell' />
                      </prereq>

                      <!-- No more than two -->
                      <prereq kind='mult' min='2' inv='1'>
                      <prereq kind='feat' key='feat.enlarge-spell' />
                      <prereq kind='feat' key='feat.eschew-materials' />
                      <prereq kind='feat' key='feat.silent-spell' />
                      </prereq>


                      B. A "kind" attribute with the value "not"

                      <!-- Not this -->
                      <prereq kind='not'>
                      <prereq kind='feat' inv='1' key='feat.eschew-materials' />
                      </prereq>

                      <!-- Not Both -->
                      <prereq kind='not'>
                      <prereq kind='mult'>
                      <prereq kind='feat' key='feat.eschew-materials' />
                      <prereq kind='feat' key='feat.silent-spell' />
                      </prereq>
                      </prereq>

                      <!-- Neither -->
                      <prereq kind='not'>
                      <prereq kind='mult' min='1' max='1'>
                      <prereq kind='feat' key='feat.eschew-materials' />
                      <prereq kind='feat' key='feat.silent-spell' />
                      </prereq>
                      </prereq>

                      <!-- No more than two -->
                      <prereq kind='not'>
                      <prereq kind='mult' min='2'>
                      <prereq kind='feat' key='feat.enlarge-spell' />
                      <prereq kind='feat' key='feat.eschew-materials' />
                      <prereq kind='feat' key='feat.silent-spell' />
                      </prereq>
                      </prereq>


                      C. Adding ".inv" to the "kind" attribute

                      <!-- Not this -->
                      <prereq kind='feat.inv' key='feat.eschew-materials' />

                      <!-- Not both -->
                      <prereq kind='mult.inv'>
                      <prereq kind='feat' key='feat.eschew-materials' />
                      <prereq kind='feat' key='feat.silent-spell' />
                      </prereq>

                      <!-- Neither -->
                      <prereq kind='mult.inv' min='1' max='1'>
                      <prereq kind='feat' key='feat.eschew-materials' />
                      <prereq kind='feat' key='feat.silent-spell' />
                      </prereq>

                      <!-- No more than two -->
                      <prereq kind='mult.inv' min='2'>
                      <prereq kind='feat' key='feat.enlarge-spell' />
                      <prereq kind='feat' key='feat.eschew-materials' />
                      <prereq kind='feat' key='feat.silent-spell' />
                      </prereq>


                      2) How would one achieve the Boolean XOR -- e.g., A || B && !(A && B); one or
                      the other but not both -- using the numerical method? Would it have to be
                      written the long way, as follows (I'm using option C for NOT) or is there an
                      easier way that I'm overlooking:

                      <prereq kind='mult'>
                      <prereq kind='mult' min="1" max="1">
                      <prereq kind='feat' key='feat.eschew-materials' />
                      <prereq kind='feat' key='feat.silent-spell' />
                      </prereq>
                      <prereq kind='mult.inv'>
                      <prereq kind='feat' key='feat.eschew-materials' />
                      <prereq kind='feat' key='feat.silent-spell' />
                      </prereq>
                      </prereq>

                      Jenni

                      --
                      Jenni A. M. Merrifield (strawberry @ jamm . com)
                      Software User Experience Professional
                      Designing to Requirements and walking on Water is EASY. . .
                      . . . So long as both are Frozen.
                      --
                    • Jenni A. Merrifield
                      {Oh man....} {Resending with a subject and some comments I left off the end.} {I m really not having much luck with this list lately, am I? :-P}
                      Message 10 of 29 , Apr 17, 2004
                      • 0 Attachment
                        {Oh man....}

                        {Resending with a subject and some comments I left off the end.}

                        {I'm really not having much luck with this list lately, am I? :-P}


                        <quote who="Keith Davies" when="Fri, 16 Apr, 2004 07:23:33 -0700">
                        > On Fri, Apr 16, 2004 at 09:48:16AM +0100, Frugal wrote:
                        > >
                        > > <quote who="Keith Davies">
                        >
                        > [bigsnip]
                        >
                        > > > 'countmult'? I'm still not quite sure what that actually means.
                        > > >
                        > > > <prereq kind='feat' key='feat.weapon-focus' min='2' />
                        > > >
                        > > > means in my schema 'the entity has the Weapon Focus feat at least
                        > > > twice'.
                        > >
                        > > It was to cope with prerequisites like: You must have a total of 20
                        > > ranks in "jump", "balance" and "Tumble" combined.
                        >
                        > Ah, okay.
                        >
                        > > count-multiples="true" effectively means: Instead of returning '1' for
                        > > pass and '0' for fail, return 'n' for pass and '0' for fail where 'n' is
                        > > the total value of the prerequisite:
                        >
                        > Hmm... I'm not sure like changing prereq semantics so they no longer
                        > return pass (true) or fail (false).

                        I would tend to agree. Among User Experience Professionals a guideline we
                        try to enforce is that anything which means one thing in a particular context
                        may only be used in a different context if it will mean exactly the same
                        thing there. Allowing it to be used in a context where it would end up with
                        a different meaning (even only a slightly different meaning) engenders
                        confusion and increases the risk of errors occurring while users are
                        interacting with it.

                        Most UX guidelines have been developed over time based on facts around
                        human physiology and psychology, applicable to all humans - including
                        developers as well as end users. So, if you accept than an XML schema (or an
                        API, a programming language, &c) is a piece of the developer "user
                        experience" then this guideline is one that is worth remembering. ;-)

                        > > <prereq min="20">
                        > > <prereq kind="skill_rank" key="jump" min="1" count-multiples="true"/>
                        > > <prereq kind="skill_rank" key="balance" min="1" count-
                        > > multiples="true"/>
                        > > <prereq kind="skill_rank" key="tumble" min="1" count-
                        > > multiples="true"/>
                        > > </prereq>
                        >
                        > I had a different syntax for this sort of thing, but buggered if I can
                        > remember what it was. Probably something like
                        >
                        > <prereq kind='cumulative-ranks' min='20'>
                        > <progression-ref key='skill.jump' />
                        > <progression-ref key='skill.balance' />
                        > <progression-ref key='skill.tumble' />
                        > </prereq>
                        >
                        > I know it wasn't progression-ref (I've never seen it before in my life,
                        > and it's a lousy name). Still, I think this probably represents the
                        > 'cumulative total' behavior a little more clearly than by nesting
                        > prereqs with changed semantics.

                        Couldn't we do this with additional prereq tags with a kind sent to
                        'skill-rank', and allowing min and max to set limits on how few/man each
                        skill is allowed to supply to the total?

                        Eg: At least 20 cumulative ranks (total-ranks?) from the specified skills,
                        with at least 4 ranks and no more than 10 coming from each one:

                        <prereq kind='cumulative-ranks' min='20'>
                        <prereq kind='skill-ranks' key='skill.jump' min='4' max='10' />
                        <prereq kind='skill-ranks' key='skill.balance' min='4' max='10' />
                        <prereq kind='skill-ranks' key='skill.tumble' min='4' max='10' />
                        </prereq>

                        This is then similar to the format that would be used to set a prerequisite
                        that required at least N ranks in any M of the specified skills:

                        Eg: At least 10 ranks in at least one of the specified skills:

                        <prereq kind='mult' min='1' max='1'>
                        <prereq kind='skill-ranks' key='skill.jump' min='10' />
                        <prereq kind='skill-ranks' key='skill.balance' min='10' />
                        <prereq kind='skill-ranks' key='skill.tumble' min='10' />
                        </prereq>

                        Jenni

                        --
                        Jenni A. M. Merrifield (strawberry @ jamm . com)
                        Software User Experience Professional
                        Designing to Requirements and walking on Water is EASY. . .
                        . . . So long as both are Frozen.
                        --
                      • Jenni A.M. Merrifield
                        ... I realized I made an error when I tried to give negation examples for not more than two . That is best accomplished without needing a negation anyway:
                        Message 11 of 29 , Apr 17, 2004
                        • 0 Attachment
                          > 1) How does one negate the numerical version for prerequisites? I
                          > can think of three options:

                          I realized I made an error when I tried to give "negation"
                          examples for "not more than two". That is best accomplished without
                          needing a negation anyway:

                          <!-- No more than two -->
                          <prereq kind='mult' max='2'>
                          <prereq kind='feat' key='feat.enlarge-spell' />
                          <prereq kind='feat' key='feat.eschew-materials' />
                          <prereq kind='feat' key='feat.heighten-spell' />
                          <prereq kind='feat' key='feat.silent-spell' />
                          </prereq>


                          --
                          Jenni A. M. Merrifield (strawberry @ jamm . com)
                          Software User Experience Professional
                          Designing to Requirements and walking on Water is EASY. . .
                          . . . So long as both are Frozen.
                          --
                        • Frugal
                          ... So instead of a common case where always evaulates to an integer and can only contain objects you want to move
                          Message 12 of 29 , Apr 19, 2004
                          • 0 Attachment
                            <quote who="Keith Davies">
                            > I had a different syntax for this sort of thing, but buggered if I can
                            > remember what it was. Probably something like
                            >
                            > <prereq kind='cumulative-ranks' min='20'>
                            > <progression-ref key='skill.jump' />
                            > <progression-ref key='skill.balance' />
                            > <progression-ref key='skill.tumble' />
                            > </prereq>

                            So instead of a common case where <prereq> always evaulates to an integer
                            and can only contain <prereq> objects you want to move to a system where
                            <prereq> always returns true/false but can contain an arbitrary number of
                            any element.

                            This is exactly what I was trying to get away from, going down this road
                            is what led to the dogs dinner that is the current LST syntax.

                            --
                            regards,
                            Frugal
                            -OS Chimp
                          • Frugal
                            ... No. You can not define to evaluate to {true|false} and then get a minimum of 20 from 3 elements. What
                            Message 13 of 29 , Apr 19, 2004
                            • 0 Attachment
                              <quote who="Jenni A. Merrifield">
                              > Couldn't we do this with additional prereq tags with a kind sent to
                              > 'skill-rank', and allowing min and max to set limits on how few/man each
                              > skill is allowed to supply to the total?
                              >
                              > Eg: At least 20 cumulative ranks (total-ranks?) from the specified
                              > skills,
                              > with at least 4 ranks and no more than 10 coming from each one:
                              >
                              > <prereq kind='cumulative-ranks' min='20'>
                              > <prereq kind='skill-ranks' key='skill.jump' min='4' max='10' />
                              > <prereq kind='skill-ranks' key='skill.balance' min='4' max='10' />
                              > <prereq kind='skill-ranks' key='skill.tumble' min='4' max='10' />
                              > </prereq>

                              No. You can not define <prereq> to evaluate to {true|false} and then get a
                              minimum of "20" from 3 <prereq> elements.

                              What you presented will evaulate to:
                              <prereq kind="cumulative-ranks" min="30">
                              <true|false>
                              <true|false>
                              <true|false>
                              </prereq>

                              How do you propose to get a min of "30" cumulative ranks from 3 true/false
                              values.

                              What you are trying to do is exactly the same thing that I did exlpicitly,
                              but you are trying to do do it by side effect.

                              --
                              regards,
                              Frugal
                              -OS Chimp
                            • Jenni A. Merrifield
                              Message 14 of 29 , Apr 19, 2004
                              • 0 Attachment
                                <quote who="Frugal" when="Mon, 19 Apr 2004 09:04:47 +0100 (BST)"
                                > <quote who="Jenni A. Merrifield">
                                > > Couldn't we do this with additional prereq tags with a kind sent to
                                > > 'skill-rank', and allowing min and max to set limits on how few/man each
                                > > skill is allowed to supply to the total?
                                > >
                                > > Eg: At least 20 cumulative ranks (total-ranks?) from the specified
                                > > skills,
                                > > with at least 4 ranks and no more than 10 coming from each one:
                                > >
                                > > <prereq kind='cumulative-ranks' min='20'>
                                > > <prereq kind='skill-ranks' key='skill.jump' min='4' max='10' />
                                > > <prereq kind='skill-ranks' key='skill.balance' min='4' max='10' />
                                > > <prereq kind='skill-ranks' key='skill.tumble' min='4' max='10' />
                                > > </prereq>
                                >
                                > No. You can not define <prereq> to evaluate to {true|false} and then get a
                                > minimum of "20" from 3 <prereq> elements.
                                >
                                > What you presented will evaulate to:
                                > <prereq kind="cumulative-ranks" min="30">
                                > <true|false>
                                > <true|false>
                                > <true|false>
                                > </prereq>
                                >
                                > How do you propose to get a min of "30" cumulative ranks from 3 true/false
                                > values.

                                D'oh! Despite reading Keith's previous email about "always true/false" I
                                was still expecting numerical values to be output from the prereq tags.

                                Keith: In a true/false context, usually any value != 0 is considered
                                "false". Thus, even if a prereq tag *does* return an appropriate count
                                (number of times a character has the feat, the number of ranks held in a
                                skill, &c. -- basically whatever was appropriate) whenever the stated
                                prerequisite was met and always returns a zero value whenever the
                                prerequisite wasn't met, it can still be evaluated as "true/false" if that's
                                all that mattered (i.e., does or doesn't the character meet the prereq).
                                However, this also allows (as in the example above) cumulative scores when
                                that's what matters.

                                This would keeps the syntax consistent across the board: prereq always
                                contains prereq (avoiding the "dogs dinner" of LST syntax as you so aptly put
                                it), eliminates the need for any "countmultiples" attribute (multiples are
                                always counted) AND if all you want is true/false you just ignore the
                                magnitude of a succesful return values in most cases (where all that matters
                                is "is it false (0) or is it true (not 0)").

                                What do you think?

                                Jenni

                                --
                                Jenni A. M. Merrifield (strawberry @ jamm . com)
                                Software User Experience Professional
                                Designing to Requirements and walking on Water is EASY. . .
                                . . . So long as both are Frozen.
                                --
                              • Brass Tilde
                                ... Did you mean to say true there? Unless usually doesn t include languages such as C/C++, where zero is false and non-zero is true. Or did I
                                Message 15 of 29 , Apr 19, 2004
                                • 0 Attachment
                                  > Keith: In a true/false context, usually any value != 0 is considered
                                  > "false".

                                  Did you mean to say "true" there? Unless "usually" doesn't include
                                  languages such as C/C++, where zero is false and non-zero is true.

                                  Or did I misinterpret?
                                • Frugal
                                  ... Which takes us back to the way I originally proposed that everyone disliked ;O) ... You still need to have a flag to
                                  Message 16 of 29 , Apr 19, 2004
                                  • 0 Attachment
                                    <quote who="Jenni A. Merrifield">
                                    > <quote who="Frugal" when="Mon, 19 Apr 2004 09:04:47 +0100 (BST)"
                                    >> No. You can not define <prereq> to evaluate to {true|false} and then get
                                    >> a
                                    >> minimum of "20" from 3 <prereq> elements.
                                    >>
                                    >> What you presented will evaulate to:
                                    >> <prereq kind="cumulative-ranks" min="30">
                                    >> <true|false>
                                    >> <true|false>
                                    >> <true|false>
                                    >> </prereq>
                                    >>
                                    >> How do you propose to get a min of "30" cumulative ranks from 3
                                    >> true/false
                                    >> values.
                                    >
                                    > D'oh! Despite reading Keith's previous email about "always true/false"
                                    > I
                                    > was still expecting numerical values to be output from the prereq tags.
                                    >
                                    > Keith: In a true/false context, usually any value != 0 is considered
                                    > "false". Thus, even if a prereq tag *does* return an appropriate count
                                    > (number of times a character has the feat, the number of ranks held in a
                                    > skill, &c. -- basically whatever was appropriate) whenever the stated
                                    > prerequisite was met and always returns a zero value whenever the
                                    > prerequisite wasn't met, it can still be evaluated as "true/false" if
                                    > that's
                                    > all that mattered (i.e., does or doesn't the character meet the prereq).
                                    > However, this also allows (as in the example above) cumulative scores when
                                    > that's what matters.

                                    Which takes us back to the way I originally proposed that everyone
                                    disliked ;O)

                                    > This would keeps the syntax consistent across the board: prereq always
                                    > contains prereq (avoiding the "dogs dinner" of LST syntax as you so aptly
                                    > put
                                    > it), eliminates the need for any "countmultiples" attribute (multiples are
                                    > always counted) AND if all you want is true/false you just ignore the
                                    > magnitude of a succesful return values in most cases (where all that
                                    > matters
                                    > is "is it false (0) or is it true (not 0)").

                                    You still need to have a flag to count the multiples otherwise it is
                                    impossible to tell the difference between

                                    <!-- at least 20 ranks in total in Balance, Jump and Climb -->
                                    <prereq kind="mult" operator="gteq" operand="20">
                                    <prereq kind="skill.ranks" key="balance" operator="gteq" operand="1"/>
                                    <prereq kind="skill.ranks" key="climb" operator="gteq" operand="1"/>
                                    <prereq kind="skill.ranks" key="jump" operator="gteq" operand="1"/>
                                    </prereq>

                                    and

                                    <!-- must have ranks in at least 2 of Balance, Jump or Climb -->
                                    <prereq kind="mult" operator="gteq" operand="2">
                                    <prereq kind="skill.ranks" key="balance" operator="gteq" operand="1"/>
                                    <prereq kind="skill.ranks" key="climb" operator="gteq" operand="1"/>
                                    <prereq kind="skill.ranks" key="jump" operator="gteq" operand="1"/>
                                    </prereq>


                                    If you always return multiples then you can pass the second one by having
                                    at least 2 ranks in a 1 skill rather than by having at least 1 rank in at
                                    least 2 skills. If you always return 0/1 then you can never satisfy the
                                    first example...

                                    --
                                    regards,
                                    Frugal
                                    -OS Chimp
                                  • Keith Davies
                                    ... I think you contradicted yourself above (I split the paragraphs to make it more evident). 0 is often interpreted as false, non-zero as true. ... I never
                                    Message 17 of 29 , Apr 19, 2004
                                    • 0 Attachment
                                      On Mon, Apr 19, 2004 at 07:13:18AM -0700, Jenni A. Merrifield wrote:
                                      > <quote who="Frugal" when="Mon, 19 Apr 2004 09:04:47 +0100 (BST)"
                                      > > <quote who="Jenni A. Merrifield">
                                      > > > Couldn't we do this with additional prereq tags with a kind sent to
                                      > > > 'skill-rank', and allowing min and max to set limits on how few/man each
                                      > > > skill is allowed to supply to the total?
                                      > > >
                                      > > > Eg: At least 20 cumulative ranks (total-ranks?) from the specified
                                      > > > skills,
                                      > > > with at least 4 ranks and no more than 10 coming from each one:
                                      > > >
                                      > > > <prereq kind='cumulative-ranks' min='20'>
                                      > > > <prereq kind='skill-ranks' key='skill.jump' min='4' max='10' />
                                      > > > <prereq kind='skill-ranks' key='skill.balance' min='4' max='10' />
                                      > > > <prereq kind='skill-ranks' key='skill.tumble' min='4' max='10' />
                                      > > > </prereq>
                                      > >
                                      > > No. You can not define <prereq> to evaluate to {true|false} and then get a
                                      > > minimum of "20" from 3 <prereq> elements.
                                      > >
                                      > > What you presented will evaulate to:
                                      > > <prereq kind="cumulative-ranks" min="30">
                                      > > <true|false>
                                      > > <true|false>
                                      > > <true|false>
                                      > > </prereq>
                                      > >
                                      > > How do you propose to get a min of "30" cumulative ranks from 3 true/false
                                      > > values.
                                      >
                                      > D'oh! Despite reading Keith's previous email about "always
                                      > true/false" I was still expecting numerical values to be output from
                                      > the prereq tags.
                                      >
                                      > Keith: In a true/false context, usually any value != 0 is considered
                                      > "false".
                                      >
                                      > Thus, even if a prereq tag *does* return an appropriate count (number
                                      > of times a character has the feat, the number of ranks held in a
                                      > skill, &c. -- basically whatever was appropriate) whenever the stated
                                      > prerequisite was met and always returns a zero value whenever the
                                      > prerequisite wasn't met, it can still be evaluated as "true/false" if
                                      > that's all that mattered (i.e., does or doesn't the character meet the
                                      > prereq). However, this also allows (as in the example above)
                                      > cumulative scores when that's what matters.

                                      I think you contradicted yourself above (I split the paragraphs to make
                                      it more evident). 0 is often interpreted as false, non-zero as true.

                                      > This would keeps the syntax consistent across the board: prereq
                                      > always contains prereq (avoiding the "dogs dinner" of LST syntax as
                                      > you so aptly put it), eliminates the need for any "countmultiples"
                                      > attribute (multiples are always counted) AND if all you want is
                                      > true/false you just ignore the magnitude of a succesful return
                                      > values in most cases (where all that matters is "is it false (0) or
                                      > is it true (not 0)").

                                      I never called it a dogs dinner. I don't disagree, but someone else
                                      said that.

                                      > What do you think?

                                      As a predominantly C++ programmer and Perl scripter I am comfortable
                                      with the idea of 0/non-0 examination for false/true. However, in this
                                      model <prereq> is doing two things, and now neither of them is
                                      particularly obvious.

                                      0/non-0 examination, while easy for many people to understand, is not as
                                      obvious as false/true values (that's why Java got rid of implicit
                                      conversion of int to boolean). Also, you now have prereqs performing
                                      calculations; that's not what they're for, but people will use them that
                                      way.

                                      Two non-obvious things. One of them can do what was originally
                                      intended, but with an extra step that could be overlooked. At this
                                      point I don't think it is the correct way to go. I am willing to
                                      reconsider if someone presents a convincing argument.

                                      Personally, I'd rather see

                                      <prereq kind='cumulative' min='20'>
                                      <count kind='skill-ranks' key='skill.jump' />
                                      <count kind='skill-ranks' key='skill.balance' />
                                      <count kind='skill-ranks' key='skill.tumble' />
                                      </prereq>

                                      If there are further requirements (such as 'each skill must have at
                                      least four and no more than ten ranks') then treat those as separate
                                      prereqs:

                                      <prereq kind='mult'>
                                      <prereq kind='cumulative' min='20'>
                                      <count kind='skill-ranks' key='skill.jump' />
                                      <count kind='skill-ranks' key='skill.balance' />
                                      <count kind='skill-ranks' key='skill.tumble' />
                                      </prereq>
                                      <prereq kind='skill-ranks' key='skill.jump' min='4' max='10' />
                                      <prereq kind='skill-ranks' key='skill.balance' min='4' max='10' />
                                      <prereq kind='skill-ranks' key='skill.tumble' min='4' max='10' />
                                      </prereq>

                                      This keeps the semantics of each element fairly simple. This looks like
                                      a very odd case here, and I don't like to complicate the general model
                                      to make it more convenient -- but less clear -- to encode something I
                                      don't expect to happen.


                                      Keith
                                      --
                                      Keith Davies I gave my 2yo daughter a strawberry
                                      keith.davies@... Naomi: "Strawberry!"
                                      me: "What do you say?"
                                      Naomi: "*MY* strawberry!"
                                    • Keith Davies
                                      ... Misspoke, I think. She was pretty consistent about 0 == false, !0 == true later. Keith -- Keith Davies I gave my 2yo daughter a strawberry
                                      Message 18 of 29 , Apr 19, 2004
                                      • 0 Attachment
                                        On Mon, Apr 19, 2004 at 10:21:28AM -0400, Brass Tilde wrote:
                                        > > Keith: In a true/false context, usually any value != 0 is considered
                                        > > "false".
                                        >
                                        > Did you mean to say "true" there? Unless "usually" doesn't include
                                        > languages such as C/C++, where zero is false and non-zero is true.
                                        >
                                        > Or did I misinterpret?

                                        Misspoke, I think. She was pretty consistent about 0 == false,
                                        !0 == true later.


                                        Keith
                                        --
                                        Keith Davies I gave my 2yo daughter a strawberry
                                        keith.davies@... Naomi: "Strawberry!"
                                        me: "What do you say?"
                                        Naomi: "*MY* strawberry!"
                                      • Keith Davies
                                        ... in her example. It is flagged. ... Her example would work. It s predicated on the always returning a
                                        Message 19 of 29 , Apr 19, 2004
                                        • 0 Attachment
                                          On Mon, Apr 19, 2004 at 03:25:51PM +0100, Frugal wrote:
                                          > <quote who="Jenni A. Merrifield">
                                          > > <quote who="Frugal" when="Mon, 19 Apr 2004 09:04:47 +0100 (BST)"
                                          > >> No. You can not define <prereq> to evaluate to {true|false} and then get
                                          > >> a
                                          > >> minimum of "20" from 3 <prereq> elements.
                                          > >>
                                          > >> What you presented will evaulate to:
                                          > >> <prereq kind="cumulative-ranks" min="30">
                                          > >> <true|false>
                                          > >> <true|false>
                                          > >> <true|false>
                                          > >> </prereq>
                                          > >>
                                          > >> How do you propose to get a min of "30" cumulative ranks from 3
                                          > >> true/false
                                          > >> values.
                                          > >
                                          > > D'oh! Despite reading Keith's previous email about "always true/false"
                                          > > I
                                          > > was still expecting numerical values to be output from the prereq tags.
                                          > >
                                          > > Keith: In a true/false context, usually any value != 0 is considered
                                          > > "false". Thus, even if a prereq tag *does* return an appropriate count
                                          > > (number of times a character has the feat, the number of ranks held in a
                                          > > skill, &c. -- basically whatever was appropriate) whenever the stated
                                          > > prerequisite was met and always returns a zero value whenever the
                                          > > prerequisite wasn't met, it can still be evaluated as "true/false" if
                                          > > that's
                                          > > all that mattered (i.e., does or doesn't the character meet the prereq).
                                          > > However, this also allows (as in the example above) cumulative scores when
                                          > > that's what matters.
                                          >
                                          > Which takes us back to the way I originally proposed that everyone
                                          > disliked ;O)
                                          >
                                          > > This would keeps the syntax consistent across the board: prereq always
                                          > > contains prereq (avoiding the "dogs dinner" of LST syntax as you so aptly
                                          > > put
                                          > > it), eliminates the need for any "countmultiples" attribute (multiples are
                                          > > always counted) AND if all you want is true/false you just ignore the
                                          > > magnitude of a succesful return values in most cases (where all that
                                          > > matters
                                          > > is "is it false (0) or is it true (not 0)").
                                          >
                                          > You still need to have a flag to count the multiples otherwise it is
                                          > impossible to tell the difference between
                                          >
                                          > <!-- at least 20 ranks in total in Balance, Jump and Climb -->
                                          > <prereq kind="mult" operator="gteq" operand="20">
                                          > <prereq kind="skill.ranks" key="balance" operator="gteq" operand="1"/>
                                          > <prereq kind="skill.ranks" key="climb" operator="gteq" operand="1"/>
                                          > <prereq kind="skill.ranks" key="jump" operator="gteq" operand="1"/>
                                          > </prereq>

                                          <prereq kind='cumulative-ranks' min='20' />

                                          in her example. It is flagged.

                                          > and
                                          >
                                          > <!-- must have ranks in at least 2 of Balance, Jump or Climb -->
                                          > <prereq kind="mult" operator="gteq" operand="2">
                                          > <prereq kind="skill.ranks" key="balance" operator="gteq" operand="1"/>
                                          > <prereq kind="skill.ranks" key="climb" operator="gteq" operand="1"/>
                                          > <prereq kind="skill.ranks" key="jump" operator="gteq" operand="1"/>
                                          > </prereq>
                                          >
                                          > If you always return multiples then you can pass the second one by having
                                          > at least 2 ranks in a 1 skill rather than by having at least 1 rank in at
                                          > least 2 skills. If you always return 0/1 then you can never satisfy the
                                          > first example...

                                          Her example would work. It's predicated on the <prereq> always
                                          returning a numerical value that can be examined to determine the truth
                                          of the <prereq>. How these are interpreted depends on the parent.

                                          If parent/@kind is 'mult' it looks at the truth of the children and
                                          counts. If parent/@kind is 'cumulative-ranks' it adds up the value of
                                          the children and examines the total. It presumably passes that total
                                          on.

                                          Ewww... if the test fails it must by definition return 0, but if not has
                                          the option of passing back 1 (true) or the cumulative number of ranks
                                          (20+). Anyone else see people abusing this function and complaining
                                          when it doesn't work right?

                                          As far as I know, <prereq> will work correctly if it returns true or
                                          false only for *all* cases except when nested for the purpose of
                                          determining cumulative totals. When examining cumulative totals,
                                          though, the individual values that go into are not prerequisites but
                                          operands; they do not themselves have true or false values, just numeric
                                          (which can be interpreted as true and false under some circumstances, I
                                          know). That the example shows them also being used as actual prereqs
                                          (4 <= ranks <= 10) I think confuses the matter, as the model is showing
                                          it being used for two things at once, rather than splitting them.

                                          The English text of the combination might be:

                                          "At least 20 ranks in Balance, Jump, and Tumble, with at least four
                                          ranks and no more than ten ranks in each."

                                          This is most cleanly encoded as two (sets of) prereqs. The first
                                          handles the first clause:

                                          <prereq kind='cumulative' min='20'>
                                          <value kind='skill-ranks' key='skill.balance' />
                                          <value kind='skill-ranks' key='skill.jump' />
                                          <value kind='skill-ranks' key='skill.tumble' />
                                          </prereq>

                                          and the second handles the second clause:

                                          <prereq kind='skill-ranks' key='skill.balance' min='4' max='10' />
                                          <prereq kind='skill-ranks' key='skill.jump' min='4' max='10' />
                                          <prereq kind='skill-ranks' key='skill.tumble' min='4' max='10' />

                                          This provides the cleanest encoding of the information and the clearest,
                                          with no overloading of terms or element interpretation.


                                          Keith
                                          --
                                          Keith Davies I gave my 2yo daughter a strawberry
                                          keith.davies@... Naomi: "Strawberry!"
                                          me: "What do you say?"
                                          Naomi: "*MY* strawberry!"
                                        • Keith Davies
                                          ... In the absence of a better way of describing this sort of prerequisite, I m willing to bend on prereqs contain only prereqs , if it is necessary to encode
                                          Message 20 of 29 , Apr 19, 2004
                                          • 0 Attachment
                                            On Mon, Apr 19, 2004 at 08:59:38AM +0100, Frugal wrote:
                                            > <quote who="Keith Davies">
                                            > > I had a different syntax for this sort of thing, but buggered if I can
                                            > > remember what it was. Probably something like
                                            > >
                                            > > <prereq kind='cumulative-ranks' min='20'>
                                            > > <progression-ref key='skill.jump' />
                                            > > <progression-ref key='skill.balance' />
                                            > > <progression-ref key='skill.tumble' />
                                            > > </prereq>
                                            >
                                            > So instead of a common case where <prereq> always evaulates to an integer
                                            > and can only contain <prereq> objects you want to move to a system where
                                            > <prereq> always returns true/false but can contain an arbitrary number of
                                            > any element.
                                            >
                                            > This is exactly what I was trying to get away from, going down this road
                                            > is what led to the dogs dinner that is the current LST syntax.

                                            In the absence of a better way of describing this sort of prerequisite,
                                            I'm willing to bend on 'prereqs contain only prereqs', if it is
                                            necessary to encode this sort of thing. I don't want to allow 'any'
                                            element, but allowing <prereq> to contain an element that can do what
                                            <prereq> is designed not to... while it should be avoided when possible,
                                            should not be outright verboten, I think.

                                            And yes, I know that the two examples I posted today use different names
                                            for the child element. I've got a cold.


                                            Keith
                                            --
                                            Keith Davies I gave my 2yo daughter a strawberry
                                            keith.davies@... Naomi: "Strawberry!"
                                            me: "What do you say?"
                                            Naomi: "*MY* strawberry!"
                                          • Keith Davies
                                            ... It fails, though, if only max is set (oops). I need something like if (minSet) { min = attribs.getAttrib( min ); } if (maxSet) { max = attribs.getAttrib(
                                            Message 21 of 29 , Apr 19, 2004
                                            • 0 Attachment
                                              On Fri, Apr 16, 2004 at 06:46:32PM -0700, Jenni A. Merrifield wrote:
                                              > {Double-Bah. I just realized this other message, which was actually written
                                              > before either of my last two, never showed up on the list. If any of my
                                              > comments referring to my own previous comments seemed confusing, this might
                                              > explain why. :-P }
                                              >
                                              > <quote who="Keith Davies" when="Tue, 13 Apr 2004 12:04:53 -0700">
                                              > > On Tue, Apr 13, 2004 at 07:06:51AM -0700, Jenni A. Merrifield wrote:
                                              > > >
                                              > > > Is there any particular reason, with this *internal* data
                                              > > > representation, to avoid using traditional Boolean operators such as
                                              > > > "AND", "OR", "XOR" and "NOT"? Using it, we could be quite sure of what
                                              > > > prerequisites were being requested and their relationships to each other.
                                              > >
                                              > > I'd be willing to use this for the external data representation; I was
                                              > > using 'min' and 'max' to allow for 'at least two of the following' (or
                                              > > 'no more than two of the following', for that matter) cases. The same
                                              > > mechanism would successfully deal with the cases described below, so I
                                              > > didn't bother pursuing your suggestion (I *did* think of it, but numbers
                                              > > served the same purpose across more cases).
                                              >
                                              > [...SNIP...]
                                              >
                                              > > Your suggestion is probably simpler in most cases; I'd be willing to use
                                              > > it. The only thing it fails to handle (as written) is the 'n of m'
                                              > > case, and even that can be handled by another operand
                                              > >
                                              > > <prereq kind='mult' operand='select' min='2'>
                                              > > <prereq kind='alignment' key='lawful.good' />
                                              > > <prereq kind='feat' key='feat.eschew-materials' />
                                              > > <prereq kind='feat' key='feat.silent-spell' />
                                              > > </prereq>
                                              > >
                                              > > 'select' is a lousy operand name, need a better one.
                                              >
                                              > How about one of:
                                              >
                                              > * "selection"
                                              > * "pick" <-- I like this one
                                              > * "choose" <-- this would be familiar to LST writers
                                              > * "choice"
                                              > * "subset"
                                              >
                                              > > Still, I like the numbers version better -- it's a little clearer what's
                                              > > going on and can be implemented using a single chain of logic:
                                              > >
                                              > > min = numChildren;
                                              > > max = numChildren;
                                              > > if (minSet) {
                                              > > min = attribs.getAttrib( "min");
                                              > > }
                                              > > if (maxSet) {
                                              > > max = attribs.getAttrib( "max");
                                              > > }
                                              > > childrenMatched = checkPrereqs( entity, children);
                                              > > if ((min <= childrenMatched) &&
                                              > > (childrenMatched <= max)) {
                                              > > doWePassed();
                                              > > } else {
                                              > > doWeFailed();
                                              > > }
                                              > >
                                              > > This does not require string examination of the operand attribute, nor
                                              > > the logic necessary to handle the various cases.
                                              >
                                              > Your algorithmic argument is a fairly good one - the lack of a need
                                              > to do string examination would probably make it somewhat more
                                              > performant.

                                              It fails, though, if only max is set (oops). I need something like

                                              if (minSet) {
                                              min = attribs.getAttrib( "min");
                                              }
                                              if (maxSet) {
                                              max = attribs.getAttrib( "max");
                                              if (!minSet) {
                                              min = max;
                                              }
                                              }

                                              so that we don't require something that can't happen.

                                              > > The 'and' case is
                                              > > implicit (if min and max aren't set, it requires all children to pass),
                                              > > the 'or' case is handled as '1 of m', and it handles both 'n of m' and
                                              > > 'no more than n of m' cases consistently.
                                              >
                                              > With Boolean terms "and" would still be implicit if there is no operator
                                              > and no min or max.

                                              This is (to date) the normal case, though variable prereqs are becoming
                                              more popular (this feat or this class, plus these conditions)

                                              > In addition "pick"/"choose" is almost implicit if there is no operator
                                              > but there is a min and/or a max (e.g., a subset of the options must
                                              > apply for the prereq to apply)

                                              It is, but let's make it explicit anyway.

                                              > > I'd be willing to use 'and' or 'or' operands, but this is, IMO, more
                                              > > elegant, consistent, and simpler to implement and use.
                                              >
                                              > Perhaps you are right. It would definitely seem to be more consistent.
                                              >
                                              > Two remaining questions:
                                              >
                                              > 1) How does one negate the numerical version for prerequisites? I can think
                                              > of three options:
                                              >
                                              > A. A "not" or "inv" attribute set to "1" when it applies:
                                              >
                                              > <!-- Not this -->
                                              > <prereq kind='feat' inv='1' key='feat.eschew-materials' />

                                              <prereq kind='feat' key='feat.eschew-materials' max='0'/>

                                              > <!-- Not both -->
                                              > <prereq kind='mult' inv='1'>
                                              > <prereq kind='feat' key='feat.eschew-materials' />
                                              > <prereq kind='feat' key='feat.silent-spell' />
                                              > </prereq>

                                              This one passes when neither feat is available.

                                              <prereq kind='mult' min='1' max='1'>
                                              <prereq kind='feat' key='feat.eschew-materials' />
                                              <prereq kind='feat' key='feat.silent-spell' />
                                              </prereq>

                                              > <!-- Neither -->
                                              > <prereq kind='mult' min='1' max='1' inv='1'>
                                              > <prereq kind='feat' key='feat.eschew-materials' />
                                              > <prereq kind='feat' key='feat.silent-spell' />
                                              > </prereq>

                                              Both available, or none?

                                              <prereq kind='mult' min='1' max='1'>
                                              <prereq kind='mult' min='2'>
                                              <prereq kind='feat' key='feat.eschew-materials' />
                                              <prereq kind='feat' key='feat.silent-spell' />
                                              </prereq>
                                              <prereq kind='mult' max='0'>
                                              <prereq kind='feat' key='feat.eschew-materials' />
                                              <prereq kind='feat' key='feat.silent-spell' />
                                              </prereq>
                                              </prereq>

                                              Yuck. Better might be

                                              <prereq kind='mult' max='0'>
                                              <prereq kind='mult' min='1' max='1'>
                                              <prereq kind='feat' key='feat.eschew-materials' />
                                              <prereq kind='feat' key='feat.silent-spell' />
                                              </prereq>
                                              </prereq>

                                              That's a little unobvious, but it is consistent with other behavior.

                                              I am *considering* allowing:

                                              <prereq kind='mult' min='2' max='0'>
                                              <prereq kind='feat' key='feat.eschew-materials' />
                                              <prereq kind='feat' key='feat.silent-spell' />
                                              </prereq>

                                              It's... not something I'm happy about yet. However, I am willing to
                                              consider the case of 'min > max' to mean 'outside the defined range'. I
                                              don't know that it comes up often enough to be worth it, though.

                                              > <!-- No more than two -->
                                              > <prereq kind='mult' min='2' inv='1'>
                                              > <prereq kind='feat' key='feat.enlarge-spell' />
                                              > <prereq kind='feat' key='feat.eschew-materials' />
                                              > <prereq kind='feat' key='feat.silent-spell' />
                                              > </prereq>

                                              <prereq kind='mult' max='2'>
                                              <prereq kind='feat' key='feat.enlarge-spell' />
                                              <prereq kind='feat' key='feat.eschew-materials' />
                                              <prereq kind='feat' key='feat.silent-spell' />
                                              </prereq>


                                              > B. A "kind" attribute with the value "not"

                                              Possibly, though it's synonymous with "kind='mult' max='0'"

                                              > <!-- Not this -->
                                              > <prereq kind='not'>
                                              > <prereq kind='feat' inv='1' key='feat.eschew-materials' />
                                              > </prereq>

                                              probably meant

                                              <prereq kind='feat' key='feat.eschew-materials' />

                                              here. (You left the @inv in when you cut&paste.)

                                              > <!-- Not Both -->
                                              > <prereq kind='not'>
                                              > <prereq kind='mult'>
                                              > <prereq kind='feat' key='feat.eschew-materials' />
                                              > <prereq kind='feat' key='feat.silent-spell' />
                                              > </prereq>
                                              > </prereq>

                                              You could say

                                              <prereq kind='mult' max='0'>
                                              <prereq kind='mult'>
                                              <prereq kind='feat' key='feat.eschew-materials' />
                                              <prereq kind='feat' key='feat.silent-spell' />
                                              </prereq>
                                              </prereq>

                                              But it's even simpler to say

                                              <prereq kind='mult' max='1'>
                                              <prereq kind='feat' key='feat.eschew-materials' />
                                              <prereq kind='feat' key='feat.silent-spell' />
                                              </prereq>

                                              '0 or 1 of the following, but not 2'.

                                              I made a mistake in the pseudocode I showed in another message; if min
                                              is not set but max is, min should be set to 0, not max. It makes more
                                              sense that 'max alone' means 'there is a maximum, but no minimum',
                                              especially since 'min alone' effectively means 'there is a minimum, but
                                              no maximum'. If neither is set, all are required, so min = max = number
                                              of children.

                                              > <!-- Neither -->
                                              > <prereq kind='not'>
                                              > <prereq kind='mult' min='1' max='1'>
                                              > <prereq kind='feat' key='feat.eschew-materials' />
                                              > <prereq kind='feat' key='feat.silent-spell' />
                                              > </prereq>
                                              > </prereq>

                                              <prereq kind='mult' max='0'>
                                              <prereq kind='feat' key='feat.eschew-materials' />
                                              <prereq kind='feat' key='feat.silent-spell' />
                                              </prereq>

                                              Your will say 'both or neither', probably not what you meant.

                                              > <!-- No more than two -->
                                              > <prereq kind='not'>
                                              > <prereq kind='mult' min='2'>
                                              > <prereq kind='feat' key='feat.enlarge-spell' />
                                              > <prereq kind='feat' key='feat.eschew-materials' />
                                              > <prereq kind='feat' key='feat.silent-spell' />
                                              > </prereq>
                                              > </prereq>

                                              <prereq kind='mult' max='2'>
                                              <prereq kind='feat' key='feat.enlarge-spell' />
                                              <prereq kind='feat' key='feat.eschew-materials' />
                                              <prereq kind='feat' key='feat.silent-spell' />
                                              </prereq>


                                              > C. Adding ".inv" to the "kind" attribute

                                              No, evil. No parsing of @kind.


                                              > 2) How would one achieve the Boolean XOR -- e.g., A || B && !(A && B); one or
                                              > the other but not both -- using the numerical method? Would it have to be
                                              > written the long way, as follows (I'm using option C for NOT) or is there an
                                              > easier way that I'm overlooking:
                                              >
                                              > <prereq kind='mult'>
                                              > <prereq kind='mult' min="1" max="1">
                                              > <prereq kind='feat' key='feat.eschew-materials' />
                                              > <prereq kind='feat' key='feat.silent-spell' />
                                              > </prereq>
                                              > <prereq kind='mult.inv'>
                                              > <prereq kind='feat' key='feat.eschew-materials' />
                                              > <prereq kind='feat' key='feat.silent-spell' />
                                              > </prereq>
                                              > </prereq>

                                              <prereq kind='mult' min="1" max="1">
                                              <prereq kind='feat' key='feat.eschew-materials' />
                                              <prereq kind='feat' key='feat.silent-spell' />
                                              </prereq>

                                              is sufficient -- this is true if and only if one of the children is
                                              true, which in this case matches "(A || B) && !(A && B)". If you went
                                              three-way XOR, though, it'd be uglier... but I don't think it'll come
                                              up. In fact, I don't recall ever seeing an XOR prereq, though I'll
                                              posit their existence.


                                              Keith
                                              --
                                              Keith Davies I gave my 2yo daughter a strawberry
                                              keith.davies@... Naomi: "Strawberry!"
                                              me: "What do you say?"
                                              Naomi: "*MY* strawberry!"
                                            • Keith Davies
                                              ... This was incorrect; it doesn t follow the expected semantics (nor does my later correction, gah). What I *should* have had was: min = numChildren; max =
                                              Message 22 of 29 , Apr 19, 2004
                                              • 0 Attachment
                                                --- In pcgen-xml@yahoogroups.com, Keith Davies <keith.davies@k...>
                                                wrote:

                                                > min = numChildren;
                                                > max = numChildren;
                                                > if (minSet) {
                                                > min = attribs.getAttrib( "min");
                                                > }
                                                > if (maxSet) {
                                                > max = attribs.getAttrib( "max");
                                                > }
                                                > childrenMatched = checkPrereqs( entity, children);
                                                > if ((min <= childrenMatched) &&
                                                > (childrenMatched <= max)) {
                                                > doWePassed();
                                                > } else {
                                                > doWeFailed();
                                                > }

                                                This was incorrect; it doesn't follow the expected semantics (nor
                                                does my later correction, gah). What I *should* have had was:

                                                min = numChildren;
                                                max = numChildren;
                                                if (minSet) {
                                                min = attribs.getAttrib( "min");
                                                }
                                                if (maxSet) {
                                                max = attribs.getAttrib( "max");
                                                if (!minSet) {
                                                min = 0;
                                                }
                                                }
                                                childrenMatched = checkPrereqs( entity, children);
                                                if ((min <= childrenMatched) &&
                                                (childrenMatched <= max)) {
                                                doWePassed();
                                                } else {
                                                doWeFailed();
                                                }

                                                This correctly matches the logic:

                                                . if min and max are unset, all are required
                                                . if min is set and not max, at least min are required (the
                                                implicit 'no more than max' still works).
                                                . if max is set and not min, then it should be read as 'no more
                                                than max'; there is no minimum. I was handling this case
                                                incorrectly.
                                                . if min and max are set, min <= count <= max.
                                                . I have considered -- but don't like -- interpreting min and
                                                max set, but min > max, to mean 'min <= count || count <= max'
                                                but I'm not yet comfortable with it.


                                                Keith [posted via web]
                                              • Keith Davies
                                                ... *Still* not right. That describes equals behavior, not no more than . if (minSet) { min = attribs.getAttrib( min ); } if (maxSet) { max =
                                                Message 23 of 29 , Apr 19, 2004
                                                • 0 Attachment
                                                  On Mon, Apr 19, 2004 at 08:49:57AM -0700, Keith Davies wrote:
                                                  > On Fri, Apr 16, 2004 at 06:46:32PM -0700, Jenni A. Merrifield wrote:
                                                  > >
                                                  > > > Still, I like the numbers version better -- it's a little clearer what's
                                                  > > > going on and can be implemented using a single chain of logic:
                                                  > > >
                                                  > > > min = numChildren;
                                                  > > > max = numChildren;
                                                  > > > if (minSet) {
                                                  > > > min = attribs.getAttrib( "min");
                                                  > > > }
                                                  > > > if (maxSet) {
                                                  > > > max = attribs.getAttrib( "max");
                                                  > > > }
                                                  > > > childrenMatched = checkPrereqs( entity, children);
                                                  > > > if ((min <= childrenMatched) &&
                                                  > > > (childrenMatched <= max)) {
                                                  > > > doWePassed();
                                                  > > > } else {
                                                  > > > doWeFailed();
                                                  > > > }
                                                  > > >
                                                  > > > This does not require string examination of the operand attribute, nor
                                                  > > > the logic necessary to handle the various cases.
                                                  > >
                                                  > > Your algorithmic argument is a fairly good one - the lack of a need
                                                  > > to do string examination would probably make it somewhat more
                                                  > > performant.
                                                  >
                                                  > It fails, though, if only max is set (oops). I need something like
                                                  >
                                                  > if (minSet) {
                                                  > min = attribs.getAttrib( "min");
                                                  > }
                                                  > if (maxSet) {
                                                  > max = attribs.getAttrib( "max");
                                                  > if (!minSet) {
                                                  > min = max;
                                                  > }
                                                  > }

                                                  *Still* not right. That describes 'equals' behavior, not 'no more
                                                  than'.

                                                  if (minSet) {
                                                  min = attribs.getAttrib( "min");
                                                  }
                                                  if (maxSet) {
                                                  max = attribs.getAttrib( "max");
                                                  if (!minSet) {
                                                  min = 0;
                                                  }
                                                  }

                                                  This one has it right. Finally.


                                                  Keith
                                                  --
                                                  Keith Davies I gave my 2yo daughter a strawberry
                                                  keith.davies@... Naomi: "Strawberry!"
                                                  me: "What do you say?"
                                                  Naomi: "*MY* strawberry!"
                                                • Frugal
                                                  ... I have never seen you take so long to get something right, go away and take something for your cold ;O) I recommend a large
                                                  Message 24 of 29 , Apr 20, 2004
                                                  • 0 Attachment
                                                    <quote who="Keith Davies">
                                                    > On Mon, Apr 19, 2004 at 08:49:57AM -0700, Keith Davies wrote:
                                                    >> On Fri, Apr 16, 2004 at 06:46:32PM -0700, Jenni A. Merrifield wrote:
                                                    > *Still* not right. That describes 'equals' behavior, not 'no more
                                                    > than'.
                                                    >
                                                    > if (minSet) {
                                                    > min = attribs.getAttrib( "min");
                                                    > }
                                                    > if (maxSet) {
                                                    > max = attribs.getAttrib( "max");
                                                    > if (!minSet) {
                                                    > min = 0;
                                                    > }
                                                    > }
                                                    >
                                                    > This one has it right. Finally.

                                                    I have never seen you take so long to get something right, go away and
                                                    take something for your cold ;O) I recommend a large whiskey with a hot
                                                    lemon squeezed into it.

                                                    --
                                                    regards,
                                                    Frugal
                                                    -OS Chimp
                                                  • Frugal
                                                    ... I did ;O) ... I can go with this because it satisfies Frugals First Law Of Programming: Never Do Anything Twice. Well, it almost
                                                    Message 25 of 29 , Apr 20, 2004
                                                    • 0 Attachment
                                                      <quote who="Keith Davies">
                                                      > On Mon, Apr 19, 2004 at 07:13:18AM -0700, Jenni A. Merrifield wrote:
                                                      >> <quote who="Frugal" when="Mon, 19 Apr 2004 09:04:47 +0100 (BST)"
                                                      > I never called it a dogs dinner. I don't disagree, but someone else
                                                      > said that.

                                                      I did ;O)

                                                      > Personally, I'd rather see
                                                      >
                                                      > <prereq kind='cumulative' min='20'>
                                                      > <count kind='skill-ranks' key='skill.jump' />
                                                      > <count kind='skill-ranks' key='skill.balance' />
                                                      > <count kind='skill-ranks' key='skill.tumble' />
                                                      > </prereq>
                                                      >
                                                      > If there are further requirements (such as 'each skill must have at
                                                      > least four and no more than ten ranks') then treat those as separate
                                                      > prereqs:
                                                      >
                                                      > <prereq kind='mult'>
                                                      > <prereq kind='cumulative' min='20'>
                                                      > <count kind='skill-ranks' key='skill.jump' />
                                                      > <count kind='skill-ranks' key='skill.balance' />
                                                      > <count kind='skill-ranks' key='skill.tumble' />
                                                      > </prereq>
                                                      > <prereq kind='skill-ranks' key='skill.jump' min='4' max='10' />
                                                      > <prereq kind='skill-ranks' key='skill.balance' min='4' max='10' />
                                                      > <prereq kind='skill-ranks' key='skill.tumble' min='4' max='10' />
                                                      > </prereq>

                                                      I can go with this because it satisfies Frugals First Law Of Programming:
                                                      Never Do Anything Twice. Well, it almost does.

                                                      <prereq kind='skill-ranks' key='skill.jump' min='4' max='10' />

                                                      can also be written as:

                                                      <prereq kind="cumulative" min="4" max="10">
                                                      <count kind='skill-ranks' key='skill.jump' />
                                                      </prereq>

                                                      So rather than having to have <prereq kind="skill-ranks"/> and <count
                                                      kind="skill-ranks" /> we can just have <count/> and express <prereq/> in
                                                      terms of <count/>

                                                      So the only <prereq> kinds we need are "count" and "mult" where
                                                      kind="count" can only have <count> children and kind="mult" can only have
                                                      <prereq> children.

                                                      As we can convert from all <prereq kind="skill-ranks"/> to a count nested
                                                      inside a prereq on the fly this should not be a problem.


                                                      As an aside in the very low level schema I think that
                                                      <count kind='skill-ranks' key='skill.jump' />
                                                      should actually be written as:
                                                      <count kind='var' key='skill.jump.ranks' />
                                                      because we are storing a lot more of the information as variables than the
                                                      current system

                                                      --
                                                      regards,
                                                      Frugal
                                                      -OS Chimp
                                                    • Keith Davies
                                                      ... The diet I m on, I m not allowed lemon. Or tea (my preferred cold-time drink is tea with honey (verboten) and a couple of Fisherman s Friends (strong
                                                      Message 26 of 29 , Apr 20, 2004
                                                      • 0 Attachment
                                                        On Tue, Apr 20, 2004 at 08:33:36AM +0100, Frugal wrote:
                                                        >
                                                        > <quote who="Keith Davies">
                                                        > > On Mon, Apr 19, 2004 at 08:49:57AM -0700, Keith Davies wrote:
                                                        > >> On Fri, Apr 16, 2004 at 06:46:32PM -0700, Jenni A. Merrifield wrote:
                                                        > > *Still* not right. That describes 'equals' behavior, not 'no more
                                                        > > than'.
                                                        > >
                                                        > > if (minSet) {
                                                        > > min = attribs.getAttrib( "min");
                                                        > > }
                                                        > > if (maxSet) {
                                                        > > max = attribs.getAttrib( "max");
                                                        > > if (!minSet) {
                                                        > > min = 0;
                                                        > > }
                                                        > > }
                                                        > >
                                                        > > This one has it right. Finally.
                                                        >
                                                        > I have never seen you take so long to get something right, go away and
                                                        > take something for your cold ;O) I recommend a large whiskey with a hot
                                                        > lemon squeezed into it.

                                                        The diet I'm on, I'm not allowed lemon. Or tea (my preferred cold-time
                                                        drink is tea with honey (verboten) and a couple of Fisherman's Friends
                                                        (strong cough tablet things)).

                                                        The whiskey I am allowed, but I'm not much on whiskey.


                                                        Keith
                                                        --
                                                        Keith Davies I gave my 2yo daughter a strawberry
                                                        keith.davies@... Naomi: "Strawberry!"
                                                        me: "What do you say?"
                                                        Naomi: "*MY* strawberry!"
                                                      • Keith Davies
                                                        ... Yeah, I read your post after. ... Well, we probably need others because there are tests that are binary (such as kind= feat ), but I suspect a number of
                                                        Message 27 of 29 , Apr 20, 2004
                                                        • 0 Attachment
                                                          On Tue, Apr 20, 2004 at 08:43:36AM +0100, Frugal wrote:
                                                          > <quote who="Keith Davies">
                                                          > > On Mon, Apr 19, 2004 at 07:13:18AM -0700, Jenni A. Merrifield wrote:
                                                          > >> <quote who="Frugal" when="Mon, 19 Apr 2004 09:04:47 +0100 (BST)"
                                                          > > I never called it a dogs dinner. I don't disagree, but someone else
                                                          > > said that.
                                                          >
                                                          > I did ;O)

                                                          Yeah, I read your post after.

                                                          > > Personally, I'd rather see
                                                          > >
                                                          > > <prereq kind='cumulative' min='20'>
                                                          > > <count kind='skill-ranks' key='skill.jump' />
                                                          > > <count kind='skill-ranks' key='skill.balance' />
                                                          > > <count kind='skill-ranks' key='skill.tumble' />
                                                          > > </prereq>
                                                          > >
                                                          > > If there are further requirements (such as 'each skill must have at
                                                          > > least four and no more than ten ranks') then treat those as separate
                                                          > > prereqs:
                                                          > >
                                                          > > <prereq kind='mult'>
                                                          > > <prereq kind='cumulative' min='20'>
                                                          > > <count kind='skill-ranks' key='skill.jump' />
                                                          > > <count kind='skill-ranks' key='skill.balance' />
                                                          > > <count kind='skill-ranks' key='skill.tumble' />
                                                          > > </prereq>
                                                          > > <prereq kind='skill-ranks' key='skill.jump' min='4' max='10' />
                                                          > > <prereq kind='skill-ranks' key='skill.balance' min='4' max='10' />
                                                          > > <prereq kind='skill-ranks' key='skill.tumble' min='4' max='10' />
                                                          > > </prereq>
                                                          >
                                                          > I can go with this because it satisfies Frugals First Law Of Programming:
                                                          > Never Do Anything Twice. Well, it almost does.
                                                          >
                                                          > <prereq kind='skill-ranks' key='skill.jump' min='4' max='10' />
                                                          >
                                                          > can also be written as:
                                                          >
                                                          > <prereq kind="cumulative" min="4" max="10">
                                                          > <count kind='skill-ranks' key='skill.jump' />
                                                          > </prereq>
                                                          >
                                                          > So rather than having to have <prereq kind="skill-ranks"/> and <count
                                                          > kind="skill-ranks" /> we can just have <count/> and express <prereq/> in
                                                          > terms of <count/>
                                                          >
                                                          > So the only <prereq> kinds we need are "count" and "mult" where
                                                          > kind="count" can only have <count> children and kind="mult" can only have
                                                          > <prereq> children.

                                                          Well, we probably need others because there are tests that are binary
                                                          (such as kind='feat'), but I suspect a number of the numeric ones can be
                                                          reduced to your example.

                                                          OTOH, even feat can be:

                                                          <prereq kind='count' min='1'>
                                                          <count kind='feat' key='feat.alertness' />
                                                          </prereq>

                                                          OTOH, I can see someone getting hosed when they try to do

                                                          <prereq kind='count' min='3'>
                                                          <count kind='feat' key='feat.weapon-focus' />
                                                          <count kind='feat' key='feat.greater-weapon-focus' />
                                                          <cound kind='feat' key='feat.weapon-specialization' />
                                                          </prereq>

                                                          because it should be

                                                          <prereq kind='mult'>
                                                          <prereq kind='count' min='1'>
                                                          <count kind='feat' key='feat.weapon-focus' />
                                                          </prereq>
                                                          <prereq kind='count' min='1'>
                                                          <count kind='feat' key='feat.greater-weapon-focus' />
                                                          </prereq>
                                                          <prereq kind='count' min='1'>
                                                          <count kind='feat' key='feat.weapon-specialization' />
                                                          </prereq>
                                                          </prereq>

                                                          > As we can convert from all <prereq kind="skill-ranks"/> to a count
                                                          > nested inside a prereq on the fly this should not be a problem.

                                                          If this is reserved for internal use I don't think I'll argue, though I
                                                          expect to keep the more concise form for external. While I agree that
                                                          consistency is a benefit, I think I'd rather see the larger syntax used
                                                          when needed, but allow the more concise syntax for the more common case.

                                                          I don't like making *everything* harder in order accommodate something
                                                          that I don't expect to come up often. OTOH, I really dislike special
                                                          cases. Gah, I'm going to leave it for how.

                                                          > As an aside in the very low level schema I think that
                                                          > <count kind='skill-ranks' key='skill.jump' />
                                                          > should actually be written as:
                                                          > <count kind='var' key='skill.jump.ranks' />
                                                          > because we are storing a lot more of the information as variables than the
                                                          > current system

                                                          Fair enough. IIRC at one point skill ranks were handled differently.


                                                          Keith
                                                          --
                                                          Keith Davies I gave my 2yo daughter a strawberry
                                                          keith.davies@... Naomi: "Strawberry!"
                                                          me: "What do you say?"
                                                          Naomi: "*MY* strawberry!"
                                                        • Frugal
                                                          ... Are you allowed Chilli? the other cure I have for a cold is a good hot curry. -- regards, Frugal -OS Chimp
                                                          Message 28 of 29 , Apr 20, 2004
                                                          • 0 Attachment
                                                            <quote who="Keith Davies">
                                                            > On Tue, Apr 20, 2004 at 08:33:36AM +0100, Frugal wrote:
                                                            >> I have never seen you take so long to get something right, go away and
                                                            >> take something for your cold ;O) I recommend a large whiskey with a hot
                                                            >> lemon squeezed into it.
                                                            >
                                                            > The diet I'm on, I'm not allowed lemon. Or tea (my preferred cold-time
                                                            > drink is tea with honey (verboten) and a couple of Fisherman's Friends
                                                            > (strong cough tablet things)).
                                                            >
                                                            > The whiskey I am allowed, but I'm not much on whiskey.

                                                            Are you allowed Chilli? the other cure I have for a cold is a good hot curry.

                                                            --
                                                            regards,
                                                            Frugal
                                                            -OS Chimp
                                                          • Keith Davies
                                                            ... Not really, no. Right now I m down to Vitamin C and hot water. I m at the worst part, the aw *shit*, I *am* sick part. Tomorrow I ll be in worse
                                                            Message 29 of 29 , Apr 20, 2004
                                                            • 0 Attachment
                                                              On Tue, Apr 20, 2004 at 03:35:25PM +0100, Frugal wrote:
                                                              >
                                                              > <quote who="Keith Davies">
                                                              > > On Tue, Apr 20, 2004 at 08:33:36AM +0100, Frugal wrote:
                                                              > >> I have never seen you take so long to get something right, go away and
                                                              > >> take something for your cold ;O) I recommend a large whiskey with a hot
                                                              > >> lemon squeezed into it.
                                                              > >
                                                              > > The diet I'm on, I'm not allowed lemon. Or tea (my preferred cold-time
                                                              > > drink is tea with honey (verboten) and a couple of Fisherman's Friends
                                                              > > (strong cough tablet things)).
                                                              > >
                                                              > > The whiskey I am allowed, but I'm not much on whiskey.
                                                              >
                                                              > Are you allowed Chilli? the other cure I have for a cold is a good hot
                                                              > curry.

                                                              Not really, no. Right now I'm down to Vitamin C and hot water.

                                                              I'm at the worst part, the 'aw *shit*, I *am* sick' part. Tomorrow I'll
                                                              be in worse condition, but it won't bother me so much because I'll
                                                              likely be unconscious anyway.


                                                              Keith
                                                              --
                                                              Keith Davies I gave my 2yo daughter a strawberry
                                                              keith.davies@... Naomi: "Strawberry!"
                                                              me: "What do you say?"
                                                              Naomi: "*MY* strawberry!"
                                                            Your message has been successfully submitted and would be delivered to recipients shortly.