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

RE: [pcgen-xml] XML example

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