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

RE: [pcgen-xml] Re: XML example

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

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

      Mynex

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


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


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

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

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

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

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

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

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

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

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

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

        If my elements got too long for one line.

        -Ryan


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

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

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

          or we could do:

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

          or some combination thereof:

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

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

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

          -Ryan



          __________________________________________________
          Do You Yahoo!?
          Send FREE video emails in Yahoo! Mail!
          http://promo.yahoo.com/videomail/
        • Keith Davies
          ... And less typing, too. At this point, I m leaning toward having the various lists being resources used to define others. For example (and counter to your
          Message 4 of 22 , Jan 10, 2002
            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 5 of 22 , Jan 10, 2002
              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 6 of 22 , Jan 10, 2002
                > -----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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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 15 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 16 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 17 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.