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

Re: [pcgen-xml]

Expand Messages
  • Keith Davies
    ... I have no real intention of restricting anything. As described (long ago) if you want a skill that gives a bonus to attack rolls, a weapon that gives a
    Message 1 of 9 , Nov 13, 2003
      On Thu, Nov 13, 2003 at 11:54:36AM +0000, Frugal wrote:
      > How does your system handle the common base tags that all Entities can
      > have in PCGen:
      >
      > add, auto, bonus, campaign, changeprof, choose, cskill, ccskill,
      > define, desc, descispi, dr, key, kit, langauto, move, movea,
      > moveclone, name, nameispi, naturalattacks, outputname, pre, region,
      > source, sa, spell, spelllevel, sr, type, udam, umult, vfeat, vision,
      > weaponauto
      >
      > It is possible to have a natural attacks flag in a skill (PCGen would
      > probably never do anything with it, but it is possible).
      >
      > Will the XML elements be able to encode all of these elements for any
      > Object, or will you restrict it (i.e. skills can only use bonus, pre,
      > define, choose, nameispi, name).
      >
      > If you are planning to restrict it, what method are you using to
      > determine which of the global tags can be in each entity?

      I have no real intention of restricting anything. As described (long
      ago) if you want a skill that gives a bonus to attack rolls, a weapon
      that gives a bonus to skill checks, whatever, it's not *my* place to say
      you can't. In many cases it makes sense to be able to do so, and for
      the others, I don't see it worth the bother to make it impossible.

      The <effects> element (I think I've seen mention of it) may or may not
      be present in the schema. If present, it could contain any sort of
      effect -- add bonuses, add to known spells, whatever. It wouldn't vary
      by parent element. If not present in the schema, it's a placeholder for
      'anything that can be an effect of this thing'.

      If the current PCGen-XML documentation does not show otherwise, it means
      that either nothing else was found there, or the documentation is not
      complete.

      Obvious global children are:

      <name abbrev />
      <aka /> <!-- aliases, but not the primary name -->
      <desc />
      <description />
      <pre /> <!-- or <prereq /> -->

      global attributes may be on any object and include

      source:*

      source information is handled using attributes, and is inherited from
      parent elements except where overridden. This allows you to define
      source information at the <data> level and have all children share it.

      ispi, isogl

      are both needed? One indicates PI, other indicates OGL; I *think*
      these are exclusive conditions. These attributes may appear on any
      element, not just game objects (<description ispi='yes' /> means that
      the description is PI).

      I want to rework type; it's doing way more than it should have to.


      Keith
      --
      Keith Davies "Your ability to bang your head against
      keith.davies@... reality in the hope that reality will
      crack first is impressive, but futile"
      -- Geoffrey Brent, rec.games.frp.dnd
    • Frugal
      ... That is cool. In fact it is helpfull as we can create an Object base type in the schema for all of the common data and then
      Message 2 of 9 , Nov 14, 2003
        <quote who="Keith Davies">
        > I have no real intention of restricting anything. As described (long
        > ago) if you want a skill that gives a bonus to attack rolls, a weapon
        > that gives a bonus to skill checks, whatever, it's not *my* place to say
        > you can't. In many cases it makes sense to be able to do so, and for
        > the others, I don't see it worth the bother to make it impossible.

        That is cool. In fact it is helpfull as we can create an Object base type
        in the schema for all of the common data and then derive a type for each
        of the concrete object types (feat skill etc).

        --
        regards,
        Frugal
        -OS Chimp
      • Keith Davies
        ... That s pretty much my plan. Keith -- Keith Davies Your ability to bang your head against keith.davies@kjdavies.org reality in the hope
        Message 3 of 9 , Nov 14, 2003
          On Fri, Nov 14, 2003 at 08:51:21AM +0000, Frugal wrote:
          >
          > <quote who="Keith Davies">
          > > I have no real intention of restricting anything. As described
          > > (long ago) if you want a skill that gives a bonus to attack rolls, a
          > > weapon that gives a bonus to skill checks, whatever, it's not *my*
          > > place to say you can't. In many cases it makes sense to be able to
          > > do so, and for the others, I don't see it worth the bother to make
          > > it impossible.
          >
          > That is cool. In fact it is helpfull as we can create an Object base
          > type in the schema for all of the common data and then derive a type
          > for each of the concrete object types (feat skill etc).

          That's pretty much my plan.


          Keith
          --
          Keith Davies "Your ability to bang your head against
          keith.davies@... reality in the hope that reality will
          crack first is impressive, but futile"
          -- Geoffrey Brent, rec.games.frp.dnd
        • Frugal
          ... Trouble is, I can not figure out how to have a concrete type derived from an abstract base type and have the data be unordered
          Message 4 of 9 , Nov 14, 2003
            <quote who="Keith Davies">
            > On Fri, Nov 14, 2003 at 08:51:21AM +0000, Frugal wrote:
            >>
            >> <quote who="Keith Davies">
            >> > I have no real intention of restricting anything. As described
            >> > (long ago) if you want a skill that gives a bonus to attack rolls, a
            >> > weapon that gives a bonus to skill checks, whatever, it's not *my*
            >> > place to say you can't. In many cases it makes sense to be able to
            >> > do so, and for the others, I don't see it worth the bother to make
            >> > it impossible.
            >>
            >> That is cool. In fact it is helpfull as we can create an Object base
            >> type in the schema for all of the common data and then derive a type
            >> for each of the concrete object types (feat skill etc).
            >
            > That's pretty much my plan.

            Trouble is, I can not figure out how to have a concrete type derived from
            an abstract base type and have the data be unordered over all of them.

            But hey, I only just figured out how to use the source: namespace for
            attributes without the parser throwing a hissy fit ;O)

            --
            regards,
            Frugal
            -OS Chimp
          • Keith Davies
            ... That the child elements be unordered was Tir s requirement, not mine. I m all for having the children in specific order. That said, a reasonably simple way
            Message 5 of 9 , Nov 17, 2003
              On Fri, Nov 14, 2003 at 08:08:30PM +0000, Frugal wrote:
              >
              > <quote who="Keith Davies">
              > > On Fri, Nov 14, 2003 at 08:51:21AM +0000, Frugal wrote:
              > >>
              > >> <quote who="Keith Davies">
              > >> > I have no real intention of restricting anything. As described
              > >> > (long ago) if you want a skill that gives a bonus to attack rolls, a
              > >> > weapon that gives a bonus to skill checks, whatever, it's not *my*
              > >> > place to say you can't. In many cases it makes sense to be able to
              > >> > do so, and for the others, I don't see it worth the bother to make
              > >> > it impossible.
              > >>
              > >> That is cool. In fact it is helpfull as we can create an Object base
              > >> type in the schema for all of the common data and then derive a type
              > >> for each of the concrete object types (feat skill etc).
              > >
              > > That's pretty much my plan.
              >
              > Trouble is, I can not figure out how to have a concrete type derived
              > from an abstract base type and have the data be unordered over all of
              > them.

              That the child elements be unordered was Tir's requirement, not mine.
              I'm all for having the children in specific order.

              That said, a reasonably simple way to handle it would be to allow any
              number of them in any order and just keep the last. If the element may
              appear more than once (which I'm trying to avoid, as you know) then cat
              them together as you normally would (all <prereq>s go into the prereqs
              set, etc.). If you find a second... <weight>, say, for an <equip> just
              stomp on the one that was already present.


              Keith
              --
              Keith Davies "Your ability to bang your head against
              keith.davies@... reality in the hope that reality will
              crack first is impressive, but futile"
              -- Geoffrey Brent, rec.games.frp.dnd
            • Keith Davies
              ... Whoops, just remembered that keeping children in the same order for *all* elements can lead to some ugliness -- either children in weird order (one that
              Message 6 of 9 , Nov 17, 2003
                On Fri, Nov 14, 2003 at 08:08:30PM +0000, Frugal wrote:
                >
                > <quote who="Keith Davies">
                > > On Fri, Nov 14, 2003 at 08:51:21AM +0000, Frugal wrote:
                > >>
                > >> <quote who="Keith Davies">
                > >> > I have no real intention of restricting anything. As described
                > >> > (long ago) if you want a skill that gives a bonus to attack rolls, a
                > >> > weapon that gives a bonus to skill checks, whatever, it's not *my*
                > >> > place to say you can't. In many cases it makes sense to be able to
                > >> > do so, and for the others, I don't see it worth the bother to make
                > >> > it impossible.
                > >>
                > >> That is cool. In fact it is helpfull as we can create an Object base
                > >> type in the schema for all of the common data and then derive a type
                > >> for each of the concrete object types (feat skill etc).
                > >
                > > That's pretty much my plan.
                >
                > Trouble is, I can not figure out how to have a concrete type derived
                > from an abstract base type and have the data be unordered over all of
                > them.

                Whoops, just remembered that keeping children in the same order for
                *all* elements can lead to some ugliness -- either children in weird
                order (one that doesn't make sense for the element) or conflicts.

                This can be remedied, I think, by establishing a single ordering scheme
                for all entities; if an entity doesn't contain a particular child
                element at all, it simply doesn't show up in the list of allowable
                children. For instance, we might say

                <!ELEMENT race (name,desc?,description?,prereq?) >
                <!ELMEENT skill (name,desc?,description?) >

                Assuming, of course, that <skill> will never have prereqs (which I'm
                inclined to allow them to have anyway because I figure just about
                *anything* can be limited by prereqs). As an example, though, I think
                it's simple enough.


                Keith
                --
                Keith Davies "Your ability to bang your head against
                keith.davies@... reality in the hope that reality will
                crack first is impressive, but futile"
                -- Geoffrey Brent, rec.games.frp.dnd
              • Frugal
                ... Caveat: I have never tried to write a schema that is anything other than trivial before this. Please feel free to tear this to
                Message 7 of 9 , Nov 18, 2003
                  <quote who="Keith Davies">
                  >> Trouble is, I can not figure out how to have a concrete type derived
                  >> from an abstract base type and have the data be unordered over all of
                  >> them.
                  >
                  > Whoops, just remembered that keeping children in the same order for
                  > *all* elements can lead to some ugliness -- either children in weird
                  > order (one that doesn't make sense for the element) or conflicts.

                  Caveat: I have never tried to write a schema that is anything other than
                  trivial before this. Please feel free to tear this to pieces. We have the
                  technology, we can rebuild it.

                  What I currently have is something like this:

                  <xs:complexType name="objectType">
                  <xs:all>
                  <xs:element ref="name"/>
                  <xs:element ref="outputName" minOccurs="0"/>
                  <xs:element ref="description" minOccurs="0"/>
                  <xs:element ref="prereq" minOccurs="0"/>
                  <xs:element ref="types" minOccurs="0"/>
                  <xs:element ref="defines" minOccurs="0"/>
                  <xs:element ref="bonuses" minOccurs="0"/>
                  <xs:element ref="autos" minOccurs="0"/>
                  <xs:element ref="specialAbilities" minOccurs="0"/>
                  <xs:element ref="damageReduction" minOccurs="0"/>
                  <xs:element name="classSkills" type="classSkillsType" minOccurs="0"/>
                  <xs:element name="crossClassSkills" type="crossClassSkillsType"
                  minOccurs="0"/>
                  <xs:element ref="vision" minOccurs="0"/>
                  <xs:element ref="add" minOccurs="0"/>
                  </xs:all>
                  <xs:attribute name="id" type="xs:string" use="required"/>
                  <xs:attribute name="ispi" type="xs:boolean" use="optional"/>
                  <xs:attributeGroup ref="source.group"/>
                  </xs:complexType>
                  <xs:complexType name="featType">
                  <xs:complexContent>
                  <xs:extension base="objectType">
                  <xs:all>
                  <xs:element ref="cost" minOccurs="0"/>
                  <xs:element ref="addSpellLevel" minOccurs="0"/>
                  </xs:all>
                  <xs:attribute name="visiblity" type="xs:string" use="optional"/>
                  <xs:attribute name="stacks" type="xs:string" use="optional"/>
                  <xs:attribute name="multiples" type="xs:string" use="optional"/>
                  </xs:extension>
                  </xs:complexContent>
                  </xs:complexType>


                  Which sort of works. You can order the elements in the 'objectType' in any
                  order you wish; you can order the elements in the 'featType' in any order
                  you wish. What you can not do is put any featType child before any
                  objectType child.

                  i.e.

                  <feat id="feat.foo">
                  <types>
                  <type>Fighter</type>
                  <type>General</type>
                  </types>
                  <name>Foo</name>
                  <cost>1</cost>
                  </feat>

                  is fine, but:

                  <feat id="feat.foo">
                  <types>
                  <type>Fighter</type>
                  <type>General</type>
                  </types>
                  <cost>1</cost>
                  <name>Foo</name>
                  </feat>

                  Is not. It will give an "unexpected child element 'name' error".

                  Is it even possible to write a schema that allows the elements from a type
                  and it's base type to mix ?

                  > This can be remedied, I think, by establishing a single ordering scheme
                  > for all entities; if an entity doesn't contain a particular child
                  > element at all, it simply doesn't show up in the list of allowable
                  > children. For instance, we might say
                  >
                  > <!ELEMENT race (name,desc?,description?,prereq?) >
                  > <!ELMEENT skill (name,desc?,description?) >

                  True, but this means that we need to copy the common objectType content
                  into each and every Entity element (and remember to update them all
                  whenever we change something).

                  > Assuming, of course, that <skill> will never have prereqs (which I'm
                  > inclined to allow them to have anyway because I figure just about
                  > *anything* can be limited by prereqs). As an example, though, I think
                  > it's simple enough.

                  As you suspected there are indeed skills that have prereqs on them.

                  "Knowledge (Data World)" has a prereq of 1 level in a particular class.

                  "Pilot" has a prereq of the "Technical Proficiency" feat.

                  --
                  regards,
                  Frugal
                  -OS Chimp
                • Keith Davies
                  ... I ll have to comment on this later; I m working right now and don t have the time to examine it in sufficient detail. ... Keith -- Keith Davies
                  Message 8 of 9 , Nov 18, 2003
                    On Tue, Nov 18, 2003 at 10:32:52AM +0000, Frugal wrote:
                    >
                    > <quote who="Keith Davies">
                    > >> Trouble is, I can not figure out how to have a concrete type derived
                    > >> from an abstract base type and have the data be unordered over all of
                    > >> them.
                    > >
                    > > Whoops, just remembered that keeping children in the same order for
                    > > *all* elements can lead to some ugliness -- either children in weird
                    > > order (one that doesn't make sense for the element) or conflicts.
                    >
                    > Caveat: I have never tried to write a schema that is anything other
                    > than trivial before this. Please feel free to tear this to pieces. We
                    > have the technology, we can rebuild it.

                    I'll have to comment on this later; I'm working right now and don't have
                    the time to examine it in sufficient detail.

                    > What I currently have is something like this:
                    >
                    > <xs:complexType name="objectType">
                    > <xs:all>


                    Keith
                    --
                    Keith Davies "Your ability to bang your head against
                    keith.davies@... reality in the hope that reality will
                    crack first is impressive, but futile"
                    -- Geoffrey Brent, rec.games.frp.dnd
                  Your message has been successfully submitted and would be delivered to recipients shortly.