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

Re: [pcgen-xml] XML example

Expand Messages
  • Karl-Petter Åkesson
    Hi, Just a bit of curiosity... If there is an D20XML why dont we use it for PCGen? Kalle
    Message 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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.