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

XML example

Expand Messages
  • STILES, BRAD
    ... This is something one of the guys on the D20 XML list came up with for a spell list. It s an extract from the D20 SRD. I suspect that what we come up with
    Message 1 of 22 , Jan 10, 2002
    • 0 Attachment
      > -----Original Message-----
      > From: samspectre
      >
      > Could someone post their idea of what an XML .LST file would like?
      > It doesn't have to be full file, just the heading and one or two
      > items...

      This is something one of the guys on the D20 XML list came up with for a
      spell list. It's an extract from the D20 SRD.

      I suspect that what we come up with will be similar, though from what I've
      read, using attributes rather than bodies in the elements is more parser
      friendly.

      <d20xml>
      <spell>
      <name>Acid Fog</name>
      <short-description>Fog deals acid
      damage.</short-description>
      <school>Conjuration</school>
      <sub-school>Creation</sub-school>
      <type>Acid</type>
      <classes>
      <class level='6'>Sorcerer</class>
      <class level='6'>Wizard</class>
      <class level='7'>Water</class>
      </classes>
      <components>
      <component>V</component>
      <component>S</component>
      <component>M/DF</component>
      </components>
      <casting-time>1 action</casting-time>
      <range>Medium (100 ft. + 10 ft./level)</range>
      <effect>Fog spreads 30 ft., 20 ft. high</effect>
      <duration>1 round/level</duration>
      <saving-throw>None</saving-throw>
      <spell-resistance>Yes</spell-resistance>
      <long-description>
      <p>This spell's vapors are highly acidic. Each
      round, starting
      when you cast the spell, the fog deals 2d6 points of
      acid damage
      to creatures and objects within it.</p>
      </long-description>
      </spell>
      </d20xml>
    • kyuzo184
      I don t know much about what is and what is not parser friendly but I do know that example is fairly easy to read and understand. I think name and type could
      Message 2 of 22 , Jan 10, 2002
      • 0 Attachment
        I don't know much about what is and what is not parser friendly but I
        do know that example is fairly easy to read and understand. I think
        name and type could probably be attributes of <spell>. And maybe sub-
        school as an attribute of <school>.

        My feeling is that attributes are all well and good as long as you
        don't over use them. I guess that is because I'm a scroll down sort
        of guy as opposed to a scroll right sort of guy.

        How do other people feel about this?

        -Stefan

        --- In pcgen-xml@y..., "STILES, BRAD" <BRAD.STILES@s...> wrote:
        > > -----Original Message-----
        > > From: samspectre
        > >
        > > Could someone post their idea of what an XML .LST file would
        like?
        > > It doesn't have to be full file, just the heading and one or two
        > > items...
        >
        > This is something one of the guys on the D20 XML list came up with
        for a
        > spell list. It's an extract from the D20 SRD.
        >
        > I suspect that what we come up with will be similar, though from
        what I've
        > read, using attributes rather than bodies in the elements is more
        parser
        > friendly.
        >
        > <d20xml>
        > <spell>
        > <name>Acid Fog</name>
        > <short-description>Fog deals acid
        > damage.</short-description>
        > <school>Conjuration</school>
        > <sub-school>Creation</sub-school>
        > <type>Acid</type>
        > <classes>
        > <class level='6'>Sorcerer</class>
        > <class level='6'>Wizard</class>
        > <class level='7'>Water</class>
        > </classes>
        > <components>
        > <component>V</component>
        > <component>S</component>
        > <component>M/DF</component>
        > </components>
        > <casting-time>1 action</casting-time>
        > <range>Medium (100 ft. + 10 ft./level)</range>
        > <effect>Fog spreads 30 ft., 20 ft. high</effect>
        > <duration>1 round/level</duration>
        > <saving-throw>None</saving-throw>
        > <spell-resistance>Yes</spell-resistance>
        > <long-description>
        > <p>This spell's vapors are highly acidic. Each
        > round, starting
        > when you cast the spell, the fog deals 2d6
        points of
        > acid damage
        > to creatures and objects within it.</p>
        > </long-description>
        > </spell>
        > </d20xml>
      • STILES, BRAD
        No so much friendly as more efficient. Most parsers are apparently optimized to handle attributes rather than elements with text bodies. While I agree that
        Message 3 of 22 , Jan 10, 2002
        • 0 Attachment
          No so much friendly as more efficient. Most parsers are apparently
          optimized to handle attributes rather than elements with text bodies. While
          I agree that we shouldn't overdo attributes, we need to keep this
          optimization issue in mind.

          > -----Original Message-----
          > From: kyuzo184 [mailto:sh@...]
          > Sent: Thursday, January 10, 2002 12:00
          > To: pcgen-xml@yahoogroups.com
          > Subject: [pcgen-xml] Re: XML example
          >
          >
          > I don't know much about what is and what is not parser friendly but I
          > do know that example is fairly easy to read and understand. I think
          > name and type could probably be attributes of <spell>. And maybe sub-
          > school as an attribute of <school>.
          >
          > My feeling is that attributes are all well and good as long as you
          > don't over use them. I guess that is because I'm a scroll down sort
          > of guy as opposed to a scroll right sort of guy.
          >
          > How do other people feel about this?
          >
          > -Stefan
          >
          > --- In pcgen-xml@y..., "STILES, BRAD" <BRAD.STILES@s...> wrote:
          > > > -----Original Message-----
          > > > From: samspectre
          > > >
          > > > Could someone post their idea of what an XML .LST file would
          > like?
          > > > It doesn't have to be full file, just the heading and one or two
          > > > items...
          > >
          > > This is something one of the guys on the D20 XML list came up with
          > for a
          > > spell list. It's an extract from the D20 SRD.
          > >
          > > I suspect that what we come up with will be similar, though from
          > what I've
          > > read, using attributes rather than bodies in the elements is more
          > parser
          > > friendly.
          > >
          > > <d20xml>
          > > <spell>
          > > <name>Acid Fog</name>
          > > <short-description>Fog deals acid
          > > damage.</short-description>
          > > <school>Conjuration</school>
          > > <sub-school>Creation</sub-school>
          > > <type>Acid</type>
          > > <classes>
          > > <class level='6'>Sorcerer</class>
          > > <class level='6'>Wizard</class>
          > > <class level='7'>Water</class>
          > > </classes>
          > > <components>
          > > <component>V</component>
          > > <component>S</component>
          > > <component>M/DF</component>
          > > </components>
          > > <casting-time>1 action</casting-time>
          > > <range>Medium (100 ft. + 10 ft./level)</range>
          > > <effect>Fog spreads 30 ft., 20 ft. high</effect>
          > > <duration>1 round/level</duration>
          > > <saving-throw>None</saving-throw>
          > > <spell-resistance>Yes</spell-resistance>
          > > <long-description>
          > > <p>This spell's vapors are highly acidic. Each
          > > round, starting
          > > when you cast the spell, the fog deals 2d6
          > points of
          > > acid damage
          > > to creatures and objects within it.</p>
          > > </long-description>
          > > </spell>
          > > </d20xml>
          >
          >
          > ------------------------ Yahoo! Groups Sponsor
          > ---------------------~-->
          > Sponsored by VeriSign - The Value of Trust
          > Pinpoint the right security solution for your company - FREE
          > Guide from industry leader VeriSign gives you all the facts.
          > http://us.click.yahoo.com/pCuuSA/WdiDAA/yigFAA/2U_rlB/TM
          > --------------------------------------------------------------
          > -------~->
          >
          > To unsubscribe from this group, send an email to:
          > pcgen-xml-unsubscribe@yahoogroups.com
          >
          >
          >
          > Your use of Yahoo! Groups is subject to
          > http://docs.yahoo.com/info/terms/
          >
          >
        • Mynex
          Yes, optimization will be an issue, but we need to keep in mind joe user as well. It has to be _REALLY_ easy for them to edit the information. As a note, I
          Message 4 of 22 , Jan 10, 2002
          • 0 Attachment
            Yes, optimization will be an issue, but we need to keep in mind joe user
            as well. It has to be _REALLY_ easy for them to edit the information.
            As a note, I liked what you did with the coins personally, and we should
            do that wherever we can for short, 1st few fields stuff, then expand
            down for others..

            Using your own coins for an example, use the line as it is, (name, wt,
            cost) and then the next attribute would be Bonus, next attribute down,
            PRE, next down, SPROP, ect...

            If we can keep the most common (short) elements in one line (80 width
            only?) and special/long stuff (DESC, SPROP, etc) in it's own elements,
            I'd say we'd be able to optimize AND make it easy for joe user to
            read/edit/modify

            Mynex

            - Dark Sith Silverback Android, Dark Lord of the Docs, The Sleepless One


            -----Original Message-----
            From: STILES, BRAD [mailto:BRAD.STILES@...]
            Sent: Thursday, January 10, 2002 12:07 PM
            To: 'PCGen XML'
            Subject: RE: [pcgen-xml] Re: XML example

            No so much friendly as more efficient. Most parsers are apparently
            optimized to handle attributes rather than elements with text bodies.
            While
            I agree that we shouldn't overdo attributes, we need to keep this
            optimization issue in mind.
          • STILES, BRAD
            ... Yep, but one nice thing about XML is that when we get to the point where there is a Schema, writing an editor that uses it will be moderately less complex.
            Message 5 of 22 , Jan 10, 2002
            • 0 Attachment
              > -----Original Message-----
              > From: Mynex
              >
              > Yes, optimization will be an issue, but we need to keep in
              > mind joe user as well. It has to be _REALLY_ easy for them
              > to edit the information.

              Yep, but one nice thing about XML is that when we get to the point where
              there is a Schema, writing an editor that uses it will be moderately less
              complex.

              > Using your own coins for an example, use the line as it is, (name, wt,
              > cost) and then the next attribute would be Bonus, next attribute down,
              > PRE, next down, SPROP, ect...

              While I agree with you, I want to note that some items, such as bonuses,
              will likely be elements all by themselves, to be included in other elements.
              The BONUS element specifically would likely have many forms, and each would
              have it's own schema, or mayb eone schema that encompasses all the
              permutations.

              <item type="weapon" name="Spurious Example">
              <otherattributesandelements/>
              <bonus towhat="ToHit" value="+1" type="Enhancement"/>
              <bonus towhat="Damage" value="+1" type="Enhancement"/>
              </item>

              <item type="Feat" name="Run">
              <otherattributesandelements/>
              <bonus towhat="Skill" item="Jump" value="1.25" operator="multiply"/>
              </item>

              These are not intended to be exhaustive examples. In fact, it might be a
              good idea to go through all of the LST files, find all of the bonus tags,
              and attempt to unify them into one set of required and optional attributes
              that can then be assembled into any combination needed for a particular
              purpose.

              > If we can keep the most common (short) elements in one line (80 width
              > only?)

              Perfectly reasonable, and the syntactic requirements of XML make it
              relatively easy to assemble in a very readable form.


              Brad
            • Mynex
              1) That s exactly what I meant, just didn t explain it very well. ;p So we see eye-to-eye on that. :D 2) Going through the list files, hmm.., never heard of
              Message 6 of 22 , Jan 10, 2002
              • 0 Attachment
                1) That's exactly what I meant, just didn't explain it very well. ;p So
                we see eye-to-eye on that. :D

                2) Going through the list files, hmm.., never heard of anyone doing that
                before. ;p Standardizing stuff in the list files? You heathen! You
                Blasphemer! And Document them all? Are you mad? :D

                Mynex

                - Dark Sith Silverback Android, Dark Lord of the Docs, The Sleepless One


                -----Original Message-----
                From: STILES, BRAD [mailto:BRAD.STILES@...]
                Sent: Thursday, January 10, 2002 1:40 PM
                To: 'PCGen XML'
                Subject: RE: [pcgen-xml] Re: XML example


                > Using your own coins for an example, use the line as it is, (name, wt,
                > cost) and then the next attribute would be Bonus, next attribute down,
                > PRE, next down, SPROP, ect...

                While I agree with you, I want to note that some items, such as bonuses,
                will likely be elements all by themselves, to be included in other
                elements.
                The BONUS element specifically would likely have many forms, and each
                would
                have it's own schema, or mayb eone schema that encompasses all the
                permutations.

                <item type="weapon" name="Spurious Example">
                <otherattributesandelements/>
                <bonus towhat="ToHit" value="+1" type="Enhancement"/>
                <bonus towhat="Damage" value="+1" type="Enhancement"/>
                </item>

                <item type="Feat" name="Run">
                <otherattributesandelements/>
                <bonus towhat="Skill" item="Jump" value="1.25"
                operator="multiply"/>
                </item>

                These are not intended to be exhaustive examples. In fact, it might be
                a
                good idea to go through all of the LST files, find all of the bonus
                tags,
                and attempt to unify them into one set of required and optional
                attributes
                that can then be assembled into any combination needed for a particular
                purpose.
              • Ryan Koppenhaver
                ... Well, one of the advantages of XML is that as long as you conform to the (reasonably strict, more so than HTML) rules[1], any parser should be able to
                Message 7 of 22 , Jan 10, 2002
                • 0 Attachment
                  --- kyuzo184 <sh@...> wrote:
                  > I don't know much about what is and what is not parser friendly but I

                  Well, one of the advantages of XML is that as long as you conform to
                  the (reasonably strict, more so than HTML) rules[1], any parser should
                  be able to parse your document. Though, as someone else points out in
                  another email, efficiency is an issue too.

                  [1] Documents that follow the rules of XML are said to be
                  "well-formed". There's another level of rules-following, called
                  "validity", which relates to rules for a specific type of document,
                  e.g., a "spell list" type document would have to be full of "spell"
                  elements, and not "feat" elements.

                  > [snip]
                  > My feeling is that attributes are all well and good as long as you
                  > don't over use them. I guess that is because I'm a scroll down sort
                  > of guy as opposed to a scroll right sort of guy.

                  True, but remember, whitespace in xml is insignificant, so I could
                  write something like:

                  <element attribute1="foo"
                  attribute2="bar"
                  attribute3="baz"
                  ....
                  />

                  If my elements got too long for one line.

                  -Ryan


                  __________________________________________________
                  Do You Yahoo!?
                  Send FREE video emails in Yahoo! Mail!
                  http://promo.yahoo.com/videomail/
                • Ryan Koppenhaver
                  ... Well, the thing that immediately jumps out at me is either: or we could do:
                  Message 8 of 22 , Jan 10, 2002
                  • 0 Attachment
                    --- "STILES, BRAD" <BRAD.STILES@...> wrote:
                    > The BONUS element specifically would likely have many forms, and each
                    > would
                    > have it's own schema, or mayb eone schema that encompasses all the
                    > permutations.

                    Well, the thing that immediately jumps out at me is either:

                    <bonus type="enhancement" to="toHit" amount="3" />

                    or we could do:

                    <bonus>
                    <type name="enhancement" />
                    <bonusto affects="toHit" amount="3" />
                    <bonusto affects="damage" amount="3" />
                    </bonus>

                    or some combination thereof:

                    <bonus type="enhancement">
                    <bonusto affects="toHit" amount="3" />
                    <bonusto affects="damage" amount="3" />
                    </bonus>

                    Personally, I'm partial to the first or the third.

                    Perhaps PCGen wouldn't even need to know what a "toHit" bonus does, it
                    would just find a reference on a character sheet to "toHit", and add up
                    all the bonuses that apply at that point.

                    -Ryan



                    __________________________________________________
                    Do You Yahoo!?
                    Send FREE video emails in Yahoo! Mail!
                    http://promo.yahoo.com/videomail/
                  • Keith Davies
                    ... And less typing, too. At this point, I m leaning toward having the various lists being resources used to define others. For example (and counter to your
                    Message 9 of 22 , Jan 10, 2002
                    • 0 Attachment
                      STILES, BRAD wrote on Thu Jan 10 08:33:51 2002:
                      >
                      > > -----Original Message-----
                      > > From: samspectre
                      > >
                      > > Could someone post their idea of what an XML .LST file would like?
                      > > It doesn't have to be full file, just the heading and one or two
                      > > items...
                      >
                      > This is something one of the guys on the D20 XML list came up with for a
                      > spell list. It's an extract from the D20 SRD.
                      >
                      > I suspect that what we come up with will be similar, though from what I've
                      > read, using attributes rather than bodies in the elements is more parser
                      > friendly.

                      And less typing, too.

                      At this point, I'm leaning toward having the various lists being
                      resources used to define others. For example (and counter to your
                      sample below), I'd remove the <classes> below and have <spelllist>
                      contain the spell and level, something like:

                      <spellist name="Sorcerer/Wizard" id="spelllist.sorwiz">
                      <spellref spellid="spell.acid-fog" level="6"/>
                      </spelllist>

                      <domain name="Water" id="domain.water">
                      <domainpower>...</domainpower>
                      <spellref spellid="spell.acid-fog" level="7"/>
                      </domain>

                      The spell could be managed like:

                      <spell name="Acid Fog" refname="acid fog" id="spell.acid-fog"
                      verbal="Y" somatic="Y" save="None" range="medium">
                      <brief>Deals 2d6 hp/round damage to all creatures in area of effect.</brief>
                      </spell>

                      Then <class> could look like

                      <class name="Sorcerer" id="class.sorcerer">
                      <spellists>
                      <spelllistref refid="spelllist.sorwiz"
                      </spelllists>
                      </class>


                      Still drawing up the list, though.

                      > <d20xml>
                      > <spell>
                      > <name>Acid Fog</name>
                      > <short-description>Fog deals acid
                      > damage.</short-description>
                      > <school>Conjuration</school>
                      > <sub-school>Creation</sub-school>
                      > <type>Acid</type>
                      > <classes>
                      > <class level='6'>Sorcerer</class>
                      > <class level='6'>Wizard</class>
                      > <class level='7'>Water</class>
                      > </classes>
                      > <components>
                      > <component>V</component>
                      > <component>S</component>
                      > <component>M/DF</component>
                      > </components>
                      > <casting-time>1 action</casting-time>
                      > <range>Medium (100 ft. + 10 ft./level)</range>
                      > <effect>Fog spreads 30 ft., 20 ft. high</effect>
                      > <duration>1 round/level</duration>
                      > <saving-throw>None</saving-throw>
                      > <spell-resistance>Yes</spell-resistance>
                      > <long-description>
                      > <p>This spell's vapors are highly acidic. Each
                      > round, starting
                      > when you cast the spell, the fog deals 2d6 points of
                      > acid damage
                      > to creatures and objects within it.</p>
                      > </long-description>
                      > </spell>
                      > </d20xml>


                      Keith
                      --
                      Keith Davies
                      kjdavies@...

                      Elarios: "Shade, you showed honor and mercy
                      "Raven, you were couragous beyond expectation
                      "Logan, you resisted the temptation of knowledge."

                      Logan: "That's... good, right?"
                    • Karl-Petter Åkesson
                      Hi, Just a bit of curiosity... If there is an D20XML why dont we use it for PCGen? Kalle
                      Message 10 of 22 , Jan 10, 2002
                      • 0 Attachment
                        Hi,

                        Just a bit of curiosity... If there is an D20XML why dont we use it for
                        PCGen?

                        Kalle

                        Keith Davies wrote:
                        >
                        > STILES, BRAD wrote on Thu Jan 10 08:33:51 2002:
                        > >
                        > > > -----Original Message-----
                        > > > From: samspectre
                        > > >
                        > > > Could someone post their idea of what an XML .LST file would like?
                        > > > It doesn't have to be full file, just the heading and one or two
                        > > > items...
                        > >
                        > > This is something one of the guys on the D20 XML list came up with for a
                        > > spell list. It's an extract from the D20 SRD.
                        > >
                        > > I suspect that what we come up with will be similar, though from what I've
                        > > read, using attributes rather than bodies in the elements is more parser
                        > > friendly.
                        >
                        > And less typing, too.
                        >
                        > At this point, I'm leaning toward having the various lists being
                        > resources used to define others. For example (and counter to your
                        > sample below), I'd remove the <classes> below and have <spelllist>
                        > contain the spell and level, something like:
                        >
                        > <spellist name="Sorcerer/Wizard" id="spelllist.sorwiz">
                        > <spellref spellid="spell.acid-fog" level="6"/>
                        > </spelllist>
                        >
                        > <domain name="Water" id="domain.water">
                        > <domainpower>...</domainpower>
                        > <spellref spellid="spell.acid-fog" level="7"/>
                        > </domain>
                        >
                        > The spell could be managed like:
                        >
                        > <spell name="Acid Fog" refname="acid fog" id="spell.acid-fog"
                        > verbal="Y" somatic="Y" save="None" range="medium">
                        > <brief>Deals 2d6 hp/round damage to all creatures in area of effect.</brief>
                        > </spell>
                        >
                        > Then <class> could look like
                        >
                        > <class name="Sorcerer" id="class.sorcerer">
                        > <spellists>
                        > <spelllistref refid="spelllist.sorwiz"
                        > </spelllists>
                        > </class>
                        >
                        > Still drawing up the list, though.
                        >
                        > > <d20xml>
                        > > <spell>
                        > > <name>Acid Fog</name>
                        > > <short-description>Fog deals acid
                        > > damage.</short-description>
                        > > <school>Conjuration</school>
                        > > <sub-school>Creation</sub-school>
                        > > <type>Acid</type>
                        > > <classes>
                        > > <class level='6'>Sorcerer</class>
                        > > <class level='6'>Wizard</class>
                        > > <class level='7'>Water</class>
                        > > </classes>
                        > > <components>
                        > > <component>V</component>
                        > > <component>S</component>
                        > > <component>M/DF</component>
                        > > </components>
                        > > <casting-time>1 action</casting-time>
                        > > <range>Medium (100 ft. + 10 ft./level)</range>
                        > > <effect>Fog spreads 30 ft., 20 ft. high</effect>
                        > > <duration>1 round/level</duration>
                        > > <saving-throw>None</saving-throw>
                        > > <spell-resistance>Yes</spell-resistance>
                        > > <long-description>
                        > > <p>This spell's vapors are highly acidic. Each
                        > > round, starting
                        > > when you cast the spell, the fog deals 2d6 points of
                        > > acid damage
                        > > to creatures and objects within it.</p>
                        > > </long-description>
                        > > </spell>
                        > > </d20xml>
                        >
                        > Keith
                        > --
                        > Keith Davies
                        > kjdavies@...
                        >
                        > Elarios: "Shade, you showed honor and mercy
                        > "Raven, you were couragous beyond expectation
                        > "Logan, you resisted the temptation of knowledge."
                        >
                        > Logan: "That's... good, right?"
                        >
                        >
                        > To unsubscribe from this group, send an email to:
                        > pcgen-xml-unsubscribe@yahoogroups.com
                        >
                        >
                        >
                        > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                      • STILES, BRAD
                        ... It s not complete. Besides which, we don t necessarily want to represent D20 data, we want to represent D20 data in a form that PCGen can use. Now, those
                        Message 11 of 22 , Jan 10, 2002
                        • 0 Attachment
                          > -----Original Message-----
                          > From: Karl-Petter Åkesson [mailto:kalle@...]
                          >
                          > Just a bit of curiosity... If there is an D20XML why dont we
                          > use it for PCGen?

                          It's not complete. Besides which, we don't necessarily want to represent
                          D20 data, we want to represent D20 data in a form that PCGen can use. Now,
                          those two things may be similar in many respects, but they are not going to
                          be identical.

                          Brad
                        • STILES, BRAD
                          ... Actually, that one I posted was one that was derived directly from the SRD spell list. One of the D20-XML members did it as an excercise. The actual
                          Message 12 of 22 , Jan 10, 2002
                          • 0 Attachment
                            > -----Original Message-----
                            > From: Keith Davies [mailto:kjdavies@...]
                            >
                            > At this point, I'm leaning toward having the various lists being
                            > resources used to define others. For example (and counter to your
                            > sample below), I'd remove the <classes> below and have <spelllist>
                            > contain the spell and level, something like:

                            Actually, that one I posted was one that was derived directly from the SRD
                            spell list. One of the D20-XML members did it as an excercise.

                            The actual standard, where such had been addressed, was much closer to what
                            you had included in your message, Keith.

                            Brad
                          • Mynex
                            I m not overly happy with this example either, it is the kind of clarity we need to have. Some of the shorter elements (Components, casting times, etc)
                            Message 13 of 22 , Jan 11, 2002
                            • 0 Attachment
                              I'm not overly happy with this example either, it is the kind of clarity
                              we need to have. Some of the 'shorter' elements (Components, casting
                              times, etc) could be put onto one line, School, sub-school and name onto
                              1 line, etc... I think it's just a matter of sitting down, writing
                              something from each type of list file in this format, and then see where
                              it can be condensed.

                              Mynex

                              - Dark Sith Silverback Android, Dark Lord of the Docs, The Sleepless
                              One, The Code Badger


                              -----Original Message-----
                              From: STILES, BRAD [mailto:BRAD.STILES@...]
                              Sent: Thursday, January 10, 2002 11:34 AM
                              To: 'PCGen XML'
                              Subject: [pcgen-xml] XML example

                              This is something one of the guys on the D20 XML list came up with for a
                              spell list. It's an extract from the D20 SRD.

                              I suspect that what we come up with will be similar, though from what
                              I've
                              read, using attributes rather than bodies in the elements is more parser
                              friendly.

                              <d20xml>
                              <spell>
                              <name>Acid Fog</name>
                              <short-description>Fog deals acid
                              damage.</short-description>
                              <school>Conjuration</school>
                              <sub-school>Creation</sub-school>
                              <type>Acid</type>
                              <classes>
                              <class level='6'>Sorcerer</class>
                              <class level='6'>Wizard</class>
                              <class level='7'>Water</class>
                              </classes>
                              <components>
                              <component>V</component>
                              <component>S</component>
                              <component>M/DF</component>
                              </components>
                              <casting-time>1 action</casting-time>
                              <range>Medium (100 ft. + 10 ft./level)</range>
                              <effect>Fog spreads 30 ft., 20 ft. high</effect>
                              <duration>1 round/level</duration>
                              <saving-throw>None</saving-throw>
                              <spell-resistance>Yes</spell-resistance>
                              <long-description>
                              <p>This spell's vapors are highly acidic. Each
                              round, starting
                              when you cast the spell, the fog deals 2d6
                              points of
                              acid damage
                              to creatures and objects within it.</p>
                              </long-description>
                              </spell>
                              </d20xml>
                            • Paul M . Lambert
                              Greetings! With all due respect, eminent Mynex, I think it s possible that you are missing part of the point to the migration to XML. XML is easily parsed by
                              Message 14 of 22 , Jan 11, 2002
                              • 0 Attachment
                                Greetings!

                                With all due respect, eminent Mynex, I think it's possible that you
                                are missing part of the point to the migration to XML.

                                XML is easily parsed by machine. As a result, writing things like
                                "pretty-printers" is incredibly simple.

                                Sure, one can use WordPad or TextPad or BBEdit or any other text
                                editor to edit XML. That's one of its strengths. But there will
                                be automated editors as well, which will be written fairly quickly
                                and simply once the format is decided upon.

                                But the _true_ format decisions won't have anything to do with how
                                many tags to put on a line or the number of spaces to indent. Those
                                things are transitory and unnecessary. There will be tools to
                                change them consistently across the entire span of files. The
                                format decisions that need to be made are the parser-level decisions.

                                Once those are made, things like converting the output to something
                                easy to edit will be _very_ simple. For example, one could easily
                                write a program to convert the XML data to an Excel spreadsheet.
                                Then after editing it, it could be converted back.

                                The whitespace (tabs, spaces, etc.) are not the data. Those are there
                                for our comfort. The purpose of computers is to make our lives easier
                                by doing tedious work for us. We _all_ appreciate your efforts far more
                                than we can ever express, and we're hoping that the move to XML will
                                allow everyone to use their own methods of editing that are most comfortable
                                for them.

                                This means, though, that it probably isn't necessary to dictate exact
                                text-level formatting of the files. Once the parser is complete for
                                _reading_ the files, it can take its internal representation and spit
                                it back out in some standard format. That format can then be tweaked to
                                be a little bit easier to edit as plaintext. But as long as the XML is
                                well-formed from the parser's point of view, it doesn't care one whit
                                about the spacing, so the next person to submit a version of a datafile
                                might have it all on a single line, and that will affect no one.

                                The end result will be to allow each of us to use our own methods to
                                access and modify the data, without having to make arbitrary yet
                                so amazingly painful decisions like how wide a tab column should be.
                                (Every tool I use assumes 4 or 8. All of them. I find six to be
                                incredibly annoying, but since you were doing so much work on the files
                                and that's what you used, I kept my mouth shut.)

                                With XML no one has to keep their mouth shut: we'll all be on even
                                footing. But the first step is to ensure that the basic _data_ format
                                is decided. As far as the parser is concerned, whitespace is meaningless.
                                It's all about the data!

                                So let's worry about how to structure the data, and not worry about
                                where the linefeeds go? That can be changed many times later.

                                --plambert


                                On Fri, 11 Jan 2002, Mynex wrote:

                                >
                                > I'm not overly happy with this example either, it is the kind of clarity
                                > we need to have. Some of the 'shorter' elements (Components, casting
                                > times, etc) could be put onto one line, School, sub-school and name onto
                                > 1 line, etc... I think it's just a matter of sitting down, writing
                                > something from each type of list file in this format, and then see where
                                > it can be condensed.
                                >
                                > Mynex
                                >
                                > - Dark Sith Silverback Android, Dark Lord of the Docs, The Sleepless
                                > One, The Code Badger
                                >
                                >
                                > -----Original Message-----
                                > From: STILES, BRAD [mailto:BRAD.STILES@...]
                                > Sent: Thursday, January 10, 2002 11:34 AM
                                > To: 'PCGen XML'
                                > Subject: [pcgen-xml] XML example
                                >
                                > This is something one of the guys on the D20 XML list came up with for a
                                > spell list. It's an extract from the D20 SRD.
                                >
                                > I suspect that what we come up with will be similar, though from what
                                > I've
                                > read, using attributes rather than bodies in the elements is more parser
                                > friendly.
                                >
                                > <d20xml>
                                > <spell>
                                > <name>Acid Fog</name>
                                > <short-description>Fog deals acid
                                > damage.</short-description>
                                > <school>Conjuration</school>
                                > <sub-school>Creation</sub-school>
                                > <type>Acid</type>
                                > <classes>
                                > <class level='6'>Sorcerer</class>
                                > <class level='6'>Wizard</class>
                                > <class level='7'>Water</class>
                                > </classes>
                                > <components>
                                > <component>V</component>
                                > <component>S</component>
                                > <component>M/DF</component>
                                > </components>
                                > <casting-time>1 action</casting-time>
                                > <range>Medium (100 ft. + 10 ft./level)</range>
                                > <effect>Fog spreads 30 ft., 20 ft. high</effect>
                                > <duration>1 round/level</duration>
                                > <saving-throw>None</saving-throw>
                                > <spell-resistance>Yes</spell-resistance>
                                > <long-description>
                                > <p>This spell's vapors are highly acidic. Each
                                > round, starting
                                > when you cast the spell, the fog deals 2d6
                                > points of
                                > acid damage
                                > to creatures and objects within it.</p>
                                > </long-description>
                                > </spell>
                                > </d20xml>
                                >
                                >
                                >
                                >
                                >
                                > To unsubscribe from this group, send an email to:
                                > pcgen-xml-unsubscribe@yahoogroups.com
                                >
                                >
                                >
                                > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                                >
                              • Mynex
                                ... No, I understand the point, I am a tad familiar with XML. ;) ... Very true, I m not arguing point there at all. ... Well, while there are tools to do so,
                                Message 15 of 22 , Jan 11, 2002
                                • 0 Attachment
                                  > -----Original Message-----
                                  > From: Paul M . Lambert [mailto:plambert@...]
                                  > Sent: Friday, January 11, 2002 4:04 PM
                                  > To: pcgen-xml@yahoogroups.com
                                  > Subject: Re: [pcgen-xml] As part of my last post...
                                  >
                                  > Greetings!
                                  >
                                  > With all due respect, eminent Mynex, I think it's possible that you
                                  > are missing part of the point to the migration to XML.

                                  No, I understand the point, I am a 'tad' familiar with XML. ;)

                                  >
                                  > XML is easily parsed by machine. As a result, writing things like
                                  > "pretty-printers" is incredibly simple.
                                  >
                                  > Sure, one can use WordPad or TextPad or BBEdit or any other text
                                  > editor to edit XML. That's one of its strengths. But there will
                                  > be automated editors as well, which will be written fairly quickly
                                  > and simply once the format is decided upon.


                                  Very true, I'm not arguing point there at all.

                                  >
                                  > But the _true_ format decisions won't have anything to do with how
                                  > many tags to put on a line or the number of spaces to indent. Those
                                  > things are transitory and unnecessary. There will be tools to
                                  > change them consistently across the entire span of files. The
                                  > format decisions that need to be made are the parser-level decisions.


                                  Well, while there are tools to do so, Joe user may not want them. He
                                  may be perfectly happy writing everything in notepad for all we know, so
                                  regardless of what point we are talking about, we need to keep in mind
                                  the lowest common denominator of things.

                                  >
                                  > Once those are made, things like converting the output to something
                                  > easy to edit will be _very_ simple. For example, one could easily
                                  > write a program to convert the XML data to an Excel spreadsheet.
                                  > Then after editing it, it could be converted back.

                                  Again, think of these things know, across the board, and avoid problems
                                  later.

                                  >
                                  > The whitespace (tabs, spaces, etc.) are not the data. Those are there
                                  > for our comfort. The purpose of computers is to make our lives easier
                                  > by doing tedious work for us. We _all_ appreciate your efforts far
                                  more
                                  > than we can ever express, and we're hoping that the move to XML will
                                  > allow everyone to use their own methods of editing that are most
                                  > comfortable
                                  > for them.

                                  That is one of the goals, yes, but not the most important one. The most
                                  important thing is for a standardization of the list files. A standard
                                  that anyone, regardless of whether they use a parser, or just open up
                                  the xml doc, can edit without giving themselves a headache (which would
                                  be a vast improvement over what we have now. ;p)


                                  >
                                  > This means, though, that it probably isn't necessary to dictate exact
                                  > text-level formatting of the files. Once the parser is complete for
                                  > _reading_ the files, it can take its internal representation and spit
                                  > it back out in some standard format. That format can then be tweaked
                                  to
                                  > be a little bit easier to edit as plaintext. But as long as the XML
                                  is
                                  > well-formed from the parser's point of view, it doesn't care one whit
                                  > about the spacing, so the next person to submit a version of a
                                  datafile
                                  > might have it all on a single line, and that will affect no one.
                                  >
                                  > The end result will be to allow each of us to use our own methods to
                                  > access and modify the data, without having to make arbitrary yet
                                  > so amazingly painful decisions like how wide a tab column should be.
                                  > (Every tool I use assumes 4 or 8. All of them. I find six to be
                                  > incredibly annoying, but since you were doing so much work on the
                                  files
                                  > and that's what you used, I kept my mouth shut.)
                                  >
                                  > With XML no one has to keep their mouth shut: we'll all be on even
                                  > footing. But the first step is to ensure that the basic _data_ format
                                  > is decided. As far as the parser is concerned, whitespace is
                                  meaningless.
                                  > It's all about the data!
                                  >
                                  > So let's worry about how to structure the data, and not worry about
                                  > where the linefeeds go? That can be changed many times later.
                                  >
                                  > --plambert
                                  >

                                  My point was about the basic data format, but I was also thinking of
                                  output (post parser) as well... Sorry if that wasn't clear, but I do
                                  tend to think on multiple trains of thought at the same time. ;D

                                  (and thanks for all the compliments! (but yer still not getting any Code
                                  Monkey (tm pending) snacks outta me ;D)


                                  Mynex

                                  - Dark Sith Silverback Android, Dark Lord of the Docs, The Sleepless
                                  One, The Code Badger

                                  >
                                  > On Fri, 11 Jan 2002, Mynex wrote:
                                  >
                                  > >
                                  > > I'm not overly happy with this example either, it is the kind of
                                  clarity
                                  > > we need to have. Some of the 'shorter' elements (Components,
                                  casting
                                  > > times, etc) could be put onto one line, School, sub-school and name
                                  onto
                                  > > 1 line, etc... I think it's just a matter of sitting down, writing
                                  > > something from each type of list file in this format, and then see
                                  where
                                  > > it can be condensed.
                                  > >
                                  > > Mynex
                                  > >
                                  > > - Dark Sith Silverback Android, Dark Lord of the Docs, The Sleepless
                                  > > One, The Code Badger
                                  > >
                                  > >
                                  > > -----Original Message-----
                                  > > From: STILES, BRAD [mailto:BRAD.STILES@...]
                                  > > Sent: Thursday, January 10, 2002 11:34 AM
                                  > > To: 'PCGen XML'
                                  > > Subject: [pcgen-xml] XML example
                                  > >
                                  > > This is something one of the guys on the D20 XML list came up with
                                  for a
                                  > > spell list. It's an extract from the D20 SRD.
                                  > >
                                  > > I suspect that what we come up with will be similar, though from
                                  what
                                  > > I've
                                  > > read, using attributes rather than bodies in the elements is more
                                  parser
                                  > > friendly.
                                  > >
                                  > > <d20xml>
                                  > > <spell>
                                  > > <name>Acid Fog</name>
                                  > > <short-description>Fog deals acid
                                  > > damage.</short-description>
                                  > > <school>Conjuration</school>
                                  > > <sub-school>Creation</sub-school>
                                  > > <type>Acid</type>
                                  > > <classes>
                                  > > <class level='6'>Sorcerer</class>
                                  > > <class level='6'>Wizard</class>
                                  > > <class level='7'>Water</class>
                                  > > </classes>
                                  > > <components>
                                  > > <component>V</component>
                                  > > <component>S</component>
                                  > > <component>M/DF</component>
                                  > > </components>
                                  > > <casting-time>1 action</casting-time>
                                  > > <range>Medium (100 ft. + 10 ft./level)</range>
                                  > > <effect>Fog spreads 30 ft., 20 ft. high</effect>
                                  > > <duration>1 round/level</duration>
                                  > > <saving-throw>None</saving-throw>
                                  > > <spell-resistance>Yes</spell-resistance>
                                  > > <long-description>
                                  > > <p>This spell's vapors are highly acidic. Each
                                  > > round, starting
                                  > > when you cast the spell, the fog deals 2d6
                                  > > points of
                                  > > acid damage
                                  > > to creatures and objects within it.</p>
                                  > > </long-description>
                                  > > </spell>
                                  > > </d20xml>
                                  > >
                                  > >
                                  > >
                                  > >
                                  > >
                                  > > To unsubscribe from this group, send an email to:
                                  > > pcgen-xml-unsubscribe@yahoogroups.com
                                  > >
                                  > >
                                  > >
                                  > > Your use of Yahoo! Groups is subject to
                                  > http://docs.yahoo.com/info/terms/
                                  > >
                                  >
                                  > ------------------------ Yahoo! Groups Sponsor
                                  >
                                  > To unsubscribe from this group, send an email to:
                                  > pcgen-xml-unsubscribe@yahoogroups.com
                                  >
                                  >
                                  >
                                  > Your use of Yahoo! Groups is subject to
                                  http://docs.yahoo.com/info/terms/
                                  >
                                • Paul M . Lambert
                                  ... Good! I m _very_ familiar with information theory, and I see XML as just another packaging. There are other, equally effective methods, but this one is
                                  Message 16 of 22 , Jan 11, 2002
                                  • 0 Attachment
                                    On Fri, 11 Jan 2002, Mynex wrote:

                                    >
                                    >
                                    > No, I understand the point, I am a 'tad' familiar with XML. ;)

                                    Good! I'm _very_ familiar with information theory, and I see XML
                                    as just another packaging. There are other, equally effective
                                    methods, but this one is where we're going, and that's fine with
                                    me. :-)

                                    [snip]

                                    >
                                    > >
                                    > > But the _true_ format decisions won't have anything to do with how
                                    > > many tags to put on a line or the number of spaces to indent. Those
                                    > > things are transitory and unnecessary. There will be tools to
                                    > > change them consistently across the entire span of files. The
                                    > > format decisions that need to be made are the parser-level decisions.
                                    >
                                    >
                                    > Well, while there are tools to do so, Joe user may not want them. He
                                    > may be perfectly happy writing everything in notepad for all we know, so
                                    > regardless of what point we are talking about, we need to keep in mind
                                    > the lowest common denominator of things.

                                    But again, the important thing is still the data. Anyone who wants
                                    to edit in a text editor may do so (and believe me, _I_ am in that
                                    category, although it'll be vi and not anything ending in .exe ;-)
                                    but we cannot expect to have the sheer volume of data we are dealing
                                    with and provide it in an easily-editable-in-a-text-editor format.
                                    I truly do not believe it's possible. That isn't to say it won't
                                    happen and that there won't be plenty of people who edit the XML
                                    files with text editors. But it is to say that we cannot cater to
                                    them any more than we can cater to me (my plan is to write an
                                    XML-parser that creates a second format, and then converts it back
                                    when I'm done editing... that lets me use my own personal format
                                    without burdening anyone else with it. :-)

                                    >
                                    > >
                                    > > Once those are made, things like converting the output to something
                                    > > easy to edit will be _very_ simple. For example, one could easily
                                    > > write a program to convert the XML data to an Excel spreadsheet.
                                    > > Then after editing it, it could be converted back.
                                    >
                                    > Again, think of these things know, across the board, and avoid problems
                                    > later.

                                    But I contend that these problems cannot be solved now. There is
                                    no way to know what will be "pretty" in a text editor. Where should
                                    the linefeeds go? Who cares. Let's get the _data_ right first
                                    because if we let an 80-column, 6-space-tab mindset get in the way
                                    of actually storing the data, then we lose a great deal in the long
                                    run. A pre-printed character sheet and a pencil is _really_ easy
                                    for the average Joe to understand and deal with. We're going to
                                    have to aim well above that.

                                    I also contend that the minute these XML files are available, we'll
                                    have a minor flood of editors, viewers, verifiers, summarizers, and
                                    general data manipulation utilities. I, for one, will write many
                                    of them. (The .LST format is too unparseable for me or I'd have
                                    some of my projects completed already... :-/)

                                    >
                                    > >
                                    > > The whitespace (tabs, spaces, etc.) are not the data. Those are there
                                    > > for our comfort. The purpose of computers is to make our lives easier
                                    > > by doing tedious work for us. We _all_ appreciate your efforts far
                                    > more
                                    > > than we can ever express, and we're hoping that the move to XML will
                                    > > allow everyone to use their own methods of editing that are most
                                    > > comfortable
                                    > > for them.
                                    >
                                    > That is one of the goals, yes, but not the most important one. The most
                                    > important thing is for a standardization of the list files. A standard
                                    > that anyone, regardless of whether they use a parser, or just open up
                                    > the xml doc, can edit without giving themselves a headache (which would
                                    > be a vast improvement over what we have now. ;p)
                                    >

                                    But everyone _does_ use a parser: PCGen. The XML docs will be ugly.
                                    XML is ugly. That's the way it is. We _can't_ have things line
                                    up in nice, neat columns, and we _can't_ have everything fit
                                    beautifully on 80-char lines. Why? Because we're dealing with a
                                    large quantity of real-world data, and a large developer base. How
                                    can you enforce a "style sheet" for the spacing and layout of the
                                    XML? The only true enforcement is the parser in PCGen. If _it_
                                    can read it, it's valid. Hence the need for a pretty-printer.
                                    Build whatever functionality into the pretty-printer that you want,
                                    but whatever it produces will be the "standard" for the forseeable
                                    future, and I can assure you it won't be easy to line anything up
                                    in columns. :-)

                                    >
                                    [big snip... boy, i'm windy!]
                                    > > So let's worry about how to structure the data, and not worry about
                                    > > where the linefeeds go? That can be changed many times later.
                                    > >
                                    > > --plambert
                                    > >
                                    >
                                    > My point was about the basic data format, but I was also thinking of
                                    > output (post parser) as well... Sorry if that wasn't clear, but I do
                                    > tend to think on multiple trains of thought at the same time. ;D

                                    Good. So we're really on the same track, and even on the same train,
                                    we're just looking out different windows. :-)

                                    I look forward to XML so that I can publish the contents of the list
                                    files in vaguely readable HTML on the web, and move closer to my goal
                                    of automagickal generation of data! <laugh type='evil genius'
                                    emotion='describing plot to take over the world' />

                                    >
                                    > (and thanks for all the compliments! (but yer still not getting any Code
                                    > Monkey (tm pending) snacks outta me ;D)
                                    >

                                    I don't deserve any yet. When/if I do, _then_ I'll be expectin' them!

                                    --plambert
                                  • Ryan Koppenhaver
                                    ... For the record, they re not mutually exclusive: [rlk@RLK:Tools]$ ps -Ws PID TTY STIME COMMAND 15751165 ? Dec 31 C: WINDOWS SYSTEM KERNEL32.DLL
                                    Message 17 of 22 , Jan 11, 2002
                                    • 0 Attachment
                                      A few sets of $.02:

                                      --- "Paul M . Lambert" <plambert@...> wrote:
                                      > But again, the important thing is still the data. Anyone who wants
                                      > to edit in a text editor may do so (and believe me, _I_ am in that
                                      > category, although it'll be vi and not anything ending in .exe ;-)

                                      For the record, they're not mutually exclusive:

                                      [rlk@RLK:Tools]$ ps -Ws
                                      PID TTY STIME COMMAND
                                      15751165 ? Dec 31 C:\WINDOWS\SYSTEM\KERNEL32.DLL
                                      ...snip some...
                                      189161 ? Dec 31 C:\VIM\VIM57\GVIM.EXE
                                      184577 ? Dec 31 C:\VIM\VIM57\GVIM.EXE

                                      > [snip a bunch]

                                      > I also contend that the minute these XML files are available, we'll
                                      > have a minor flood of editors, viewers, verifiers, summarizers, and
                                      > general data manipulation utilities. I, for one, will write many
                                      > of them. (The .LST format is too unparseable for me or I'd have
                                      > some of my projects completed already... :-/)

                                      Agreed, I'm a big proponent of "Plain Text is Good", but I'll write a
                                      PCGen data editor myself before I type out all my campaign info, no
                                      matter how user-friendly the xml schema and formatting guidelines.

                                      > I look forward to XML so that I can publish the contents of the list
                                      > files in vaguely readable HTML on the web, and move closer to my goal
                                      > of automagickal generation of data! <laugh type='evil genius'
                                      > emotion='describing plot to take over the world' />

                                      Yep. I *hate* having to keep two versions of my data-- .lst and HTML--
                                      in sync manually.

                                      -Ryan

                                      __________________________________________________
                                      Do You Yahoo!?
                                      Send FREE video emails in Yahoo! Mail!
                                      http://promo.yahoo.com/videomail/
                                    • Keith Davies
                                      ... Probably a good idea. One of my goals is for an editor-friendly schema, but I really expect GUI to appear for these... and a good schema will make these
                                      Message 18 of 22 , Jan 12, 2002
                                      • 0 Attachment
                                        Ryan Koppenhaver wrote on Fri Jan 11 18:53:17 2002:
                                        >
                                        > --- "Paul M . Lambert" <plambert@...> wrote:
                                        >
                                        > > I also contend that the minute these XML files are available, we'll
                                        > > have a minor flood of editors, viewers, verifiers, summarizers, and
                                        > > general data manipulation utilities. I, for one, will write many
                                        > > of them. (The .LST format is too unparseable for me or I'd have
                                        > > some of my projects completed already... :-/)
                                        >
                                        > Agreed, I'm a big proponent of "Plain Text is Good", but I'll write a
                                        > PCGen data editor myself before I type out all my campaign info, no
                                        > matter how user-friendly the xml schema and formatting guidelines.

                                        Probably a good idea. One of my goals is for an 'editor-friendly'
                                        schema, but I really expect GUI to appear for these... and a good
                                        schema will make these easier too.

                                        > > I look forward to XML so that I can publish the contents of the list
                                        > > files in vaguely readable HTML on the web, and move closer to my goal
                                        > > of automagickal generation of data! <laugh type='evil genius'
                                        > > emotion='describing plot to take over the world' />
                                        >
                                        > Yep. I *hate* having to keep two versions of my data-- .lst and HTML--
                                        > in sync manually.

                                        Well, if we do this right it should be possible to write a transformation
                                        that'll convert the data base to LST format. It can be hard to go from
                                        content-poor to content-rich (LST->XML), but the other direction tends to
                                        be *much* easier.


                                        Keith
                                        --
                                        Keith Davies
                                        kjdavies@...

                                        Elarios: "Shade, you showed honor and mercy
                                        "Raven, you were couragous beyond expectation
                                        "Logan, you resisted the temptation of knowledge."

                                        Logan: "That's... good, right?"
                                      • Eric Beaudoin
                                        ... [snip.] ... I m in the process of writing a parser for the .lst files. Parsing these is not that bad. The parser will take me some time to write only
                                        Message 19 of 22 , Jan 12, 2002
                                        • 0 Attachment
                                          At 05:40 2002.01.12, Keith Davies wrote:
                                          >Ryan Koppenhaver wrote on Fri Jan 11 18:53:17 2002:

                                          [snip.]

                                          >> > I look forward to XML so that I can publish the contents of the list
                                          >> > files in vaguely readable HTML on the web, and move closer to my goal
                                          >> > of automagickal generation of data! <laugh type='evil genius'
                                          >> > emotion='describing plot to take over the world' />
                                          >>
                                          >> Yep. I *hate* having to keep two versions of my data-- .lst and HTML--
                                          >> in sync manually.
                                          >
                                          >Well, if we do this right it should be possible to write a transformation
                                          >that'll convert the data base to LST format. It can be hard to go from
                                          >content-poor to content-rich (LST->XML), but the other direction tends to
                                          >be *much* easier.

                                          I'm in the process of writing a parser for the .lst files. Parsing these is not that bad. The parser will take me some time to write only because of the diversity of grammatical techniques used. Once the parser is done, it will be possible to use it to generate XML from the LST for every new release of PCGEN until the full transition to XML is completed (I'm guessing here, I hope you plan to let go of the LST format at some point in the future). Hopefully, there will be a freeze on the changes to the .lst grammar and syntax during the transition.

                                          I should be able to send a YACC like grammar for the .PCC file and maybe for one of the .LST type this weekend. It might be useful to really understand what type of beast we are dealing with.

                                          Multiple parsers for XML already exist so the conversion from XML to LST should be also be kind of easy except for the places where we actually use "richness" of XML not available in the LST format. Then the transformation from XML to LST will be a bit more complicated. For example, with XML we should be able to use the |, : and $ characters in every fields and I can see that breaking quite a few .lst files.

                                          So I guess I'm of the opposite opinion than Keith on this one. In my experience, it is easier to go from content poor to content rich than the other way around. It should still be possible but we should all be aware that while the LST format is still in use, the XML format will be limited by LST restrictions.

                                          Best

                                          -----------------------------------------------------------
                                          Éric Beaudoin <mailto:beaudoer@...>
                                        • Keith Davies
                                          ... I think I understand what you re saying. Yeah, it can be harder to make the more content-rich data for into the content-poor format because there s
                                          Message 20 of 22 , Jan 12, 2002
                                          • 0 Attachment
                                            Eric Beaudoin wrote on Sat Jan 12 08:08:50 2002:
                                            >
                                            > Multiple parsers for XML already exist so the conversion from XML to LST should be also be kind of easy except for the places where we actually use "richness" of XML not available in the LST format. Then the transformation from XML to LST will be a bit more complicated. For example, with XML we should be able to use the |, : and $ characters in every fields and I can see that breaking quite a few .lst files.
                                            >
                                            > So I guess I'm of the opposite opinion than Keith on this one. In my experience, it is easier to go from content poor to content rich than the other way around. It should still be possible but we should all be aware that while the LST format is still in use, the XML format will be limited by LST restrictions.

                                            I think I understand what you're saying.

                                            Yeah, it can be harder to make the more 'content-rich' data for into the
                                            'content-poor' format because there's more of it. However, with the other
                                            direction, you have to somehow come up with information that may not be
                                            present in the weaker data format.


                                            Keith
                                            --
                                            Keith Davies
                                            kjdavies@...

                                            Elarios: "Shade, you showed honor and mercy
                                            "Raven, you were couragous beyond expectation
                                            "Logan, you resisted the temptation of knowledge."

                                            Logan: "That's... good, right?"
                                          • pjak
                                            ... To quote a co-worker of mine: No project is complete without a World Domination Plan! Seems we have one now. Good. ;-) /Jonas
                                            Message 21 of 22 , Jan 14, 2002
                                            • 0 Attachment
                                              --- In pcgen-xml@y..., "Paul M . Lambert" <plambert@p...> wrote:
                                              > <laugh type='evil genius'
                                              > emotion='describing plot to take over the world' />

                                              To quote a co-worker of mine:

                                              "No project is complete without a World Domination Plan!"

                                              Seems we have one now. Good. ;-)

                                              /Jonas
                                            • Paul M . Lambert
                                              ... I would love to see this grammar. Let me know when you have something? My attempts to write one have so far failed as a result of inattention. ...
                                              Message 22 of 22 , Jan 14, 2002
                                              • 0 Attachment
                                                On Sat, 12 Jan 2002, Eric Beaudoin wrote:

                                                >
                                                > I'm in the process of writing a parser for the .lst files. Parsing
                                                > these is not that bad. The parser will take me some time to write
                                                > only because of the diversity of grammatical techniques used. Once
                                                > the parser is done, it will be possible to use it to generate XML
                                                > from the LST for every new release of PCGEN until the full transition
                                                > to XML is completed (I'm guessing here, I hope you plan to let go
                                                > of the LST format at some point in the future). Hopefully, there
                                                > will be a freeze on the changes to the .lst grammar and syntax
                                                > during the transition.
                                                >
                                                > I should be able to send a YACC like grammar for the .PCC file
                                                > and maybe for one of the .LST type this weekend. It might be useful
                                                > to really understand what type of beast we are dealing with.
                                                >
                                                > Multiple parsers for XML already exist so the conversion from XML
                                                > to LST should be also be kind of easy except for the places where
                                                > we actually use "richness" of XML not available in the LST format.
                                                > Then the transformation from XML to LST will be a bit more complicated.
                                                > For example, with XML we should be able to use the |, : and $
                                                > characters in every fields and I can see that breaking quite a few
                                                > .lst files.
                                                >
                                                > So I guess I'm of the opposite opinion than Keith on this one.
                                                > In my experience, it is easier to go from content poor to content
                                                > rich than the other way around. It should still be possible but we
                                                > should all be aware that while the LST format is still in use, the
                                                > XML format will be limited by LST restrictions.
                                                >

                                                I would love to see this grammar. Let me know when you have something?
                                                My attempts to write one have so far failed as a result of inattention.
                                                :-(

                                                --plambert
                                              Your message has been successfully submitted and would be delivered to recipients shortly.