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

Re: [pcgen-xml]

Expand Messages
  • 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 1 of 9 , Nov 14, 2003
    • 0 Attachment
      <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 2 of 9 , Nov 14, 2003
      • 0 Attachment
        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 3 of 9 , Nov 14, 2003
        • 0 Attachment
          <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 4 of 9 , Nov 17, 2003
          • 0 Attachment
            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 5 of 9 , Nov 17, 2003
            • 0 Attachment
              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 6 of 9 , Nov 18, 2003
              • 0 Attachment
                <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 7 of 9 , Nov 18, 2003
                • 0 Attachment
                  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.