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

Re: Revised Spell example

Expand Messages
  • jdk_kjdavies
    ... find ... slref ... spell ... Okay, badly-named element -- I d originally considered but I was feeling lazy. It s supposed to be a
    Message 1 of 26 , Jan 11, 2002
    • 0 Attachment
      --- In pcgen-xml@y..., Karl-Petter Åkesson <kalle@s...> wrote:
      >
      >
      > jdk_kjdavies wrote:
      > >
      > > <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>
      > >
      > > As you can see, I'm a fan of using attributes over elements. I
      find
      > > it saves me a *lot* of typing.
      >
      > Saving typing is good but not on the cost of readability. IMO
      "slref"
      > isnt very understandable and can lead to misunderstandings. Is it
      spell
      > list reference or spell reference?

      Okay, badly-named element -- I'd originally considered <spell-list-
      ref> but I was feeling lazy. It's supposed to be a spell-list
      reference; the only difference between this one and a normal <ref> is
      the level attribute.

      > > I would still separate the spell lists from the spells, and have
      the
      > > association made from the list to the spell, rather than the
      spell to
      > > the list. When looking through spells, it is usually (IMO) done
      by
      > > list rather than by spell -- when I'm looking for a new spell for
      my
      > > sorcerer, I don't need or want to see divine spells, or arcane
      spells
      > > I don't have access to (which for sorcerers is nil... so far).
      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.
      >
      > I like the seperate spelllists more but by another reason. I like to
      > seperate things into simple objects, the spell is one, defined by
      what
      > it does, a domain is something else as well as a spell list is
      something
      > completley different. It is also much more flexible.

      Yep, all good reasons and the ones I originally used for self-
      justification. I was trying to argue against the comment about the
      earlier example (<!ENTITY spell (class+)>) being less work. Not in
      the long run, IMO....


      Keith
    • 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 2 of 26 , Jan 11, 2002
      • 0 Attachment
        --- 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 3 of 26 , Jan 11, 2002
        • 0 Attachment
          --- 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 4 of 26 , Jan 11, 2002
          • 0 Attachment
            >--- 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 5 of 26 , Jan 11, 2002
            • 0 Attachment
              >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 6 of 26 , Jan 11, 2002
              • 0 Attachment
                --- 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 7 of 26 , Jan 11, 2002
                • 0 Attachment
                  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 8 of 26 , Jan 11, 2002
                  • 0 Attachment
                    --- 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 9 of 26 , Jan 11, 2002
                    • 0 Attachment
                      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 10 of 26 , Jan 11, 2002
                      • 0 Attachment
                        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 11 of 26 , Jan 11, 2002
                        • 0 Attachment
                          --- 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 12 of 26 , Jan 11, 2002
                          • 0 Attachment
                            --- 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 13 of 26 , Jan 11, 2002
                            • 0 Attachment
                              --- 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 14 of 26 , Jan 14, 2002
                              • 0 Attachment
                                --- 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 15 of 26 , Jan 14, 2002
                                • 0 Attachment
                                  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 16 of 26 , Jan 14, 2002
                                  • 0 Attachment
                                    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 17 of 26 , Jan 14, 2002
                                    • 0 Attachment
                                      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.