RE: Getting back to the Choose Tag... (was: [pcgen-xml] Can we use XPath (was Re: [pcgen-xml] First pass at an XML choose tag))
- <quote who="Jenni A. Merrifield">
> <quote who="Frugal">Remember that there is a difference between adding a weapon prof to a
>> i.e. instead of "feat.weapon-prof(Longsword,Kama)" we have
>> "feat.weapon-prof(Longsword)" and "feat.weapon-prof(kama)".
> I wanted to avoid that, because then you not only need an entity for
> weapon prof (that can be added to the character) but you also need an
> for every weapon prof feat, every other feat that is based on a weapon
> &c. which ends up with a number of entities increasing as N^(x+1) (where x
> the number of entities, like feats, that rely on weapon proficiencies).
> Doing it as feat.weapon-prof, &c. gives us an increase in individual equal
> only N+x (N for all the individual weapon profs and x for all the things
> use it). Much better.
character and adding a feat that adds a weapon prof.
I have a lot of characters, but I have only ever used the weapon-prof
feats a couple of times. You could well end up with a character that has
NOTE: This is not an accurate representation of the data, but just a rough
sketch to show how the same data can be held in a couple of different
The only thing we would need is a way to add all weapon profs that match a
<choose id="all_simple_weapons" num="all">
<choice select="/entities/entity[types/type='weapon-prof' and
> Also, doing it the way you are suggesting means that any time someoneNot really, if it is a martial, exotic or simple weapon then it can be
> to add a new weapon proficiency then they also have to add new feats that
> it, &c. Yuck. :-P
added using the appropriate feats / choices. If it is a new type such as
"firearm" then you would want a new fet to assign them anyway.
> Where additional filtering of which "choices" are allowed, it should beIs this saying: iterate over all of the entities in the system and add it
> possible to attach prereqs to any given choose or choice tag, such as,
> <choice kind="entity" refid="feat.weapon-prof">
> <prereq kind="mult">
> <prereq kind="entity" type="weapon-prof martial">
to the selectable ones if the it satisfies the <prereq>
> [ASIDE] How do we filter in entity X based on what has already been addedI would consider adding an 'exclude' option for choices.
> entity Y? E.G., when choosing a new weapon-prof feat, you should only
> have a
> choice of weapon-prof's not yet attached to the character entity and this
> different for every character.
Again, this could be expressed in terms of 'kind' and 'type' providing we
have some way of accessing the character from them.
We would also be able to say things like "any 5th level wizard spell
execpt those form the necromancy domain".
> When you pick a feat like weapon focus,<choice select="/character/entities/entity[types/type='weapon-prof']" />
> should only get to choose from the list of weapon-profs that are already
> attached to the character entity... and so on.
would select all weapon profs currently assigned to the character
> The "choose" tag should only apply in the context of exactly whateverWhat should that choice be? Should it be a String, or an object ?
> entity it's being applied to and only ever returns one thing at any one
> - the choice that was actually made. Generally, that one thing should
> be added to another entity so that you can access the actual various
> made for that entity by referencing that entity.
I am wondering if the "database" that is the application data should be a
bit more tree structured for queries:
instead of just having entities as a top level object, I wonder if we
should refer to the entities by type. so as well as being able to query
we could also use a different query to return the same results set:
i.e. create a dynamic virtual tree internally based on the 'type' elements
of the data. but because they were just references t other points in the
tree we could still get access to all of the other types:
Would return a list of all simple weapon-profs...
> Out of time - gotta go to work. I'll reply to the rest later. :-)Out of time, got to go back to pretending to be doing StarTeam training
exercises (for some reason here they give people external net acccess in
training rooms ;O)