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

Question regarding

Expand Messages
  • Frugal
    after Keiths comment on the pcgen list that he was the only person to have done anything with the XML and having no response from anyone I felt a bit guilty.
    Message 1 of 13 , Nov 6, 2003
    • 0 Attachment
      after Keiths comment on the pcgen list that he was the only person to have
      done anything with the XML and having no response from anyone I felt a bit
      guilty. And as I also felt bored I started to implement it.

      I ended up with a hacked together SAX parser that will parse an XML file
      of skills and correctly load them into PCGen.

      However what it does not do it load the bonus information for synergy
      bonuses. Partly because I have not done that yet, and partly because I
      have a few questions about the schema.

      1 - The documentation for the schema is on the web site, but is there a
      schema anywhere ?

      2 - I have created a schema with XML-Spy for the bits I have been working
      with and I can not figure out how to have attributes from different name
      spaces (i.e. the source:short group of attributes)

      3 - How are skills with multiple bonuses supposed to be handled. The docs
      indicate that there can only be a single <effects> with a single <bonus>,
      however the <effects> can have an <effects>. E.g. this is how the docs
      indicate you need to implement Diplomacy (which has 2 synergy bonuses)

      <skill id="skill.diplomacy" source.page="Chap.4, Skill Descriptions">
      <effects>
      <bonus>SKILL|Diplomacy|2|TYPE=Synergy.STACK</bonus>
      <effects>
      <bonus>SKILL|Diplomacy|2|TYPE=Synergy.STACK</bonus>
      <prereqs>
      <preskill min="5">Sense Motive</preskill>
      </prereqs>
      </effects>
      <prereqs>
      <preskill min="5">Bluff</preskill>
      </prereqs>
      </effects>
      <keystat>CHA</keystat>
      <name>Diplomacy</name>
      <types>Charisma</types>
      </skill>


      Would it not be more logical to have it like this:

      <skill id="skill.diplomacy" source.page="Chap.4, Skill Descriptions">
      <effects>
      <effect>
      <bonus>SKILL|Diplomacy|2|TYPE=Synergy.STACK</bonus>
      <prereqs>
      <preskill min="5">Bluff</preskill>
      </prereqs>
      </effect>
      <effect>
      <bonus>SKILL|Diplomacy|2|TYPE=Synergy.STACK</bonus>
      <prereqs>
      <preskill min="5">Sense Motive</preskill>
      </prereqs>
      </effect>
      </effects>
      <keystat>CHA</keystat>
      <name>Diplomacy</name>
      <types>Charisma</types>
      </skill>

      --
      regards,
      Frugal
      -OS Chimp
    • Keith Davies
      ... Not implemented. I tend to write them when I know what the data looks like. I run into fewer conflicts of but that s what *I* designed, I should follow
      Message 2 of 13 , Nov 6, 2003
      • 0 Attachment
        On Thu, Nov 06, 2003 at 10:33:42AM +0000, Frugal wrote:
        >
        > I ended up with a hacked together SAX parser that will parse an XML file
        > of skills and correctly load them into PCGen.
        >
        > However what it does not do it load the bonus information for synergy
        > bonuses. Partly because I have not done that yet, and partly because I
        > have a few questions about the schema.
        >
        > 1 - The documentation for the schema is on the web site, but is there a
        > schema anywhere ?

        Not implemented. I tend to write them when I know what the data looks
        like. I run into fewer conflicts of 'but that's what *I* designed, I
        should follow it'. Also find that if I have to create a data set and
        find that the schema's a pain in the ass, that it's better to find out
        before I go to the trouble of creating an XSD.

        > 2 - I have created a schema with XML-Spy for the bits I have been working
        > with and I can not figure out how to have attributes from different name
        > spaces (i.e. the source:short group of attributes)

        Couldn't say, I don't use XML-Spy. I understand it's a sweet tool to
        work with, and it looks like it. But I don't run Windows.

        > 3 - How are skills with multiple bonuses supposed to be handled. The docs
        > indicate that there can only be a single <effects> with a single <bonus>,
        > however the <effects> can have an <effects>. E.g. this is how the docs
        > indicate you need to implement Diplomacy (which has 2 synergy bonuses)

        Do they? That was lame... although looking below it lokos like
        something that is intended to change. The single child rule was
        probably put into place because that's what the data 'looked like'.

        > <skill id="skill.diplomacy" source.page="Chap.4, Skill Descriptions">
        > <effects>
        > <bonus>SKILL|Diplomacy|2|TYPE=Synergy.STACK</bonus>
        > <effects>
        > <bonus>SKILL|Diplomacy|2|TYPE=Synergy.STACK</bonus>
        > <prereqs>
        > <preskill min="5">Sense Motive</preskill>
        > </prereqs>
        > </effects>
        > <prereqs>
        > <preskill min="5">Bluff</preskill>
        > </prereqs>
        > </effects>
        > <keystat>CHA</keystat>
        > <name>Diplomacy</name>
        > <types>Charisma</types>
        > </skill>

        Gah, is that what's there? That's hideous.

        The primary purpose of the <effects> element is to describe what happens
        when you take a rank in the skill (such as 'Speak Language' adding to
        the number of known languages). I think I may have used it as a
        placeholder to dump the <bonus> information. It certainly isn't a good
        place for it.

        > Would it not be more logical to have it like this:
        >
        > <skill id="skill.diplomacy" source.page="Chap.4, Skill Descriptions">
        > <effects>
        > <effect>
        > <bonus>SKILL|Diplomacy|2|TYPE=Synergy.STACK</bonus>
        > <prereqs>
        > <preskill min="5">Bluff</preskill>
        > </prereqs>
        > </effect>
        > <effect>
        > <bonus>SKILL|Diplomacy|2|TYPE=Synergy.STACK</bonus>
        > <prereqs>
        > <preskill min="5">Sense Motive</preskill>
        > </prereqs>
        > </effect>
        > </effects>
        > <keystat>CHA</keystat>
        > <name>Diplomacy</name>
        > <types>Charisma</types>
        > </skill>

        What I'd like to see is:

        <data id='data.phb.skills' source:page='Chap.4, "Skill Descriptions"'>

        <skill id='skill.diplomacy' keystat='cha'>
        <name>Diplomacy</name>
        </skill>

        <bonus id='bonus.synergy.diplomacy-bluff'
        to='skill.diplomacy' value='2'>
        <type bonustype='synergy' />
        <pre skill='skill.bluff' min='5' />
        </bonus>

        <bonus id='bonus.synergy.diplomacy-sense_motive'
        to='skill.diplomacy' value='2'>
        <type bonustype='synergy' />
        <pre skill='skill.sense_motive' min='5' />
        </bonus>

        </data>

        Elements in the source namespace are expected to be inherited; if a
        number of entities share the same value (which for source, within a
        single file, they usually will), put it in the parent <data> element and
        inherit the values. Just a note.

        As shown above, I'd like to move <bonus> -- at least this kind -- out of
        the skill. It allows me the ability to manipulate them apart from the
        thing that would grant the bonus. Right now there are, so far as I can
        see, at least two places to define a synergy bonus. The first would be
        the skill that receives the check bonus, the other is the skill the
        gives the check bonus. Maintenance pain. Pull it out of both of them
        ('normalize') and make it its own object.

        I'm not entirely happy with the <bonus> elements I wrote above; this was
        a section I meant to come back to and redesign.


        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
        ... funny, I do it the other way around. I get a rough idea of how it should look in my head and then create a schema iteratively to
        Message 3 of 13 , Nov 6, 2003
        • 0 Attachment
          <quote who="Keith Davies">
          > On Thu, Nov 06, 2003 at 10:33:42AM +0000, Frugal wrote:
          >> 1 - The documentation for the schema is on the web site, but is there a
          >> schema anywhere ?
          >
          > Not implemented. I tend to write them when I know what the data looks
          > like. I run into fewer conflicts of 'but that's what *I* designed, I
          > should follow it'. Also find that if I have to create a data set and
          > find that the schema's a pain in the ass, that it's better to find out
          > before I go to the trouble of creating an XSD.

          funny, I do it the other way around. I get a rough idea of how it should
          look in my head and then create a schema iteratively to give me a
          framework to hang the test cases off and validate them ;O)

          >> 2 - I have created a schema with XML-Spy for the bits I have been
          >> working
          >> with and I can not figure out how to have attributes from different name
          >> spaces (i.e. the source:short group of attributes)
          >
          > Couldn't say, I don't use XML-Spy. I understand it's a sweet tool to
          > work with, and it looks like it. But I don't run Windows.

          It is very sweet, and work has paid the x'000 it costs ;O)

          The ability to mess around with a schema and an XML file, validating one
          against the other is a god send. It also has a rather nice XSLT
          interactive debugger.

          > Gah, is that what's there? That's hideous.

          That was a particularly bad example ;O)

          > The primary purpose of the <effects> element is to describe what happens
          > when you take a rank in the skill (such as 'Speak Language' adding to
          > the number of known languages). I think I may have used it as a
          > placeholder to dump the <bonus> information. It certainly isn't a good
          > place for it.

          In the sample docs the only place you can have a <bonus> is in an
          <effects> tag, and you can only have one of them.

          > As shown above, I'd like to move <bonus> -- at least this kind -- out of
          > the skill. It allows me the ability to manipulate them apart from the
          > thing that would grant the bonus. Right now there are, so far as I can
          > see, at least two places to define a synergy bonus. The first would be
          > the skill that receives the check bonus, the other is the skill the
          > gives the check bonus. Maintenance pain. Pull it out of both of them
          > ('normalize') and make it its own object.

          The problem which this is that a bonus needs to hang off of _something_
          PCGen does not have any concept of a free floating bonus.

          I do not know if with Jamie's bonus redesign it will be possible to have a
          global list of free floating bonuses in the same way as you have a global
          list of skills or feats. It would require a bit of work to make sure that
          they were always applied but it could work.

          > I'm not entirely happy with the <bonus> elements I wrote above; this was
          > a section I meant to come back to and redesign.

          I have noticed that there are a bunch of places where the syntax will need
          to be changed in order to satisfy your requirements that
          1 - the data should both validate and
          2 - allow elemeents in any order.

          The only way to allow elements in any order is to use an <xs:any> and the
          only time you can use one is if it has now sub elements with maxOccurs>1.

          Basically you can not have

          <feat>
          <name>Foo</name>
          <bonus>SKILL|Listen,Spot|2</bonus>
          <bonus>SKILL|Tumble|3</bonus>
          </feat>

          you have to put any repeating element in a container element:

          <feat>
          <name>Foo</name>
          <bonuses>
          <bonus>SKILL|Listen,Spot|2</bonus>
          <bonus>SKILL|Tumble|3</bonus>
          </bonuses>
          </feat>

          It will be the same for pre-reqs (in fact it gets easier if you have
          indeed found a way to put all the preerqs in a single tag:

          <feat id="feat.ambidexterity" source.page="Chap.5, Feat Descriptions">
          <name>Ambidexterity</name>
          <types>General.Fighter</types>
          <prereqs>
          <prereq type="hands" min="2" max="2"/>
          <prereq type="stat" eq="1" min="15">DEX</prereq >
          </prereqs>
          <desc>See Text</desc>
          <bonuses>
          <bonus>COMBAT|TOHIT-SECONDARY|4</bonus>
          </bonuses>
          </feat>


          Note: If you want to keep it as simple for the LST developers to move to
          this syntax why not just keep the whole of the pre-req as a string?

          <prereqs>
          <prereq>PREHANDSEQ|2</prereq>
          <prereq>PRESTAT|1,DEX=15</prereq>
          </prereqs>

          when you parse the file in, you have to convert the <prereq> content back
          to the "PRESTAT|1,DEX=15" form to apply it to the bonus/feat/whatever
          object anyway ;O)

          It will make the schema a lot simple, parseing a lot simpler and getting
          the LST monkies to buy in a lot simpler.

          If we want to move to a better syntax later we still can. I am just trying
          to cut down the amount of work needed at this point.

          Right, I am off to the Chiroprator now, then gaming tonight to see what
          evil our DM has lined up for us this week. So I will catch up with you
          tommorow.

          <frugal is happy because this topic made him use his brain at work for the
          first time in 2 weeks ;O) >

          --
          regards,
          Frugal
          -OS Chimp
        • Keith Davies
          ... I m *usually* pretty good at staying consistent while I hack things up, so it hasn t been a problem. Whatever works, I guess. ... Docs are out of date,
          Message 4 of 13 , Nov 6, 2003
          • 0 Attachment
            On Thu, Nov 06, 2003 at 03:55:36PM +0000, Frugal wrote:
            >
            > <quote who="Keith Davies">
            > > On Thu, Nov 06, 2003 at 10:33:42AM +0000, Frugal wrote:
            > >> 1 - The documentation for the schema is on the web site, but is there a
            > >> schema anywhere ?
            > >
            > > Not implemented. I tend to write them when I know what the data
            > > looks like. I run into fewer conflicts of 'but that's what *I*
            > > designed, I should follow it'. Also find that if I have to create a
            > > data set and find that the schema's a pain in the ass, that it's
            > > better to find out before I go to the trouble of creating an XSD.
            >
            > funny, I do it the other way around. I get a rough idea of how it should
            > look in my head and then create a schema iteratively to give me a
            > framework to hang the test cases off and validate them ;O)

            I'm *usually* pretty good at staying consistent while I hack things up,
            so it hasn't been a problem. Whatever works, I guess.

            > > The primary purpose of the <effects> element is to describe what
            > > happens when you take a rank in the skill (such as 'Speak Language'
            > > adding to the number of known languages). I think I may have used
            > > it as a placeholder to dump the <bonus> information. It certainly
            > > isn't a good place for it.
            >
            > In the sample docs the only place you can have a <bonus> is in an
            > <effects> tag, and you can only have one of them.

            Docs are out of date, then.

            > > As shown above, I'd like to move <bonus> -- at least this kind -- out of
            > > the skill. It allows me the ability to manipulate them apart from the
            > > thing that would grant the bonus. Right now there are, so far as I can
            > > see, at least two places to define a synergy bonus. The first would be
            > > the skill that receives the check bonus, the other is the skill the
            > > gives the check bonus. Maintenance pain. Pull it out of both of them
            > > ('normalize') and make it its own object.
            >
            > The problem which this is that a bonus needs to hang off of _something_
            > PCGen does not have any concept of a free floating bonus.

            That's the rub. Part of it is that I'm not just designing for PCGen,
            I'm designing something for my own use that PCGen can make use of. If
            you haven't seen or heard my discussion of how I expect the loader to
            work (or a reminder if you have)...

            Everything in the game is represented by an Entity or a subclass
            thereof. There will be an interface 'EntityProducer' that does the
            obvious. There will also be an interface 'EntityConsumer' that receives
            the Entity objects produced by EntityProducer and does something with
            them. So, what I picture is something like:

            public class XMLLoader implements EntityProducer {}
            public class EntityLSTConsumer implements EntityConsumer {}

            On loading the XML file, the engine will take the Entity objects
            produced by the XMLLoader and pass them to an EntityLSTConsumer. This
            object will then convert the Entity to a PObject-based object and store
            it as needed.

            In the case of a <bonus>, it can be attached to one of the <skill>s
            related to the bonus. Or cached until one of the <skill>s is loaded, if
            necessary.

            > > I'm not entirely happy with the <bonus> elements I wrote above; this was
            > > a section I meant to come back to and redesign.
            >
            > I have noticed that there are a bunch of places where the syntax will need
            > to be changed in order to satisfy your requirements that
            > 1 - the data should both validate and
            > 2 - allow elemeents in any order.

            The second isn't my requirement, it's Tir's. Personally I'd like to
            nail down the order of child elements, it'd make things a fair whack
            simpler.

            > The only way to allow elements in any order is to use an <xs:any> and the
            > only time you can use one is if it has now sub elements with maxOccurs>1.
            >
            > Basically you can not have
            >
            > <feat>
            > <name>Foo</name>
            > <bonus>SKILL|Listen,Spot|2</bonus>
            > <bonus>SKILL|Tumble|3</bonus>
            > </feat>
            >
            > you have to put any repeating element in a container element:
            >
            > <feat>
            > <name>Foo</name>
            > <bonuses>
            > <bonus>SKILL|Listen,Spot|2</bonus>
            > <bonus>SKILL|Tumble|3</bonus>
            > </bonuses>
            > </feat>

            Which I kind of prefer anyway for many things -- keeps things tidier.

            > It will be the same for pre-reqs (in fact it gets easier if you have
            > indeed found a way to put all the preerqs in a single tag:
            >
            > <feat id="feat.ambidexterity" source.page="Chap.5, Feat Descriptions">
            > <name>Ambidexterity</name>
            > <types>General.Fighter</types>
            > <prereqs>
            > <prereq type="hands" min="2" max="2"/>
            > <prereq type="stat" eq="1" min="15">DEX</prereq >
            > </prereqs>

            <pre>
            <pre var='hands' min='2' max='2' /> <!-- alt. eq='2' -->
            <pre stat='dex' min='15' />
            </pre>

            Ah, I see what you're using 'eq' for. In this scheme it'd be done
            something like:

            <pre>
            <pre var='hands' eq='2' />
            <pre min='1'>
            <pre stat='dex' min='15' />
            <pre stat='str' min='17' />
            </pre>
            </pre>

            "must have two hands and either Dex 15+ or Str 17+". By default a <pre>
            with children must have all children pass in order to be met.

            Oh, another point (hasn't come up yet): mixed elements are to be
            avoided. With a couple of notable exceptions, an element will be
            defined EMPTY, with child elements, or with #PCDATA. The major
            exception to this is for text-based elements like <description>, that
            allows formatted text. Other exceptions may be made, but I prefer to
            avoid them.

            Oh, and so you know, <desc> is a 'short description' -- one-liner to
            remind the reader what the thing is. A <description> is a marked-up
            text describing (an aspect of) an object in detail. There may be more
            than one <description>, such as for a fully-described feat:

            <feat>
            <description class='benefit' />
            <description class='note' />
            </feat>

            > <desc>See Text</desc>
            > <bonuses>
            > <bonus>COMBAT|TOHIT-SECONDARY|4</bonus>
            > </bonuses>
            > </feat>
            >
            >
            > Note: If you want to keep it as simple for the LST developers to move to
            > this syntax why not just keep the whole of the pre-req as a string?
            >
            > <prereqs>
            > <prereq>PREHANDSEQ|2</prereq>
            > <prereq>PRESTAT|1,DEX=15</prereq>
            > </prereqs>
            >
            > when you parse the file in, you have to convert the <prereq> content back
            > to the "PRESTAT|1,DEX=15" form to apply it to the bonus/feat/whatever
            > object anyway ;O)

            True. But it then complicates *my* software, where I expect to be able
            to do something like:

            class Prereq {
            bool meetPrereqs( Entity e)
            {
            //...
            }
            }

            ... and go recursive on the definition. I want to reduce things to a
            single normalized form. Also, I think a standard mechanism for prereqs
            that doesn't require the use of arbitrary text -- that must be parsed
            and the parser maintained -- will be simpler for new people to learn, as
            well.


            > It will make the schema a lot simple, parseing a lot simpler and
            > getting the LST monkies to buy in a lot simpler.

            There'd be a lower curve for those already experienced with LST prereqs.
            I think actually encoding the information in the elements might be
            simpler in the end, though.

            > If we want to move to a better syntax later we still can. I am just
            > trying to cut down the amount of work needed at this point.

            Understandable. My main disagreements here are that I don't -- never
            did -- want to do half a job, which the 'minimal conversion' would have
            been, and that such a scheme wouldn't meet *my* data needs.

            > <frugal is happy because this topic made him use his brain at work for
            > the first time in 2 weeks ;O) >

            Heh, I know the feeling. Have fun at the bonecracker.


            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
            ... So the Entity producer takes XML on disk and creates some intermediary data format. The EntityConsumer then takes that
            Message 5 of 13 , Nov 7, 2003
            • 0 Attachment
              <quote who="Keith Davies">
              > On Thu, Nov 06, 2003 at 03:55:36PM +0000, Frugal wrote:
              > Everything in the game is represented by an Entity or a subclass
              > thereof. There will be an interface 'EntityProducer' that does the
              > obvious. There will also be an interface 'EntityConsumer' that receives
              > the Entity objects produced by EntityProducer and does something with
              > them. So, what I picture is something like:
              >
              > public class XMLLoader implements EntityProducer {}
              > public class EntityLSTConsumer implements EntityConsumer {}
              >
              > On loading the XML file, the engine will take the Entity objects
              > produced by the XMLLoader and pass them to an EntityLSTConsumer. This
              > object will then convert the Entity to a PObject-based object and store
              > it as needed.

              So the Entity producer takes XML on disk and creates some intermediary
              data format.

              The EntityConsumer then takes that intermediary format and converts it to
              a POBject.

              So for the simplest case of XMLLoader the Entity could just be a JDOM
              Element for teh skill / feat / class etc?

              > In the case of a <bonus>, it can be attached to one of the <skill>s
              > related to the bonus. Or cached until one of the <skill>s is loaded, if
              > necessary.

              Looking at the code it may be straightforward to have "floating bonuses"
              that are not attached to anything.

              > The second isn't my requirement, it's Tir's. Personally I'd like to
              > nail down the order of child elements, it'd make things a fair whack
              > simpler.

              Personally I could not care what order the elements are in so long as we
              can validate the file. If we use somethign like JDOM we can deal with the
              child elements however we like regardless of order on disk.

              >> <feat>
              >> <name>Foo</name>
              >> <bonuses>
              >> <bonus>SKILL|Listen,Spot|2</bonus>
              >> <bonus>SKILL|Tumble|3</bonus>
              >> </bonuses>
              >> </feat>
              >
              > Which I kind of prefer anyway for many things -- keeps things tidier.

              So do I, I like all "list elements" to be in a "list parent".

              > <pre>
              > <pre var='hands' min='2' max='2' /> <!-- alt. eq='2' -->
              > <pre stat='dex' min='15' />
              > </pre>
              >
              > Ah, I see what you're using 'eq' for. In this scheme it'd be done
              > something like:

              I assumed that eq was for the 'count' when you had more than one option.

              > <pre>
              > <pre var='hands' eq='2' />
              > <pre min='1'>
              > <pre stat='dex' min='15' />
              > <pre stat='str' min='17' />
              > </pre>
              > </pre>
              >
              > "must have two hands and either Dex 15+ or Str 17+". By default a <pre>
              > with children must have all children pass in order to be met.

              So you want <pre> to have an attribute for each possible prereq? What are
              the differences in how the other attributes are used for each 'stat',
              'var' etc.

              How do you validate that you have exactly one of 'var', 'stat' etc in the
              element ?

              Would it not be easier from a parsing and validation point of view to have
              a 'type' attribute and a 'key' attribute.

              <pre>
              <pre kind='var' key='hands' eq='2' />
              <pre min='1'>
              <pre kind='stat' key='dex' min='15' />
              <pre kind='stat' key='str' min='17' />
              </pre>
              </pre>

              Then you can define 'type' to be a xs:NMTOKEN and emumerate all of the
              possible values.

              Can I suggest the use of <prereq> rather than <pre> so that people do not
              get it confused with the html tag. It is a little petty thing I know, but
              it is the sort of thing that will cause problems for some people.

              >> <desc>See Text</desc>
              >> <bonuses>
              >> <bonus>COMBAT|TOHIT-SECONDARY|4</bonus>
              >> </bonuses>
              >> </feat>

              So we will want to do something similar to <pre> for <bonus>

              <bonuses>
              <bonus kind="combat" key="tohit-secondary" value="4"/>
              <bonus kind="combat" key="ac" value="4"
              bonustype='NaturalArmor' replace="true" />
              </bonuses>

              Thanks to Jamie's bonus code rewrite there is a nice list of all of the
              available top level bonuses and their parameters ;O)

              > True. But it then complicates *my* software, where I expect to be able
              > to do something like:

              Just out of interest what is your software ?

              >> It will make the schema a lot simple, parseing a lot simpler and
              >> getting the LST monkies to buy in a lot simpler.
              >
              > There'd be a lower curve for those already experienced with LST prereqs.
              > I think actually encoding the information in the elements might be
              > simpler in the end, though.

              I guess it is a balancing act between doing somthing decent and doing
              something that will keep Tir happy.

              >> If we want to move to a better syntax later we still can. I am just
              >> trying to cut down the amount of work needed at this point.
              >
              > Understandable. My main disagreements here are that I don't -- never
              > did -- want to do half a job, which the 'minimal conversion' would have
              > been, and that such a scheme wouldn't meet *my* data needs.

              I guess I have been in a corporate environment too long. The only times I
              ever get to make a decent job of something is when I do not let management
              know what I am doing before I do it ;O)

              --
              regards,
              Frugal
              -OS Chimp
            • Keith Davies
              ... An EntityProducer creates an Entity. That s all you know. From disk, from a database, from a form where a user is doing data entry, whatever. It s just a
              Message 6 of 13 , Nov 7, 2003
              • 0 Attachment
                On Fri, Nov 07, 2003 at 09:11:33AM +0000, Frugal wrote:
                >
                > <quote who="Keith Davies">
                > > On Thu, Nov 06, 2003 at 03:55:36PM +0000, Frugal wrote: Everything
                > > in the game is represented by an Entity or a subclass thereof.
                > > There will be an interface 'EntityProducer' that does the obvious.
                > > There will also be an interface 'EntityConsumer' that receives the
                > > Entity objects produced by EntityProducer and does something with
                > > them. So, what I picture is something like:
                > >
                > > public class XMLLoader implements EntityProducer {} public class
                > > EntityLSTConsumer implements EntityConsumer {}
                > >
                > > On loading the XML file, the engine will take the Entity objects
                > > produced by the XMLLoader and pass them to an EntityLSTConsumer.
                > > This object will then convert the Entity to a PObject-based object
                > > and store it as needed.
                >
                > So the Entity producer takes XML on disk and creates some intermediary
                > data format.

                An EntityProducer creates an Entity. That's all you know. From disk,
                from a database, from a form where a user is doing data entry, whatever.
                It's just a source of data.

                > The EntityConsumer then takes that intermediary format and converts it to
                > a POBject.

                An EntityConsumer may be created that will take the intermediary format
                and convert it to PObject, yes.

                In my analysis I created a class called 'AtomicProducer' (implements
                Producer and Consumer). It was given a Producer and a Consumer. It
                collected Entity objects created by the Producer and cached them until
                the Producer said 'no more', then sprayed them all at the Consumer. By
                waiting until then, the AtomicProducer caused the happy situation of
                'nothing loaded until all loaded'; a syntax error in the file would not
                cause the load to leave incomplete data in the system. *Incorrect* data
                it could do nothing about, but a syntax error wouldn't cause a problem.

                It took 60 lines of code. And would work with any Producer and
                Consumer.

                Other uses for this mechanism:

                A Producer to pull data out of LST files (obviously).
                A Producer to pull data out of internal data store.
                A Producer that picks things up off a network connection.
                A Consumer to dump to file (XML, LST, HTML flavors).
                A Consumer to write to a database.
                A Consumer that pushes things through a network connection.

                There are others, as well.

                > So for the simplest case of XMLLoader the Entity could just be a JDOM
                > Element for teh skill / feat / class etc?

                I'd rather not, because I see this mechanism working for different data
                sources. I'd rather create an internal class and use that.

                > > In the case of a <bonus>, it can be attached to one of the <skill>s
                > > related to the bonus. Or cached until one of the <skill>s is loaded, if
                > > necessary.
                >
                > Looking at the code it may be straightforward to have "floating bonuses"
                > that are not attached to anything.

                That's good to hear.

                > > The second isn't my requirement, it's Tir's. Personally I'd like to
                > > nail down the order of child elements, it'd make things a fair whack
                > > simpler.
                >
                > Personally I could not care what order the elements are in so long as we
                > can validate the file. If we use somethign like JDOM we can deal with the
                > child elements however we like regardless of order on disk.

                It'd be nice to use existing tools for it. However, I was planning to
                use a metafile describing the structure of the various Entitys and how
                the elements map to them. Where things are '0..1', I'm told they
                currently just overwrite an existing value if a second one is found.
                Where things are 'm..n' they added together. A simple validation
                (beyond syntax in the data itself) would be to just run through and
                counts thing when done.

                > > <pre>
                > > <pre var='hands' min='2' max='2' /> <!-- alt. eq='2' -->
                > > <pre stat='dex' min='15' />
                > > </pre>
                > >
                > > Ah, I see what you're using 'eq' for. In this scheme it'd be done
                > > something like:
                >
                > I assumed that eq was for the 'count' when you had more than one option.

                Shorthand for 'min="val" max="val"'. I know it's redundant (which I
                usually don't like) but in this case I think it'd be useful enough to
                warrant it.

                Actually, how often *do* exact values come up in prereqs? I could be
                wrong.

                > > <pre>
                > > <pre var='hands' eq='2' />
                > > <pre min='1'>
                > > <pre stat='dex' min='15' />
                > > <pre stat='str' min='17' />
                > > </pre>
                > > </pre>
                > >
                > > "must have two hands and either Dex 15+ or Str 17+". By default a
                > > <pre> with children must have all children pass in order to be met.
                >
                > So you want <pre> to have an attribute for each possible prereq? What
                > are the differences in how the other attributes are used for each
                > 'stat', 'var' etc.

                In the Entity I was creating there wasn't one. What you'd *actually*
                see would be

                <pre var='stat.dex' />

                or

                <pre set='feats' contains='feat.power_attack' />

                > How do you validate that you have exactly one of 'var', 'stat' etc in
                > the element ?

                Throw an error if you find more than one? Which means moving this
                aspect of validation up. I'd rather have the library do it, of course,
                but it might not be too bad.

                > Would it not be easier from a parsing and validation point of view to have
                > a 'type' attribute and a 'key' attribute.
                >
                > <pre>
                > <pre kind='var' key='hands' eq='2' />
                > <pre min='1'>
                > <pre kind='stat' key='dex' min='15' />
                > <pre kind='stat' key='str' min='17' />
                > </pre>
                > </pre>
                >
                > Then you can define 'type' to be a xs:NMTOKEN and emumerate all of the
                > possible values.

                Kind, you mean? Dammit, I wish class weren't a domain term. The
                convention is to use 'class' to indicate what sort of thing an element
                actually is (like in the <description> below).

                > Can I suggest the use of <prereq> rather than <pre> so that people do not
                > get it confused with the html tag. It is a little petty thing I know, but
                > it is the sort of thing that will cause problems for some people.

                Sure. I tend to use <pre> because it's shorter and the contents can run
                long... three characters can make a difference <g>.

                > >> <desc>See Text</desc>
                > >> <bonuses>
                > >> <bonus>COMBAT|TOHIT-SECONDARY|4</bonus>
                > >> </bonuses>
                > >> </feat>
                >
                > So we will want to do something similar to <pre> for <bonus>

                Probably. Why not keep things consistent?

                > <bonuses>
                > <bonus kind="combat" key="tohit-secondary" value="4"/>
                > <bonus kind="combat" key="ac" value="4"
                > bonustype='NaturalArmor' replace="true" />
                > </bonuses>
                >
                > Thanks to Jamie's bonus code rewrite there is a nice list of all of the
                > available top level bonuses and their parameters ;O)
                >
                > > True. But it then complicates *my* software, where I expect to be able
                > > to do something like:
                >
                > Just out of interest what is your software ?

                Sort of similar, actually, but a little more... industrial. Not so
                pretty, I can just give it a stack of instructions and let it run.
                Also, my campaign rules, last I looked, would give PCGen fits.

                > >> It will make the schema a lot simple, parseing a lot simpler and
                > >> getting the LST monkies to buy in a lot simpler.
                > >
                > > There'd be a lower curve for those already experienced with LST
                > > prereqs. I think actually encoding the information in the elements
                > > might be simpler in the end, though.
                >
                > I guess it is a balancing act between doing somthing decent and doing
                > something that will keep Tir happy.

                Can be. OTOH, I'm looking for something that meets my needs. I can be
                flexible and make it useable by PCGen, which is why I started pursuing
                this (plus, if PCGen uses the same format, I can pillage the data <g>).

                I've decided to do it *right*. I'll let Tir worry about the rest; I'm
                not going to build to a shitty design to satisfy someone who doesn't
                understand the technology I'm working with.

                > >> If we want to move to a better syntax later we still can. I am just
                > >> trying to cut down the amount of work needed at this point.
                > >
                > > Understandable. My main disagreements here are that I don't --
                > > never did -- want to do half a job, which the 'minimal conversion'
                > > would have been, and that such a scheme wouldn't meet *my* data
                > > needs.
                >
                > I guess I have been in a corporate environment too long. The only
                > times I ever get to make a decent job of something is when I do not
                > let management know what I am doing before I do it ;O)

                LOL. I'm a contractor working for Government. I know *exactly* what
                you mean.

                "We want to you to update this program and make these changes."
                "Nasty stuff. It should be rebuilt from the ground up."
                "No, you don't have time for that."
                "I'm pretty sure I do, and it'll fix these other things too."
                "Just make the minimal changes needed."
                "Okay. I'll do the least I have to to make it work the way you want."

                <one week later>

                "How's it going?"
                "Well I had to modify the main menu to include the things you wanted, so
                while I was there I rearranged things a bit so they made more sense.
                The code's unstable right now because the changes are pretty deep, so I
                can't show you how it works yet."
                "Okay, keep me posted."

                <another week later>

                "Okay, I've got these modules working again the way you want. Except
                this one; the change in platform meant I had to rework *this* entirely."
                "Looks pretty good. It seems faster than before."
                "Yeah, I tidied up a bit, found some weird behavior possibly caused by
                the previous platform, probably caused by the meatheads who originally
                wrote it."
                "Heh, I remember them. Carry on."

                <two weeks after that>
                "Wow, you're done faster than expected. Apart from a couple of minor
                bugs it works *great*. It looks better and makes more sense."
                "Thanks."

                I ended up doing a full reimplementation in half the time they'd alloted
                for me to do 'make modifications'. I didn't, of course, tell them *how*
                I did it until afterward, when it was too late.

                Of course, if you try this and get it *wrong*, Bad Things Happen.


                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
                ... So there will be a separate Entity subclass for each Object type we wish to use. Will there be an Entity for things like
                Message 7 of 13 , Nov 13, 2003
                • 0 Attachment
                  <quote who="Keith Davies">
                  > On Fri, Nov 07, 2003 at 09:11:33AM +0000, Frugal wrote:
                  >> So the Entity producer takes XML on disk and creates some intermediary
                  >> data format.
                  >
                  > An EntityProducer creates an Entity. That's all you know. From disk,
                  > from a database, from a form where a user is doing data entry, whatever.
                  > It's just a source of data.

                  So there will be a separate Entity subclass for each Object type we wish
                  to use.

                  Will there be an Entity for things like <prereq> and <bonus> or are you
                  envisioning an Entity type for each top level type?

                  > In my analysis I created a class called 'AtomicProducer' (implements
                  > Producer and Consumer). It was given a Producer and a Consumer. It
                  > collected Entity objects created by the Producer and cached them until
                  > the Producer said 'no more', then sprayed them all at the Consumer. By
                  > waiting until then, the AtomicProducer caused the happy situation of
                  > 'nothing loaded until all loaded'; a syntax error in the file would not
                  > cause the load to leave incomplete data in the system. *Incorrect* data
                  > it could do nothing about, but a syntax error wouldn't cause a problem.
                  >
                  > It took 60 lines of code. And would work with any Producer and
                  > Consumer.

                  Do you have any of this code available? (rather than me rewrite it all
                  from scratch).

                  > Other uses for this mechanism:
                  >
                  > A Producer to pull data out of LST files (obviously).
                  > A Producer to pull data out of internal data store.
                  > A Producer that picks things up off a network connection.
                  > A Consumer to dump to file (XML, LST, HTML flavors).
                  > A Consumer to write to a database.
                  > A Consumer that pushes things through a network connection.

                  So we could have an LST Producer and an XML Consumer to convert all of the
                  data.

                  What I would like to do is rewrite the current persistance routines to use
                  a LST Producer and and PObject Consumer, then write an XML Consumer and an
                  XML Producer.

                  --
                  regards,
                  Frugal
                  -OS Chimp
                • Keith Davies
                  ... There *could* be. I originally had in mind a more generic data type that could just hold stuff , and a meta file that describes how the various elements
                  Message 8 of 13 , Nov 13, 2003
                  • 0 Attachment
                    On Thu, Nov 13, 2003 at 09:43:54AM +0000, Frugal wrote:
                    > <quote who="Keith Davies">
                    > > On Fri, Nov 07, 2003 at 09:11:33AM +0000, Frugal wrote:
                    > >> So the Entity producer takes XML on disk and creates some intermediary
                    > >> data format.
                    > >
                    > > An EntityProducer creates an Entity. That's all you know. From disk,
                    > > from a database, from a form where a user is doing data entry, whatever.
                    > > It's just a source of data.
                    >
                    > So there will be a separate Entity subclass for each Object type we
                    > wish to use.

                    There *could* be. I originally had in mind a more generic data type
                    that could just 'hold stuff', and a meta file that describes how the
                    various elements map to things. I decided that it was going to result
                    in big, fat data objects that I didn't want to deal with at that time...
                    and I couldn't come up with a meta language that satisfied me.

                    > Will there be an Entity for things like <prereq> and <bonus> or are
                    > you envisioning an Entity type for each top level type?

                    Entitys are top-level objects, things we care about at the game level.
                    prereqs and bonuses are implementational items; there are different
                    rules and requirements for them (each Entity has an ID, a prereq need
                    not).

                    > > In my analysis I created a class called 'AtomicProducer' (implements
                    > > Producer and Consumer). It was given a Producer and a Consumer. It
                    > > collected Entity objects created by the Producer and cached them until
                    > > the Producer said 'no more', then sprayed them all at the Consumer. By
                    > > waiting until then, the AtomicProducer caused the happy situation of
                    > > 'nothing loaded until all loaded'; a syntax error in the file would not
                    > > cause the load to leave incomplete data in the system. *Incorrect* data
                    > > it could do nothing about, but a syntax error wouldn't cause a problem.
                    > >
                    > > It took 60 lines of code. And would work with any Producer and
                    > > Consumer.
                    >
                    > Do you have any of this code available? (rather than me rewrite it all
                    > from scratch).

                    I do, but I'm not satisfied with it. I never quite got around to
                    building the data load portion of it. The AtomicProducer worked with
                    the interfaces alone, so it didn't need the concrete classes
                    implemented.

                    I've got another way to do this; I'm home this week and more or less
                    over my cold, so I'll try to get something cut this weekend.

                    > > Other uses for this mechanism:
                    > >
                    > > A Producer to pull data out of LST files (obviously).
                    > > A Producer to pull data out of internal data store.
                    > > A Producer that picks things up off a network connection.
                    > > A Consumer to dump to file (XML, LST, HTML flavors).
                    > > A Consumer to write to a database.
                    > > A Consumer that pushes things through a network connection.
                    >
                    > So we could have an LST Producer and an XML Consumer to convert all of
                    > the data.

                    Yep. At least, that's the plan.

                    > What I would like to do is rewrite the current persistance routines to
                    > use a LST Producer and and PObject Consumer, then write an XML
                    > Consumer and an XML Producer.

                    By PObject Consumer I assume you mean 'consumes Entity and turns into
                    PObject'? If so, that's what I had in mind. Replace the entire
                    persistence layer and build a more or less standalone library. Said
                    library is something I need for my own work, apart from PCGen, so it's
                    of significant interest to me.

                    I'm trying to get my folks' computer set up on wireless; I'll be back in
                    a bit.


                    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
                  • S Woodside
                    Hi, I m interested in using XML output from PCGen for various purposes so I ve been lurking on this list for quite some time now hoping to see activity. Now
                    Message 9 of 13 , Nov 18, 2003
                    • 0 Attachment
                      Hi, I'm interested in using XML output from PCGen for various purposes
                      so I've been lurking on this list for quite some time now hoping to see
                      activity. Now I'm happy ! :-) So some comments... (mainly on the
                      subject of making the XML more usable for parsers and styling engines
                      that I might write (mainly in XSLT))

                      On Thursday, November 6, 2003, at 05:33 AM, Frugal wrote:

                      > <skill id="skill.diplomacy" source.page="Chap.4, Skill Descriptions">

                      General XML theory (an my opinion) is that attributes should be used
                      for machine-readable information only. So, is source.page="Chap.4,
                      Skill Descriptions" machine readable? It doesn't look like it.

                      > <effects>
                      > <bonus>SKILL|Diplomacy|2|TYPE=Synergy.STACK</bonus>

                      This is not good... It's not good to have text inside an element that
                      must be parsed in non-xml fashion. This sould bemore like:

                      <bonus>
                      <type>SKILL</type>
                      <name>Diplomacy</name>
                      <ranks (?)>2</ranks>
                      <something>TYPE=Synergy.STACK</something>
                      </bonus>

                      simon

                      > <effects>
                      > <bonus>SKILL|Diplomacy|2|TYPE=Synergy.STACK</bonus>
                      > <prereqs>
                      > <preskill min="5">Sense Motive</preskill>
                      > </prereqs>
                      > </effects>
                      > <prereqs>
                      > <preskill min="5">Bluff</preskill>
                      > </prereqs>
                      > </effects>
                      > <keystat>CHA</keystat>
                      > <name>Diplomacy</name>
                      > <types>Charisma</types>
                      > </skill>
                      >

                      --
                      www.simonwoodside.com :: www.openict.net :: www.semacode.org
                      99% Devil, 1% Angel
                    • Keith Davies
                      ... I disagree with general XML theory, then. In this case, source information is held in attributes because it is applicable to all entities and data
                      Message 10 of 13 , Nov 18, 2003
                      • 0 Attachment
                        On Tue, Nov 18, 2003 at 03:11:08PM -0500, S Woodside wrote:
                        > Hi, I'm interested in using XML output from PCGen for various purposes
                        > so I've been lurking on this list for quite some time now hoping to
                        > see activity. Now I'm happy ! :-) So some comments... (mainly on the
                        > subject of making the XML more usable for parsers and styling engines
                        > that I might write (mainly in XSLT))
                        >
                        > On Thursday, November 6, 2003, at 05:33 AM, Frugal wrote:
                        >
                        > > <skill id="skill.diplomacy" source.page="Chap.4, Skill Descriptions">
                        >
                        > General XML theory (an my opinion) is that attributes should be used
                        > for machine-readable information only. So, is source.page="Chap.4,
                        > Skill Descriptions" machine readable? It doesn't look like it.

                        I disagree with general XML theory, then. <g>

                        In this case, source information is held in attributes because it is
                        applicable to all entities and data elements, and inheritable. I know
                        this can be done with elements, but I find attributes make it simpler
                        for me.

                        > > <effects>
                        > > <bonus>SKILL|Diplomacy|2|TYPE=Synergy.STACK</bonus>
                        >
                        > This is not good... It's not good to have text inside an element that
                        > must be parsed in non-xml fashion. This should bemore like:
                        >
                        > <bonus>
                        > <type>SKILL</type>
                        > <name>Diplomacy</name>
                        > <ranks (?)>2</ranks>
                        > <something>TYPE=Synergy.STACK</something>
                        > </bonus>

                        I think Frugal and I hashed this out downthread.

                        And, FWIW, the <bonus> up there interprets more or less as:

                        "A +2 synergy bonus to Diplomacy skill checks."

                        The type is actually synergy, 'Diplomacy' is a reference to that skill,
                        the '2' is the bonus value. The .STACK indicates that it can stack with
                        other synergy bonuses to the same skill.

                        The original example that Frugal's quoting above came out of a script I
                        hacked in Perl to autoconvert things. I hadn't put a lot of thought
                        into bonuses (since I'm not fluent in LST and didn't want to spend the
                        time to figure out how to read the syntax at that time) so I just dumped
                        the text of the tag into an element.


                        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
                        ... I must confess that I have alway thought of attributes as: Things that give more information about a particular element but do
                        Message 11 of 13 , Nov 19, 2003
                        • 0 Attachment
                          <quote who="Keith Davies">
                          > On Tue, Nov 18, 2003 at 03:11:08PM -0500, S Woodside wrote:
                          >> General XML theory (an my opinion) is that attributes should be used
                          >> for machine-readable information only. So, is source.page="Chap.4,
                          >> Skill Descriptions" machine readable? It doesn't look like it.
                          >
                          > I disagree with general XML theory, then. <g>
                          >
                          > In this case, source information is held in attributes because it is
                          > applicable to all entities and data elements, and inheritable. I know
                          > this can be done with elements, but I find attributes make it simpler
                          > for me.

                          I must confess that I have alway thought of attributes as: Things that
                          give more information about a particular element but do not make any sense
                          as an element on their own.

                          >> This is not good... It's not good to have text inside an element that
                          >> must be parsed in non-xml fashion. This should bemore like:
                          >>
                          >> <bonus>
                          >> <type>SKILL</type>
                          >> <name>Diplomacy</name>
                          >> <ranks (?)>2</ranks>
                          >> <something>TYPE=Synergy.STACK</something>
                          >> </bonus>
                          >
                          > I think Frugal and I hashed this out downthread.
                          >
                          > And, FWIW, the <bonus> up there interprets more or less as:
                          >
                          > "A +2 synergy bonus to Diplomacy skill checks."
                          >
                          > The type is actually synergy, 'Diplomacy' is a reference to that skill,
                          > the '2' is the bonus value. The .STACK indicates that it can stack with
                          > other synergy bonuses to the same skill.

                          And here is one I prepared eariler ;O)

                          <skill id="skill.diplomacy" source:page="Chap.4, Skill Descriptions"
                          acheck="false" exclusive="false" useuntrained="true">
                          <name>Diplomacy</name>
                          <types>
                          <type>Charisma</type>
                          </types>
                          <bonuses>
                          <bonus kind="SKILL" key="Diplomacy" formula="2"
                          bonustype="SYNERGY" stacks="true">
                          <prereq kind="skill" key="skill.bluff" min="5"/>
                          </bonus>
                          <bonus kind="SKILL" key="Diplomacy" formula="2"
                          bonustype="SYNERGY" stacks="true">
                          <prereq kind="skill" key="skill.sense_motive" min="5"/>
                          </bonus>
                          </bonuses>
                          <keystat>CHA</keystat>
                          </skill>

                          The above example came out of the sample source code that I posted last
                          night.

                          --
                          regards,
                          Frugal
                          -OS Chimp
                        • S Woodside
                          ... You mean it s easier when writing the schema, or easier to use ;-) I thinkit s OK to have source info in an attribute if it s machine readable though.
                          Message 12 of 13 , Nov 19, 2003
                          • 0 Attachment
                            On Tuesday, November 18, 2003, at 04:17 PM, Keith Davies wrote:

                            >>> <skill id="skill.diplomacy" source.page="Chap.4, Skill Descriptions">
                            >>
                            >> General XML theory (an my opinion) is that attributes should be used
                            >> for machine-readable information only. So, is source.page="Chap.4,
                            >> Skill Descriptions" machine readable? It doesn't look like it.
                            >
                            > I disagree with general XML theory, then. <g>
                            >
                            > In this case, source information is held in attributes because it is
                            > applicable to all entities and data elements, and inheritable. I know
                            > this can be done with elements, but I find attributes make it simpler
                            > for me.

                            You mean it's easier when writing the schema, or easier to use ;-)

                            I thinkit's OK to have source info in an attribute if it's machine
                            readable though.

                            simon
                          • Keith Davies
                            ... For me, both. I find really big namespaces harder to use. ... It is machine readable. The machine doesn t have to do anything but present it. I put the
                            Message 13 of 13 , Nov 19, 2003
                            • 0 Attachment
                              On Wed, Nov 19, 2003 at 08:06:07PM -0500, S Woodside wrote:
                              >
                              > On Tuesday, November 18, 2003, at 04:17 PM, Keith Davies wrote:
                              >
                              > >>> <skill id="skill.diplomacy" source.page="Chap.4, Skill Descriptions">
                              > >>
                              > >> General XML theory (an my opinion) is that attributes should be used
                              > >> for machine-readable information only. So, is source.page="Chap.4,
                              > >> Skill Descriptions" machine readable? It doesn't look like it.
                              > >
                              > > I disagree with general XML theory, then. <g>
                              > >
                              > > In this case, source information is held in attributes because it is
                              > > applicable to all entities and data elements, and inheritable. I know
                              > > this can be done with elements, but I find attributes make it simpler
                              > > for me.
                              >
                              > You mean it's easier when writing the schema, or easier to use ;-)

                              For me, both. I find really big namespaces harder to use.

                              > I thinkit's OK to have source info in an attribute if it's machine
                              > readable though.

                              It is machine readable. The machine doesn't have to do anything but
                              present it. I put the source information in attributes because it is an
                              attribute of the element, and all child elements that do not override
                              it. The obvious other way to do it would have entities looking at
                              sibling elements to see what to inherit... this seems very odd to me.

                              I'd make source information an element of its own if it were necessary,
                              but in this case I don't believe it is and using attributes instead
                              seems more natural.


                              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.