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

Re: [pcgen-xml] XML example

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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.