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

Re: [pcgen-xml] Question regarding

Expand Messages
  • 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 1 of 13 , Nov 13, 2003
      <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 2 of 13 , Nov 13, 2003
        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 3 of 13 , Nov 18, 2003
          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 4 of 13 , Nov 18, 2003
            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 5 of 13 , Nov 19, 2003
              <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 6 of 13 , Nov 19, 2003
                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 7 of 13 , Nov 19, 2003
                  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.