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

Re: Revised Spell example

Expand Messages
  • jdk_kjdavies
    ... will ... create ... you ve ... I disagree. Actually, I don t think page should be there at all -- when the book is reprinted, it ll be out of date. I
    Message 1 of 26 , Jan 11, 2002
      --- In pcgen-xml@y..., Ryan Koppenhaver <rlkoppenhaver@y...> wrote:
      >
      > --- jdk_kjdavies <kjdavies@t...> wrote:
      > > <school name="Conjuration" id="school.conjuration">
      > > <ref refid="spell.acid-fog"/>
      > > </school>
      >
      > I like having schools defined in the data, but again, new sources
      will
      > add spells to the conjuration school, so we don't want to try to
      create
      > a comprehensive list of conjuration spells.
      >
      > > <spell name="Acid Fog" refname="acid fog" refid="spell.acid-fog"
      > > source="wotc.phb" page="172">
      >
      > I have no problem with the source as metadata to the spell, but
      you've
      > made "page" a peer of "source", when it should be a child.

      I disagree.

      Actually, I don't think page should be there at all -- when the book
      is reprinted, it'll be out of date. I think if someone's gone so far
      as to find the book, he can look up the page number himself.

      > > <school schoolid="school.conjuration" sub="creation"/>
      >
      > "subschool.creation" for consistency, maybe?

      probably, yes.

      > > <subtype typeid="spelltype.acid"/>
      >
      > Again, "descriptor" is the official term. See PHB p.152, bottom of
      the
      > second column.

      We're not discussing specific element tags yet, just the general
      structure. You've got a point, though.

      > > <components V="Y" M="Y" S="Y" M="Y" DF="Y"/>
      > > <!-- can't misspell this way... -->
      >
      > No, but you can repeat your "M" attribute twice. Anyway, the
      validator
      > should be able to catch either error.

      heh. That was supposed to be 'MF' in the second one. Good point,
      though. I'd still rather use the abbreviations, because that's what
      gets used in the spell descriptions.

      > > <casting time="1 action" range="medium"/>
      >
      > These two have no relation to each other, and probably shouldn't be
      in
      > the same element.

      Yeah, probably.

      > > <defense save="none" sr="Y"/>
      >
      > My view is, if it isn't condensed into one line in the PHB spell
      > listing format, it shouldn't be condensed into one element.

      Eh... possibly. This element here could be describing the options
      for avoiding, resisting, or otherwise defending against the spell,
      and could arguably be contained in the same element.

      > > <brief>Deals 2d6 acid damage/round to creatures in
      effect.</brief>
      >
      > "brief" makes a lot more sense as a child to "<description>". If
      > you're going to remove the <description> element, the "brief" should
      > become "brief-description".

      I don't think I agree. <brief> is a one-line description of the item
      being described, and is quite common. I don't think <description> is
      strictly needed; I'd rather save it for the long-text description.

      > > </spell>
      >
      > > <spell-list id="spell-list.sorwiz" name="Sorcerer/Wizard"
      > > type="arcane">
      > > <slref refid="spell.acid-fog" level="6"/>
      > > </spell-list>
      > >
      > > <spell-list id="spell-list.domain.water" name="Water"
      > > type="divine">
      > > <slref refid="spell.acid-fog level="7"/>
      > > </spell-list>
      >
      > This is a spell-list format that I can probably get behind.
      However,
      > I'd like to see it implemented in such a way that I can have
      >
      > <spell-list id="spell-list.sorwiz">
      > <foo>
      > </spell-list>
      >
      > in one file, and
      >
      > <spell-list id="spell-list.sorwiz">
      > <bar>
      > </spell-list>
      >
      > and end up with both foo and bar in my Wizard's class spell list.

      I think that's reasonable, though I think we might keep <spell-list>
      as a master and have the others refer to it

      <spell-list id="spell-list.sorwiz" name="Sorcerer/Wizard"
      type="arcane"/>

      <list-spells refid="spell-list.sorwiz">
      <spellref refid="spell.acid-fog" level="6"/>
      <spellref refid="spell.fireball" level="3"/>
      </list-spells>

      <list-spells refid="spell-list.sorwiz">
      <spellref refid="spell.magic-missile" level="1"/>
      <spellref refid="spell.sleep" level="1"/>
      </list-spells>

      Crappy name for the second element, but worry about it later.

      > In another, so that new sources can add spells to existing lists,
      and
      > add new lists with existing spells equally well.

      Sounds entirely reasonable to me. It gets around my discomfort with
      everyone needing access to the spell lists whenever they add new
      spells to the system.

      > Bear in mind that it's easy enough to re-arrange the data for
      > in-program browsing purposes.

      Yep. I believe I've mentioned the possibility of having a 'working
      schema' and 'production schema'. I like your mechanism for
      associating spells and lists.

      > > Also,
      > > look at the number of changes needed. To create a new spell your
      > > way, 1 (create the spell). To create a new spell my way, 2
      (create
      > > the spell, add to spell-list). To add a new spell list my way: 2
      > > (create list and add all spells). To add a new spell list your
      way:
      > > ? (update each and every spell in the list to show it is part of
      the
      > > list). Now, while I'll grant that we can expect to be adding
      more
      > > spells than spell lists, I think that as time passes and more
      custom
      > > campaigns are brought in (and custom classes), we'll see a lot of
      new
      > > spell lists... which will be harder to create, I think.
      >
      > Yes!

      Use mechanism above, then whole thing goes away. Thank you.

      > > Now, something I realized last night is that we can have two
      schema.
      >
      > > The first would be used internally for list development and could
      > > include stuff to make life easier -- such as the suggestion from
      > > another post, that we allow more than one way of doing
      something. In
      > > this case, we might allow specification of the spell's lists to
      be in
      > > the <spell> rather than the <spell-list>; the <spell-list> could
      be
      > > updated when the spell is imported.
      >
      > I'm not sure I see much benefit in that, especially if our long-term
      > goal is to create(or add to pcgen) an gui-based editor, so people
      don't
      > have to muck around with the xml directly.

      True enough.

      Incidentally, by using attributes and the like the way I've been
      describing, it'd be easy (using a DOM parser rather than a SAX
      parser) to populate list boxes and whatnot because you can simply
      identify the elements having particular attribute values.

      > > I expect to be doing some kind of transformation of the XML
      before
      > > shipping it for use with PCGen, if only to remove redundant
      > > whitespace and collapse the file size (and read time...).
      >
      > Keep in mind that plenty of PCGen's users are going to want to read
      > through the files to get ideas for writing their own. And zipping
      the
      > files makes the impact of excess whitespace pretty trivial.

      True enough.

      > > We do not
      > > have to limit ourselves *too* strictly here, though I still favor
      the
      > > 'single method' approach.
      >
      > As someone mentioned before, flexibility and ambiguity go and in
      hand.
      > I agree, though, that one has to find a middle ground.

      That was me <g>

      Keith
    • jdk_kjdavies
      ... fog ... standard ... or ... XML ... that ... to ... I think it would. As I mentioned, I believe Bryan (well, the LST writers, actually, but it s easier
      Message 2 of 26 , Jan 11, 2002
        --- In pcgen-xml@y..., Ryan Koppenhaver <rlkoppenhaver@y...> wrote:
        >
        > --- Karl-Petter Åkesson <kalle@s...> wrote:
        > > Ryan Koppenhaver wrote:
        > > > --- kyuzo184 <sh@c...> wrote:
        >
        > > > > <spells>
        > > > > <spell name="Acid Fog" refname="acid fog" refid="spell.acid-
        fog">
        >
        > > > How
        > > > about a name ("Acid Fog"), and a unique id of the form
        > > > "spell.[source].[name]", where source and name are in some
        standard
        > > > format, i.e., all lower case with spaces changed to underscores
        or
        > > > something?
        >
        > > The refid give me goose skin. Looks like pointers in C... yikes...
        >
        > > Isnt there anyway in XML to reference another element? Seems a bit
        > > unnecessary to first create the spell element and name it and then
        > > also have to say the same thing in the ref...
        >
        > All attributes of type "ID" are required to be unique within an XML
        > document. So, when referring to something based on an ID attribute,
        > it's as simple as referring to the ID. You don't even need to know
        > what the attribute is called.
        >
        > However, I'm not sure that this is quite as useful across multiple
        XML
        > documents. In theory, there's no reason why we can't just declare
        that
        > all names must be unique, and refer by that, but it might be harder
        to
        > implement.

        I think it would. As I mentioned, I believe Bryan (well, the LST
        writers, actually, but it's easier to refer to the whole thing as
        'Bryan') is having some problems with that right now.

        Besides, it's not impossible that two things of different *types*
        might have the same text value, and that would be annoying to work
        with.

        Keith
      • Scott Ellsworth
        ... I have found when creating spells that I usually want to have the spell done first, then added to the lists as needed. I may for example, want to balance
        Message 3 of 26 , Jan 11, 2002
          >--- In pcgen-xml@y..., Ryan Koppenhaver <rlkoppenhaver@y...> wrote:
          > > --- kyuzo184 <sh@c...> wrote:
          > > > <class level="6">Sorcerer</class>
          >> > <class level="6">Wizard</class>
          >> > <class level="7">Water</class>
          >> > </classes>
          >>
          >> This won't do. The problem is that new material can add spells to
          >the list of an existing class, or it can add classes which have access
          >to existing spells. Either we include information on which classes get
          >> what in both the spell and class data (a bad thing), or we seperate
          >it out into it's own dataset.
          >
          >I considered a '<list-spell>' link that joins spells to spell lists,
          >but figured that Joe wouldn't like having to do that. Personally,
          >I've got no problem with it.

          I have found when creating spells that I usually want to have the
          spell done first, then added to the lists as needed. I may for
          example, want to balance it differently in arcane and divine. Or,
          for that matter, want to add it to a domain. (I have played with
          requiring all spellcasters to have a domain, and to always get
          primary benefits from it.)

          I suspect that Joe will not find it that hard to add the spell to the
          lists he wants it in, once he has done the scut work of creating the
          darn thing to begin with.

          > > > <components verbal="yes" sematic="yes" material="yes" focus="no"
          > > > divinefocus="yes"/>
          > >
          > > While there's no really pressing reason to do it one way or the
          >other,
          > > I still lean towards:
          > >
          > > <components>
          > > <component>Verbal</component>
          > > ...
          >> </components>
          >
          >I prefer not to, partly because of the verboseness, and DTDs don't
          >support specific values for element contents.

          Schema do, and I find that lists of elements are a bit easier to read
          for me than lists of attributes. The verboseness does not seem that
          bad, at least if I can hide the entire component list by turning an
          arrow on the components collection. If we do it the attribute way,
          it is a bit harder to pull out all the spells without verbal
          components.

          Scott
          --
        • Scott Ellsworth
          ... Name uniqueness is not that hard, if each campaign enforces it: core.spell.acid_fog rather than just plain acid_fog. If you are making a deadlands spell
          Message 4 of 26 , Jan 11, 2002
            >Ryan Koppenhaver wrote:
            > > Karl-Petter ‰kesson <kalle@...> wrote:
            >
            > > Isnt there anyway in XML to reference another element? Seems a bit
            > > unnecessary to first create the spell element and name it and then
            > > also have to say the same thing in the ref...
            >
            >All attributes of type "ID" are required to be unique within an XML
            >document. So, when referring to something based on an ID attribute,
            >it's as simple as referring to the ID. You don't even need to know
            >what the attribute is called.
            >
            >However, I'm not sure that this is quite as useful across multiple XML
            >documents. In theory, there's no reason why we can't just declare that
            >all names must be unique, and refer by that, but it might be harder to
            >implement.

            Name uniqueness is not that hard, if each campaign enforces it:
            core.spell.acid_fog rather than just plain acid_fog.

            If you are making a deadlands spell list, then you only get to add
            ids in the deadlands space. (Not namespace, just naming convention
            space.)

            This is how ANT does it - each target has its own set of qualifiers,
            such as build.compiler. Not all properties have been converted yet,
            but they are slowly being done.

            In the latest java and XSLT book, I saw a program that extracts all
            of the ids, then sorts, so that there is a canonical list of ids in
            use:

            <core>
            <spell>
            <acid_fog/>
            <magic_missile/>
            </spell>
            </core>

            from
            core.spell.acid_fog
            core.spell.magic_missle
            --
          • jdk_kjdavies
            ... Interesting idea about the domains. ... the ... the ... I don t want the lists identified inside the spells/other items, and you just gave me a good reason
            Message 5 of 26 , Jan 11, 2002
              --- In pcgen-xml@y..., Scott Ellsworth <scott@a...> wrote:
              > I have found when creating spells that I usually want to have the
              > spell done first, then added to the lists as needed. I may for
              > example, want to balance it differently in arcane and divine. Or,
              > for that matter, want to add it to a domain. (I have played with
              > requiring all spellcasters to have a domain, and to always get
              > primary benefits from it.)

              Interesting idea about the domains.

              > I suspect that Joe will not find it that hard to add the spell to
              the
              > lists he wants it in, once he has done the scut work of creating
              the
              > darn thing to begin with.

              I don't want the lists identified inside the spells/other items, and
              you just gave me a good reason for not doing it. Spell definitions
              are resources, and lists (and whatnot) use them. As such, while the
              lists collect the spells, they do not own them... or vice-versa.

              I like the mechanism you described earlier and expect to incorporate
              it.

              > > > > <components verbal="yes" sematic="yes" material="yes"
              focus="no"
              > > > > divinefocus="yes"/>
              > > >
              > > > While there's no really pressing reason to do it one way or the
              > >other,
              > > > I still lean towards:
              > > >
              > > > <components>
              > > > <component>Verbal</component>
              > > > ...
              > >> </components>
              > >
              > >I prefer not to, partly because of the verboseness, and DTDs don't
              > >support specific values for element contents.
              >
              > Schema do, and I find that lists of elements are a bit easier to
              read
              > for me than lists of attributes. The verboseness does not seem
              that
              > bad, at least if I can hide the entire component list by turning an
              > arrow on the components collection. If we do it the attribute way,
              > it is a bit harder to pull out all the spells without verbal
              > components.

              I haven't done much with Schema (yet); the tools I have still tend to
              use DTD. However, given what Schema can do I think we may well want
              to move in that direction.

              I still prefer attributes to elements, if the data present are
              reasonably short and only a single (foreseeable) value for each piece
              of information. Attributes tend to be easier for me to search in
              scripts, and do Good Things for me. However, as I said, this hasn't
              been decided yet.

              And, FWIW, I use vi as an editor; I find other tools useful for
              examining the data, but for actual editing I use a simple text editor.

              Keith
            • Mynex
              Here I have to disagree. The page # s should be kept. If in a reprinting the page # changes, we go in and change it. Again, it s a case of KISS. Also, the
              Message 6 of 26 , Jan 11, 2002
                Here I have to disagree. The page #'s should be kept. If in a
                reprinting the page # changes, we go in and change it. Again, it's a
                case of KISS. Also, the idea is that the description of things should
                be brief, in the case of really long one line description (feats, some
                spells, etc) it's simpler to put in 'See Text' and then they can look
                and see what page # the item is on. There's also been numerous calls
                for page #'s to be printed out on csheets so that folk can have that
                'handy, quick reference'.

                Leave it in, or people will howl about it's lack. Not too mention all
                the time I and other have/are putting in to put all the damn #'s there
                anyway. ;p

                Mynex

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


                -----Original Message-----
                From: jdk_kjdavies [mailto:kjdavies@...]
                Sent: Friday, January 11, 2002 2:33 PM
                To: pcgen-xml@yahoogroups.com
                Subject: [pcgen-xml] Re: Revised Spell example

                --- In pcgen-xml@y..., Ryan Koppenhaver <rlkoppenhaver@y...> wrote:
                >
                > --- jdk_kjdavies <kjdavies@t...> wrote:
                > > <school name="Conjuration" id="school.conjuration">
                > > <ref refid="spell.acid-fog"/>
                > > </school>
                >
                > I like having schools defined in the data, but again, new sources
                will
                > add spells to the conjuration school, so we don't want to try to
                create
                > a comprehensive list of conjuration spells.
                >
                > > <spell name="Acid Fog" refname="acid fog" refid="spell.acid-fog"
                > > source="wotc.phb" page="172">
                >
                > I have no problem with the source as metadata to the spell, but
                you've
                > made "page" a peer of "source", when it should be a child.

                I disagree.

                Actually, I don't think page should be there at all -- when the book
                is reprinted, it'll be out of date. I think if someone's gone so far
                as to find the book, he can look up the page number himself.
              • jdk_kjdavies
                ... a ... should ... some ... look ... calls ... Oh? Perhaps leave it in. However, if the page number changes in a new printing, either we leave it as it is
                Message 7 of 26 , Jan 11, 2002
                  --- In pcgen-xml@y..., "Mynex" <mynex3@h...> wrote:
                  >
                  > Here I have to disagree. The page #'s should be kept. If in a
                  > reprinting the page # changes, we go in and change it. Again, it's
                  a
                  > case of KISS. Also, the idea is that the description of things
                  should
                  > be brief, in the case of really long one line description (feats,
                  some
                  > spells, etc) it's simpler to put in 'See Text' and then they can
                  look
                  > and see what page # the item is on. There's also been numerous
                  calls
                  > for page #'s to be printed out on csheets so that folk can have that
                  > 'handy, quick reference'.

                  Oh? Perhaps leave it in. However, if the page number changes in a
                  new printing, either we leave it as it is and it will be incorrect in
                  the new printing, or we change it and it will be incorrect in the old
                  printing. Or we keep both pieces of information so the user can
                  either figure out which printing he has and can identify the page, or
                  check both (or more...) pages.

                  I don't think it's worth cluttering the model; identification of the
                  book is probably sufficient.

                  > Leave it in, or people will howl about it's lack. Not too mention
                  all
                  > the time I and other have/are putting in to put all the damn #'s
                  there
                  > anyway. ;p

                  Yeah, those are reasonable points. I don't know that they apply, but
                  I'd consider keeping them.

                  Heh, also, if we do keep that piece of information, and a new
                  printing invalidates it, who's going to walk through the information
                  and fix them?

                  This feels very much like data that can and will get out of step.
                  I'd rather not have it than have it wrong.

                  Keith
                • john.sussenberger@libertymutual.com
                  I agree with Mynex, keep the page numbers, especially if the descriptions will be short :) Some of us actually use them!!! -John- ... From: Mynex
                  Message 8 of 26 , Jan 11, 2002
                    I agree with Mynex, keep the page numbers, especially if the descriptions
                    will be short :) Some of us actually use them!!!

                    -John-

                    -----Original Message-----
                    From: Mynex [mailto:mynex3@...]
                    Sent: Friday, January 11, 2002 4:31 PM
                    To: pcgen-xml@yahoogroups.com
                    Subject: RE: [pcgen-xml] Re: Revised Spell example



                    Here I have to disagree. The page #'s should be kept. If in a reprinting
                    the page # changes, we go in and change it. Again, it's a case of KISS.
                    Also, the idea is that the description of things should be brief, in the
                    case of really long one line description (feats, some spells, etc) it's
                    simpler to put in 'See Text' and then they can look and see what page # the
                    item is on. There's also been numerous calls for page #'s to be printed out
                    on csheets so that folk can have that 'handy, quick reference'.

                    Leave it in, or people will howl about it's lack. Not too mention all the
                    time I and other have/are putting in to put all the damn #'s there anyway.
                    ;p

                    Mynex

                    - Dark Sith Silverback Android, Dark Lord of the Docs, The Sleepless One,
                    The Code Badger
                  • Mynex
                    Simple, Player s Handbook 1st print Player s Handbook 2nd print And
                    Message 9 of 26 , Jan 11, 2002
                      Simple,

                      <source page="172" publisher="WotC">Player's Handbook 1st
                      print"</source>
                      <source page="181" publisher="WotC">Player's Handbook 2nd
                      print"</source>

                      And as for who? Who else, the List Primate family. ;p Just because we
                      switch to XML doesn't mean our jobs are done and we all get to go back
                      to our tree's happy in the knowledge we've made the world a better
                      place. ;p

                      Besides, It's part of the legal-smegal junk for showing source
                      information about who's what/where/when/how/why in the god are they
                      wearing those rubber boots on their heads? :D

                      Mynex

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


                      > -----Original Message-----
                      > From: jdk_kjdavies [mailto:kjdavies@...]
                      > Sent: Friday, January 11, 2002 4:50 PM
                      > To: pcgen-xml@yahoogroups.com
                      > Subject: [pcgen-xml] Re: Revised Spell example
                      >
                      > --- In pcgen-xml@y..., "Mynex" <mynex3@h...> wrote:
                      > >
                      > > Here I have to disagree. The page #'s should be kept. If in a
                      > > reprinting the page # changes, we go in and change it. Again, it's
                      > a
                      > > case of KISS. Also, the idea is that the description of things
                      > should
                      > > be brief, in the case of really long one line description (feats,
                      > some
                      > > spells, etc) it's simpler to put in 'See Text' and then they can
                      > look
                      > > and see what page # the item is on. There's also been numerous
                      > calls
                      > > for page #'s to be printed out on csheets so that folk can have that
                      > > 'handy, quick reference'.
                      >
                      > Oh? Perhaps leave it in. However, if the page number changes in a
                      > new printing, either we leave it as it is and it will be incorrect in
                      > the new printing, or we change it and it will be incorrect in the old
                      > printing. Or we keep both pieces of information so the user can
                      > either figure out which printing he has and can identify the page, or
                      > check both (or more...) pages.
                      >
                      > I don't think it's worth cluttering the model; identification of the
                      > book is probably sufficient.
                      >
                      > > Leave it in, or people will howl about it's lack. Not too mention
                      > all
                      > > the time I and other have/are putting in to put all the damn #'s
                      > there
                      > > anyway. ;p
                      >
                      > Yeah, those are reasonable points. I don't know that they apply, but
                      > I'd consider keeping them.
                      >
                      > Heh, also, if we do keep that piece of information, and a new
                      > printing invalidates it, who's going to walk through the information
                      > and fix them?
                      >
                      > This feels very much like data that can and will get out of step.
                      > I'd rather not have it than have it wrong.
                      >
                      > Keith
                      >
                      >
                      > ------------------------ 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/
                    • Ryan Koppenhaver
                      ... Ok, so (for those of you who speak Perl): $id = $name $id =~ tr/A-Z /a-z_/; #lower case, and spaces become underscores $id =~ s/[^a-z_]//g; #strip
                      Message 10 of 26 , Jan 11, 2002
                        --- jdk_kjdavies <kjdavies@...> wrote:
                        > --- In pcgen-xml@y..., Ryan Koppenhaver <rlkoppenhaver@y...> wrote:
                        > > --- kyuzo184 <sh@c...> wrote:

                        > > How
                        > > about a name ("Acid Fog"), and a unique id of the form
                        > > "spell.[source].[name]", where source and name are in some standard
                        > > format, i.e., all lower case with spaces changed to underscores or
                        > > something?
                        >
                        > Melf's Acid Arrow.

                        Ok, so (for those of you who speak Perl):

                        $id = $name
                        $id =~ tr/A-Z /a-z_/; #lower case, and spaces become underscores
                        $id =~ s/[^a-z_]//g; #strip everything else

                        $id = "spell.$source.$id";

                        Which gives us "spell.phb.melfs_acid_arrow".

                        > The refname -- unlike that for, say, Magic Missile, is not all
                        > lowercase. We need to be able to manage that, without requiring
                        > special-case handling ('these words are not to be made lowercase'...
                        > yech).

                        Is there a reason that we can't change "Melf's" to "melfs" for creating
                        an ID?

                        > Normal output for references is 'if refname is present, use
                        > that. If it isn't use the name' (we can decide whether the name is
                        > to be automatically lowercased or not; I suspect so as it's the usual
                        > case). This makes refname an optional attribute.

                        As I said before, that's perfectly possible, but I think that using
                        ID's will save us from having to having to write searching functions
                        later on, since most XML tools will have "find the node with this ID"
                        built in.

                        > Nope. My intention is to do this for range, at least. Medium looks
                        > like it's *always* 100+10/level, short is 25 + 5/2 levels, long is
                        > 400 + 40/level. I'd probably do
                        >
                        > <range range="medium"/>
                        > <range>Something really weird goes here...</range>
                        >
                        > to allow reuse of common, static information. It also lends itself
                        > well to change -- "Medium just became 150 + 15/level? Noooo!"

                        > [same thing for duration and saves]

                        Fine with me. I suspect we won't do much with these things anyway,
                        mostly they'll just be printed out on the charsheet, so having
                        predefined ranges and durations just saves some typing.

                        > <source refid="wotc.phb" page="172"/>
                        >
                        > This stuff can be *easily* indexed and looked up, and you don't have
                        > to worry about mispellings (hmm... do I want stuff from the "Player's
                        > Handbook", the "Players Handbook", or the "Players Hadnbkoo"?)

                        *nod*

                        -Ryan

                        __________________________________________________
                        Do You Yahoo!?
                        Send FREE video emails in Yahoo! Mail!
                        http://promo.yahoo.com/videomail/
                      • jdk_kjdavies
                        ... standard ... or ... I m not sure I d include the source in the id -- we ll have enough data that remembering the specific source during keying may become a
                        Message 11 of 26 , Jan 11, 2002
                          --- In pcgen-xml@y..., Ryan Koppenhaver <rlkoppenhaver@y...> wrote:
                          > --- jdk_kjdavies <kjdavies@t...> wrote:
                          > > --- In pcgen-xml@y..., Ryan Koppenhaver <rlkoppenhaver@y...>
                          wrote:
                          > > > --- kyuzo184 <sh@c...> wrote:
                          >
                          > > > How
                          > > > about a name ("Acid Fog"), and a unique id of the form
                          > > > "spell.[source].[name]", where source and name are in some
                          standard
                          > > > format, i.e., all lower case with spaces changed to underscores
                          or
                          > > > something?
                          > >
                          > > Melf's Acid Arrow.
                          >
                          > Ok, so (for those of you who speak Perl):
                          >
                          > $id = $name
                          > $id =~ tr/A-Z /a-z_/; #lower case, and spaces become underscores
                          > $id =~ s/[^a-z_]//g; #strip everything else
                          >
                          > $id = "spell.$source.$id";
                          >
                          > Which gives us "spell.phb.melfs_acid_arrow".

                          I'm not sure I'd include the source in the id -- we'll have enough
                          data that remembering the specific source during keying may become a
                          hassle. I tried doing this once before and found it got awkward.
                          OTOH, I'm not too worried about ID creation at this time. We'll have
                          a standard, and this may be it, but it'll be decided later.

                          > > The refname -- unlike that for, say, Magic Missile, is not all
                          > > lowercase. We need to be able to manage that, without requiring
                          > > special-case handling ('these words are not to be made
                          lowercase'...
                          > > yech).
                          >
                          > Is there a reason that we can't change "Melf's" to "melfs" for
                          creating
                          > an ID?

                          None whatsoever. It's what I do now. I was talking about for
                          presentation. I think we'll define a rule, something like:

                          if the refname is present, use that
                          if the refname is not present, lowercase the name and use that

                          This allows for the nonstandard case where a name is presented in
                          uppercase in the lists, but lowercase in text. Hmm... will that
                          actually matter? We're not actually writing documents (which is what
                          my previous work with XML for D&D has been), so it may not come up.
                          Sort it out later.

                          > > Normal output for references is 'if refname is present, use
                          > > that. If it isn't use the name' (we can decide whether the name
                          is
                          > > to be automatically lowercased or not; I suspect so as it's the
                          usual
                          > > case). This makes refname an optional attribute.
                          >
                          > As I said before, that's perfectly possible, but I think that using
                          > ID's will save us from having to having to write searching functions
                          > later on, since most XML tools will have "find the node with this
                          ID"
                          > built in.

                          Okay, I see what you're saying here.

                          I have *always* intended to put IDs on anything that might be
                          referred to as a standalone item. For instance, a weapon, a spell, a
                          race, a skill, whatever. It never, ever even crossed my mind to not
                          do so.

                          A refname isn't used as a link for a reference, it's what gets
                          printed when that reference is called. For instance, (in text, which
                          I don't expect to be using, but anyway...) you'd have

                          "... and it causes the same damage as a
                          <ref refid='spell.fireball'/>, but as acid
                          instead ..."

                          and it could be rendered as "... and it causes the same damage as a
                          /fireball/, but as acid instead ...", rather than having '/Fireball/'
                          appear in the text.

                          Miscommunication; we both intended the same thing.

                          > > Nope. My intention is to do this for range, at least. Medium
                          looks
                          > > like it's *always* 100+10/level, short is 25 + 5/2 levels, long
                          is
                          > > 400 + 40/level. I'd probably do
                          > >
                          > > <range range="medium"/>
                          > > <range>Something really weird goes here...</range>
                          > >
                          > > to allow reuse of common, static information. It also lends
                          itself
                          > > well to change -- "Medium just became 150 + 15/level? Noooo!"
                          >
                          > > [same thing for duration and saves]
                          >
                          > Fine with me. I suspect we won't do much with these things anyway,
                          > mostly they'll just be printed out on the charsheet, so having
                          > predefined ranges and durations just saves some typing.

                          I don't expect to either; they're here for presentation. It not only
                          saves some typing, but helps consistency ("Medium (10+10/level)?
                          What?").

                          > > <source refid="wotc.phb" page="172"/>

                          I think we'll do what Mynex suggested and include multiple source
                          entries, in case we end up with multiple editions of the document...
                          the above would then become

                          <source refid="wotc.phb" page="172"/>
                          <source refid="wotc.phb.2e" page="174"/>

                          Keith
                        • Ryan Koppenhaver
                          ... Fair enough, I m happy to table the issue for now, but let me just point out that if we don t include the source, we ll run into repeated name problems.
                          Message 12 of 26 , Jan 11, 2002
                            --- jdk_kjdavies <kjdavies@...> wrote:
                            > > Which gives us "spell.phb.melfs_acid_arrow".
                            >
                            > I'm not sure I'd include the source in the id -- we'll have enough
                            > data that remembering the specific source during keying may become a
                            > hassle. I tried doing this once before and found it got awkward.
                            > OTOH, I'm not too worried about ID creation at this time. We'll have
                            > a standard, and this may be it, but it'll be decided later.

                            Fair enough, I'm happy to table the issue for now, but let me just
                            point out that if we don't include the source, we'll run into repeated
                            name problems.


                            > if the refname is present, use that
                            > if the refname is not present, lowercase the name and use that
                            >
                            > [...]
                            > Sort it out later.

                            Yeah.

                            > A refname isn't used as a link for a reference, it's what gets
                            > printed when that reference is called. For instance, (in text, which
                            >
                            > I don't expect to be using, but anyway...) you'd have
                            >
                            > "... and it causes the same damage as a
                            > <ref refid='spell.fireball'/>, but as acid
                            > instead ..."
                            >
                            > and it could be rendered as "... and it causes the same damage as a
                            > /fireball/, but as acid instead ...", rather than having '/Fireball/'
                            >
                            > appear in the text.

                            Oh, ok. I see.

                            > Miscommunication; we both intended the same thing.

                            Hate it when that happens.

                            > I don't expect to either; they're here for presentation. It not only
                            > saves some typing, but helps consistency ("Medium (10+10/level)?
                            > What?").

                            Yep.


                            > I think we'll do what Mynex suggested and include multiple source
                            > entries, in case we end up with multiple editions of the document...
                            > the above would then become
                            >
                            > <source refid="wotc.phb" page="172"/>
                            > <source refid="wotc.phb.2e" page="174"/>

                            Works for me. Could be good for material that gets published in more
                            than one place, too.

                            -Ryan

                            __________________________________________________
                            Do You Yahoo!?
                            Send FREE video emails in Yahoo! Mail!
                            http://promo.yahoo.com/videomail/
                          • pjak
                            ... Also, some books are very badly organized (Rokugan, Oriental Adventures, Divine & Defeated, Lords of Darkness immediately spring to mind) as far as finding
                            Message 13 of 26 , Jan 14, 2002
                              --- In pcgen-xml@y..., "Mynex" <mynex3@h...> wrote:
                              >
                              > Here I have to disagree. The page #'s should be kept.

                              Also, some books are very badly organized (Rokugan, Oriental
                              Adventures, Divine & Defeated, Lords of Darkness immediately spring
                              to mind) as far as finding things. (They have spells and prestige
                              classes scattered all over the place.) It can also be a hassle
                              finding things in a Dragon issue.

                              /Jonas
                            • Keith Davies
                              ... Yep. I ve decided to leave page number in, probably by including multiple tags. Keith -- Keith Davies kjdavies@telus.net Elarios: Shade, you
                              Message 14 of 26 , Jan 14, 2002
                                pjak wrote on Mon Jan 14 04:59:21 2002:
                                >
                                > --- In pcgen-xml@y..., "Mynex" <mynex3@h...> wrote:
                                > >
                                > > Here I have to disagree. The page #'s should be kept.
                                >
                                > Also, some books are very badly organized (Rokugan, Oriental
                                > Adventures, Divine & Defeated, Lords of Darkness immediately spring
                                > to mind) as far as finding things. (They have spells and prestige
                                > classes scattered all over the place.) It can also be a hassle
                                > finding things in a Dragon issue.

                                Yep. I've decided to leave page number in, probably by including
                                multiple <source> tags.

                                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?"
                              • kyuzo184
                                Certainly a lot of opinions on this topic. I m not going to go point by point through each post but I have read them all. On the notion of components, while I
                                Message 15 of 26 , Jan 14, 2002
                                  Certainly a lot of opinions on this topic. I'm not going to go point
                                  by point through each post but I have read them all.

                                  On the notion of components, while I agree that it is probably better
                                  to use V,S,M etc. I think I would prefer having these as elements
                                  instead of attributes for a couple of reasons. First, you only end
                                  up listing the components that are used. Second, if new component
                                  types are added at a later date, exisiting files do not need to be
                                  changed. I'm not sure how often that would be needed but I can see
                                  the possibility of DM's wanting custom components in their
                                  campaigns. Just a thought.

                                  Another thing that I'm not sure I have a clear opinion on is your
                                  suggested defense tag and it's attributes. I don't see it as a
                                  problem as suggested but I do like the idea that each line in the
                                  spell description be given it's own element.

                                  Can someone post a new example of a spell so we can see what we have
                                  so far? I find putting together the fragments from this thread a
                                  little difficult.

                                  I know someone said that attributes are easier to parse than elements
                                  but I have had a difficult time verifying this in any of the xml
                                  documentation I have seen so far. Can anyone point me to an article
                                  on this so I can better understand this whole thing? Does it depend
                                  on what parser you use? What are the choices that the coders have
                                  for the pcgen project? Am I asking too many questions?

                                  -Stefan
                                • Keith Davies
                                  ... You don t need to put them all in as attributes, either -- you can default them in the schema or simply leave them undefined in the data. ... it
                                  Message 16 of 26 , Jan 14, 2002
                                    kyuzo184 wrote on Mon Jan 14 07:53:17 2002:
                                    >
                                    > Certainly a lot of opinions on this topic. I'm not going to go point
                                    > by point through each post but I have read them all.
                                    >
                                    > On the notion of components, while I agree that it is probably better
                                    > to use V,S,M etc. I think I would prefer having these as elements
                                    > instead of attributes for a couple of reasons. First, you only end
                                    > up listing the components that are used. Second, if new component
                                    > types are added at a later date, exisiting files do not need to be
                                    > changed. I'm not sure how often that would be needed but I can see
                                    > the possibility of DM's wanting custom components in their
                                    > campaigns. Just a thought.

                                    You don't need to put them all in as attributes, either -- you can
                                    default them in the schema or simply leave them undefined in the
                                    data.

                                    > Another thing that I'm not sure I have a clear opinion on is your
                                    > suggested defense tag and it's attributes. I don't see it as a
                                    > problem as suggested but I do like the idea that each line in the
                                    > spell description be given it's own element.

                                    <shrug> it was an example; it's not necessarily how we're going to do
                                    it. I tend to lump similar and related things into a single element
                                    when it seems reasonable (for instance, when describing monster attacks
                                    (as in the MM), I put the attack bonus, attack name, and attack damage
                                    all in the same element, even though it's not that way in the book.
                                    Why? It's no more difficult to handle when printing the information to
                                    paper in a fashion similar to that in the book, and it's much easier if
                                    I want to present it differently because I've got the closer relationship
                                    in the XML data.

                                    > Can someone post a new example of a spell so we can see what we have
                                    > so far? I find putting together the fragments from this thread a
                                    > little difficult.
                                    >
                                    > I know someone said that attributes are easier to parse than elements
                                    > but I have had a difficult time verifying this in any of the xml
                                    > documentation I have seen so far. Can anyone point me to an article
                                    > on this so I can better understand this whole thing? Does it depend
                                    > on what parser you use? What are the choices that the coders have
                                    > for the pcgen project? Am I asking too many questions?

                                    When writing XSLT, I usually find attributes easier to work with than
                                    elements. Personal preference.


                                    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?"
                                  Your message has been successfully submitted and would be delivered to recipients shortly.