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

Re: [pcgen-xml] XML plan summary

Expand Messages
  • Keith Davies
    ... The original timeline I was told by Mynex was 3-6 weeks. I ve since talked with Bryan and we re looking at a couple of months instead... which I think is
    Message 1 of 21 , Mar 3 9:15 AM
    • 0 Attachment
      On Mon, Mar 03, 2003 at 11:45:11AM -0500, CC Americas 1 Carstensen James wrote:
      > Keith,
      >
      > You seem to have some definite time goals in mind, and there seems to
      > be some outside prodding. One point I'd like to bring up is GenCon.

      The original timeline I was told by Mynex was 3-6 weeks. I've since
      talked with Bryan and we're looking at a couple of months instead...
      which I think is actually doable. We'll have time to prepare for it,
      then we can hit it pretty hard.

      > Last year we had a fairly obviously buggy version of PCGen for
      > distribution. (Beep - helpfiles) PCGen right now has it's share of
      > problems but nothing incredibly major.

      *Personally* I'd agree with you. I'd like to start after GenCon, but
      tPtB want it in before that. As such, and because Tir's climbing all
      over me to minimize changes in syntax (we're going to XML from ad hoc
      text; *how* can you not have changes?), we're going the accelerated
      route that probably could've been done last year about this time rather
      than the redesigned route I'd prefer.

      If we finish in two months, that still gives us time to iron out bugs
      before GenCon. Not as much as I'd like, but because of the focus we'll
      need in order to meet the deadline, I think we'll be able to avoid a
      bunch of problems by the simple expedient of not dicking with too much.

      Heh, Bryan pointed out that PCGen-XML might end up being the (de facto)
      industry standard schema for d20 XML data. I didn't have time before he
      logged off, but I'll have to warn him *not* to use what we're producing
      right now to meet this deadline.

      > P.S. You know, XML will load into an Access database fairly easily.

      It can, yes. Actually using Access in PCGen is dubious, but it should
      be relatively easy to load. Certainly easier than LST.


      Keith
      --
      Keith Davies
      keith.davies@...

      PCGen: <reaper/>, smartass
      "You just can't argue with a moron. It's like handling Nuclear
      waste. It's not good, it's not evil, but for Christ's sake, don't
      get any on you!!" -- Chuck, PCGen mailing list
    • CC Americas 1 Carstensen James
      Keith, Ok, so we ve got our short term plan of current LST file syntax to XML. 1. What can we (the rest of the PCGen-XML monkeys) do to help this along? 2.
      Message 2 of 21 , Mar 3 9:36 AM
      • 0 Attachment
        Keith,

        Ok, so we've got our short term plan of current LST file syntax to XML.

        1. What can we (the rest of the PCGen-XML monkeys) do to help this
        along?
        2. What's our (XML monkeys again) next step? I suggest looking at
        Phase 1 XML (for lack of a better term) and looking how to migrate it
        towards Phase 2 XML in easy to digest (and code) steps.

        Basically we're here, we want to help, how can we do so?

        > Heh, Bryan pointed out that PCGen-XML might end up being the (de
        facto)
        > industry standard schema for d20 XML data. I didn't have time before
        he
        > logged off, but I'll have to warn him *not* to use what we're
        producing
        > right now to meet this deadline.

        How does this play into our plans? I know there is a d20 XML effort
        already going, though I think we have a more general focus. If I recall
        correctly there have been some posts here about what they are doing is
        good, but doesn't fit PCGen's needs - do we reconcile?

        Thoughtfully,
        Blue
      • Keith Davies
        ... I ll post -- tonight, I think -- guidelines on converting LST syntax to XML syntax. For the most part, because we re making such minor changes to
        Message 3 of 21 , Mar 3 10:10 AM
        • 0 Attachment
          On Mon, Mar 03, 2003 at 12:36:38PM -0500, CC Americas 1 Carstensen James wrote:
          > Keith,
          >
          > Ok, so we've got our short term plan of current LST file syntax to XML.
          >
          > 1. What can we (the rest of the PCGen-XML monkeys) do to help this
          > along?
          > 2. What's our (XML monkeys again) next step? I suggest looking at
          > Phase 1 XML (for lack of a better term) and looking how to migrate it
          > towards Phase 2 XML in easy to digest (and code) steps.

          I'll post -- tonight, I think -- guidelines on converting LST syntax to
          XML syntax. For the most part, because we're making such minor changes
          to semantics, the changes will be obvious. There are some non-obvious
          things I want done, though, so I'll describe them.

          I've upped Eric's latest doco for LST syntax to the Files area in the
          20030303* folder. Please feel free to browse the document. If we have
          enough people working on this, I want to have each person work on a
          single file at a time, but each file to be worked on by at least two
          people separately. This will help prove the guidelines and the
          conversion; if two people come up with exactly the same thing, this is
          good, if they come up with something different it shows either
          inadequate documentation on my part, a mistake in a conversion, or
          something else that has be to looked into.

          > Basically we're here, we want to help, how can we do so?
          >
          > > Heh, Bryan pointed out that PCGen-XML might end up being the (de
          > > facto) industry standard schema for d20 XML data. I didn't have
          > > time before he logged off, but I'll have to warn him *not* to use
          > > what we're producing right now to meet this deadline.
          >
          > How does this play into our plans? I know there is a d20 XML effort
          > already going, though I think we have a more general focus. If I
          > recall correctly there have been some posts here about what they are
          > doing is good, but doesn't fit PCGen's needs - do we reconcile?

          I don't know that I completely understand your question here -- do you
          mean 'are we going to try to match what they've got', 'are we going to
          try to merge projects', or something else?

          At this point, I have no answer to that. The impression I get from
          their mailing list is such that we're working toward somewhat different
          goals... and I've got enough to deal with just trying to get PCGen data
          into XML without trying to do what they are <g>.


          Keith
          --
          Keith Davies
          keith.davies@...

          PCGen: <reaper/>, smartass
          "You just can't argue with a moron. It's like handling Nuclear
          waste. It's not good, it's not evil, but for Christ's sake, don't
          get any on you!!" -- Chuck, PCGen mailing list
        • Eric Beaudoin
          ... Goal of phase 1: Translate existing .lst syntax to XML. The resulting XML syntax will be converted to automaticaly so nothing can happen here that cannot
          Message 4 of 21 , Mar 3 10:36 AM
          • 0 Attachment
            At 13:10 2003.03.03, Keith Davies wrote:
            >I'll post -- tonight, I think -- guidelines on converting LST syntax to
            >XML syntax. For the most part, because we're making such minor changes
            >to semantics, the changes will be obvious. There are some non-obvious
            >things I want done, though, so I'll describe them.
            >
            >I've upped Eric's latest doco for LST syntax to the Files area in the
            >20030303* folder. Please feel free to browse the document. If we have
            >enough people working on this, I want to have each person work on a
            >single file at a time, but each file to be worked on by at least two
            >people separately. This will help prove the guidelines and the
            >conversion; if two people come up with exactly the same thing, this is
            >good, if they come up with something different it shows either
            >inadequate documentation on my part, a mistake in a conversion, or
            >something else that has be to looked into.

            Goal of phase 1:

            Translate existing .lst syntax to XML. The resulting XML syntax will be converted to automaticaly so nothing can happen here that cannot be automated with a convertion application.

            For this, we need ppl who know .lst syntax far more than you need ppl who know XML (Trust me, XML is way easier to lear than the existing PCGEN data language).

            Suggestion: team a monkey that knows the PCGEN .lst data with a monkey that knows XML.

            Suggestion II: Tir and Keith (and maybe me but I don't want to presume :-) should act as reviewers for the resulting syntax. I think we will need both Keith (as project manager for XML) and Tir (as BoD representative for the data) to accept the new syntax.

            I'm also posting this on the close DATA monkey list to get volunteers.

            For the Data Monkeys: The train is coming, you better get in now. The action for the XML convertion will happen on the pcgen-xml Y! group. If you do not get on the train now, you will not be allowed to bitch in 2 months when XML becaumes you way of life :-).

            Best


            -----------------------------------------------------------
            Éric "Space Monkey" Beaudoin
            >> In space, no one can hear you sleep...
            >> Camels to can climb trees (and sometime eat them)
            <mailto:beaudoer@...>
          • Keith Davies
            ... damn straight. ... Sounds right. ... Perhaps working in pairs, perhaps not. Once I get guidelines posted I d like to have multiple teams (of one, perhaps)
            Message 5 of 21 , Mar 3 6:28 PM
            • 0 Attachment
              On Mon, Mar 03, 2003 at 01:36:57PM -0500, Eric Beaudoin wrote:
              >
              > Goal of phase 1:
              >
              > Translate existing .lst syntax to XML. The resulting XML syntax will
              > be converted to automaticaly so nothing can happen here that cannot be
              > automated with a convertion application.

              damn straight.

              > For this, we need ppl who know .lst syntax far more than you need ppl
              > who know XML (Trust me, XML is way easier to lear than the existing
              > PCGEN data language).

              Sounds right.

              > Suggestion: team a monkey that knows the PCGEN .lst data with a monkey
              > that knows XML.

              Perhaps working in pairs, perhaps not. Once I get guidelines posted I'd
              like to have multiple teams (of one, perhaps) on each file type; sort of
              a genetic thing to hopefully iron out any inconsistencies in the
              guidelines or their interpretations. This step actually shouldn't take
              long; I can probably mow through the whole set of files in a day if I
              had time... but I want confirmation and good QA. If we get everyone
              with the same results, we probably have something good.

              > Suggestion II: Tir and Keith (and maybe me but I don't want to presume
              > :-) should act as reviewers for the resulting syntax. I think we will
              > need both Keith (as project manager for XML) and Tir (as BoD
              > representative for the data) to accept the new syntax.

              You're the poor bugger writing the script to convert things. You're in.

              I'll contact Tir (CC) him; I'd like either him or a designate here to
              help us review it from a data side. I think it'll be reasonably
              painless, but data monkey input will be important.

              > I'm also posting this on the close DATA monkey list to get volunteers.
              >
              > For the Data Monkeys: The train is coming, you better get in now. The
              > action for the XML convertion will happen on the pcgen-xml Y! group.
              > If you do not get on the train now, you will not be allowed to bitch
              > in 2 months when XML becaumes you way of life :-).

              A little harsher than I would have worded it.... Not disagreeing,
              exactly, but I wouldn't have phrased it *quite* like that. It's not
              like I'm Mynex or something.


              Keith
              --
              Keith Davies
              keith.davies@...

              PCGen: <reaper/>, smartass
              "You just can't argue with a moron. It's like handling Nuclear
              waste. It's not good, it's not evil, but for Christ's sake, don't
              get any on you!!" -- Chuck, PCGen mailing list
            • Eric Beaudoin
              ... I guess I ve been hanging with the wrong crowd for to long (and did put a smiley at the end ;-) ) ... Éric Space Monkey Beaudoin ...
              Message 6 of 21 , Mar 3 7:12 PM
              • 0 Attachment
                At 21:28 2003.03.03, Keith Davies wrote:
                >> For the Data Monkeys: The train is coming, you better get in now. The
                >> action for the XML convertion will happen on the pcgen-xml Y! group.
                >> If you do not get on the train now, you will not be allowed to bitch
                >> in 2 months when XML becaumes you way of life :-).
                >
                >A little harsher than I would have worded it.... Not disagreeing,
                >exactly, but I wouldn't have phrased it *quite* like that. It's not
                >like I'm Mynex or something.

                I guess I've been hanging with the wrong crowd for to long (and did put a smiley at the end ;-) )


                -----------------------------------------------------------
                Éric "Space Monkey" Beaudoin
                >> In space, no one can hear you sleep...
                >> Camels to can climb trees (and sometime eat them)
                <mailto:beaudoer@...>
              • Keith Davies
                ... Okay, I m starting to go a little incoherent, so I ll post this now. The example at the bottom is incomplete; I ll update it tomorrow but I want to get
                Message 7 of 21 , Mar 3 10:54 PM
                • 0 Attachment
                  On Mon, Mar 03, 2003 at 10:10:48AM -0800, Keith Davies wrote:
                  >
                  > I'll post -- tonight, I think -- guidelines on converting LST syntax to
                  > XML syntax. For the most part, because we're making such minor changes
                  > to semantics, the changes will be obvious. There are some non-obvious
                  > things I want done, though, so I'll describe them.

                  Okay, I'm starting to go a little incoherent, so I'll post this now.
                  The example at the bottom is incomplete; I'll update it tomorrow but I
                  want to get what I got, out.

                  Please read, consider, and discuss the guidelines below. I have also
                  uploaded them to the Files area in the 20030303 LST -> XML folder.

                  Keith


                  In an effort to reduce the degree and scope of change in the data model
                  when converting to XML, we will be doing a more or less direct
                  translation of the existing LST tags to XML elements and attributes.
                  There are certain guidelines to be followed in doing this translation.
                  This document contains those guidelines and the reason behind them.

                  For those unfamiliar with XML, a document describing references to XML
                  information will be written. Don't worry if you don't understand some
                  of the technical information about XML below, it will become clear
                  later.

                  FILE-SPECIFIC GUIDELINES

                  0. ALL DATA FILES WILL BE CONFORMANT XML.

                  All data files produced must be loadable by a non-validating XML
                  parser. This means that, at a barest minimum, the file must conform
                  to the XML standard.

                  In addition, all files must meet the schema we will design here.
                  That means that all required elements and attributes are present,
                  and only allowed elements and attributes are present. This is very
                  close to being valid XML files, except that validity requires that
                  all elements referred to exist in the file or in a file loaded using
                  an external entity. We will not be using external entities in this
                  project, we will be using dependencies (similar in behavior to the
                  current tags used to load other files (EQUIPMENT, FEAT, SKILL,
                  etc.). If all dependencies for a file are met (that is, all files
                  it depends on are loaded) all references must be satisfied.

                  1. All files may be heterogeneous.

                  There is no technical need to have only a single record type in a
                  file. However, convention dictates that this is so.

                  So, for data files distributed by the PCGen and CMP teams, only a
                  single (general) type of data will be present. However, we will
                  also have the ability to create fully-encapsulated files. This
                  means we could put the entire encoded data from a sourcebook into a
                  single file, or even do a full character export that puts a
                  character and all data necessary to support that character --
                  spells, weapons, feats, and so on.

                  2. All files will conform to the same schema.

                  There will no longer be a technical distinction between file types.
                  Because all files may contain all data types, there is no need to
                  differentiate between file types. However, we may continue to do so
                  to simplify organization.

                  So, while a file may contain any type of data, we may still have
                  'PCC files' that consist solely of dependency statements that will
                  cause other files to be loaded, and 'LST' files that will contain,
                  as much as possible, only data.

                  3. All files will identify their dependencies.

                  In order to minimize unmatched references and incomplete links
                  between data, all data files must identify the files that contain
                  the elements they need. For instance, a file containing race
                  definitions would almost certainly include class definitions to
                  ensure that the preferred classes are found when the races are
                  processed.

                  It will be allowable for two files to be mutually dependent (though
                  it's a good idea to avoid that when possible). The loader will be
                  able to successfully deal with this.

                  XML Guidelines

                  4. All major elements will have XML IDs.

                  Says it all, really. All major elements will have ID fields and
                  values that comply to XML standards. This makes it possible to use
                  third-party tools to process the data files. Also, by using static
                  ID values we can insulate ourselves from spelling mistakes in names
                  and relabeling things.

                  A simple definition of XML IDs is that they begin with alphabetic
                  characters, followed by some number of alphabetic or numerical
                  characters or hyphen ('-') or period ('.'). (This is not a
                  *strictly* accurate description but will suffice for our purposes.)

                  IDs will be derived from the data being encoded. IDs will consist
                  of at least two components, and possibly more.

                  The first component will be the object type (*not* the data type).
                  For instance, when encoding information about weapons the first
                  component of these elements will be 'weapon', not 'equipment', even
                  though the element type may be <equipment>. Part of preparing the
                  translation instructions and schema for a LST file type will be
                  identifying the component type. It is possible for a single LST
                  file to produce multiple values for this first component.

                  The second part will be the name of the object being described,
                  modified to fit the specification above. The name will be changed
                  to lowercase, all punctuation will be removed, and all spaces
                  changed to hyphens.

                  The third and following parts, if present, either differentiate
                  between objects that would otherwise be the same or clarify the ID
                  of the object.

                  So, some specific examples:

                  fireball => spell.fireball
                  delayed blast fireball => spell.delayed-blast-fireball
                  Melf's acid arrow => spell.melfs-acid-arrow

                  Ranger => class.ranger
                  Monte's Ranger => class.ranger.monte-cook

                  We could instead use arbitrary ID values (for instance, initials of
                  the person doing the data entry followed by a sequential number) --
                  I could as effectively set the IDs above to kjd.18333, kjd.18334,
                  kjd.18335. However, by encoding them as I have above it makes it
                  easier to make links manually (I want the spell fireball... well,
                  that's obvious, 'spell.fireball') and easier to troubleshoot links
                  because it's clear what the ID is referring to.

                  5. Elements and attributes will be interpreted consistently.

                  Tags will be made consistent. Their content and semantics will be
                  the same in all places they are used. If there are currently two
                  tags used in LST files that differ in content or interpretation
                  either they will be made the same or (at least) one of them will be
                  renamed.

                  It is possible for two elements or attributes to have the same name
                  but contain *slightly* different information. For instance, a 'ref'
                  attribute will always contain an ID. Depending on the elements
                  containing the ref attributes they might contain IDs of different
                  element types, but they will still contain IDs.

                  6. The order of child elements will be fixed.

                  Elements will appear in a consistent order within the parent. This
                  makes it easier to validate the files. That is, if a major element
                  allows child elements 'name', 'types', and 'cost' they will always
                  appear in that order. If a child element is optional (such as
                  'cost' above) it might or might not be present, but if it is present
                  it will follow 'types'.

                  7. Order of child elements will be consistent between types.

                  Where two major elements have the same child elements, those child
                  elements will appear in the same order in both. Common child
                  elements will be identified during this analysis and their common
                  order determined.

                  I expect we will take this opportunity to further globalize data
                  elements. For instance, anything that can take prereqs will be able
                  to take all prereqs, and -- unless it risks breaking the internal
                  data model -- anything that can be applied can be applied by
                  anything. For instance, if an existing LST data type can give a
                  bonus at all, it will be able to give a bonus of any type, and I'd
                  like to extend it to allow other kinds of changes (such as giving
                  feats).

                  As a result, I want to make some data types more or less generic.
                  For instance, all bonus types will be defined and allowable anywhere
                  any bonuses are allowed, prereqs will always behave the same way,
                  and so on.

                  Style Guidelines

                  10. All XML-related values will be lowercase.

                  XML is case-sensitive. We will stick to a single case, and that
                  case will be lowercase. XML encoded entirely in uppercase is hard
                  to read because the tags conceal the data, and it's awkward to try
                  to type.

                  This applies to all namespaces, element names, attribute names, and
                  ID values. It does not apply to game data.

                  11. Most data values will be child elements.

                  Because the ordinality of tags is not always obvious and is subject
                  to change, we will make them child elements (an attribute may appear
                  only once per element). However, some current tags will be combined
                  into an element and attributes. Specifically 'DESC' and DESCISPI
                  will be combined to form an element and attribute, <desc ispi="y">.

                  This technique will be used whenever two current tags are closely
                  related, such as 'desc' and 'descispi', above, or 'name' and 'ispi',
                  or 'name' and 'abbrev' (or is that 'abb'?). If one tag would be
                  meaningless without the other they are good candidates for
                  association as described here.

                  12. Related game elements will be clearly associated.

                  As much as is reasonable, related information will be kept together.
                  It will *not* be necessary for a program loading data files to infer
                  relationships between data elements.

                  Things that are intrinsically part of a parent will be fully
                  contained by that parent. Things that are related to another item
                  will refer to the master by ID.

                  Some specific examples:

                  Class levels will be child elements of the class. Thus:

                  <class id="class.wizard">
                  <name>Wizard</name>
                  <hit-die>4</hit-die>
                  <levels>
                  <level level="1">
                  <add-feat ref="feat.scribe-scroll"/>
                  </level>
                  <level level="5">
                  <add-feat><choose type="wizard"/></add-feat>
                  </level>
                  <level level="10">
                  <add-feat><choose type="wizard"/></add-feat>
                  </level>
                  </levels>
                  </class>

                  Subclasses will not be child elements of the class. Thus:

                  <class id="class.wizard.illusionist" master="class.wizard">
                  <name>Illusionist</name>
                  <hit-die>4</hit-die>
                  <!-- identify barred schools; I don't know this yet -->
                  <levels>
                  <level level="1">
                  <add-feat ref="feat.scribe-scroll"/>
                  </level>
                  <level level="5">
                  <add-feat><choose type="wizard"/></add-feat>
                  </level>
                  <level level="10">
                  <add-feat><choose type="wizard"/></add-feat>
                  </level>
                  </levels>
                  </class>

                  13. Closely-related encoding elements will be grouped.

                  Where there are multiple child elements of similar nature, they will
                  be grouped under a superior element.

                  Specific example:

                  When encoding prerequisites, they will be grouped together as
                  below (bogus example):

                  <class id="class.assassin">
                  <name>Assassin</name>
                  <prereqs>
                  <prebab value="3"/>
                  <preskill ref="skill.move-silently" ranks="8"/>
                  <prespecial>Must kill a sentient humanoid for the sole purpose
                  of becoming an assassin.</prespecial>
                  </prereqs>
                  </class>

                  This was also demonstrated above by the <levels> element.

                  12. Ordinality must be noted.

                  When translating LST syntax to XML syntax, always identify the
                  number of times the child element is or may be present in the data.
                  This is subject to change, but this information will be made part of
                  the documentation for the XML schema and maintained.

                  Ordinality will be enforced. If only a single instance of an
                  element is allowed, more will *not* be allowed during processing.

                  13. Documentation

                  I will insist that all documentation be kept up to date. I will be
                  looking for someone to coordinate the documentation of the XML
                  schema and use.

                  14. Source information.

                  We will be replacing the current SOURCELONG, etc. tags. Currently
                  they are applied to data in the file by inference. There will be a
                  common namespace ('src') that contains this information. Like the
                  existing schema, the source information for a single element will be
                  determined by the source information of the parents, with source
                  information of the children overriding that of the parents.

                  For instance, a typical PCGen data file will look similar to:

                  <pcgen xmlns="http://www.pcgen.org/xml/1.0/lst.html"
                  xmlns:src="http://www.pcgen.org/xml/1.0/src.html"
                  src:publisher="Wizards of the Coast"
                  src:document="Core Rules I">
                  <!-- Wizards of the Coast - Core Rules 1 -->
                  <data src:subdocument="Chapter 1">
                  <!-- Wizards of the Coast - Core Rules 1 - Chapter 1-->
                  <score id="att.str">
                  <name abbrev="Str">Strength</name>
                  </score>
                  <score id="att.str">
                  <name abbrev="Str">Strength</name>
                  </score>
                  <score id="att.dex">
                  <name abbrev="Dex">Dexterity</name>
                  </score>
                  <score id="att.con">
                  <name abbrev="Con">Constitution</name>
                  </score>
                  <score id="att.int">
                  <name abbrev="Int">Intelligence</name>
                  </score>
                  <score id="att.wis">
                  <name abbrev="Wis">Wisdom</name>
                  </score>
                  <score id="att.cha">
                  <name abbrev="Cha">Charisma</name>
                  </score>
                  </data>
                  </pcgen>

                  Don't worry if the namespace (xmlns) attributes don't make sense; at
                  this point they can be templated.

                  One note about source information. I have considered having the
                  publisher, document, subdocument information and so on be references
                  to defined elements (putting ID values in the fields above) for
                  validation purposes, but I don't know if that is truly necessary or
                  will lead to unneeded elements. This is open for discussion.

                  Source attributes I expect to include at this point:

                  src:publisher -- the company or person who published the data
                  src:pub-href -- URI of the publisher's website
                  src:document -- title of the document
                  src:subdocument -- chapter, section, appendix etc. of the document
                  src:page -- specific page identifier
                  src:href -- closest possible URI of the data being encoded

                  This list is subject to extension or modification.

                  Examples

                  Here are some examples of encoded data elements; they should give an
                  indication of what the translations should provide.

                  Domain:

                  <domain id="domain.name" ispi="">
                  <name ispi="">Name</name>
                  <desc ispi="">Brief description</desc>
                  <prereqs>
                  <!-- all prereq types; I show only those present in CVS data -->
                  <prealign />
                  <preclass />
                  </prereqs>
                  <bonuses>
                  <bonus-skill />
                  <bonus-var />
                  </bonuses>
                  </domain>
                  --
                  Keith Davies
                  keith.davies@...

                  PCGen: <reaper/>, smartass
                  "You just can't argue with a moron. It's like handling Nuclear
                  waste. It's not good, it's not evil, but for Christ's sake, don't
                  get any on you!!" -- Chuck, PCGen mailing list
                • Eric Beaudoin
                  Some thoughts ... [snip.] ... This is not present now and will be a bitch to generate automaticaly from the existing files. Is this really needed for phase 1?
                  Message 8 of 21 , Mar 3 11:53 PM
                  • 0 Attachment
                    Some thoughts

                    At 01:54 2003.03.04, Keith Davies wrote:
                    >On Mon, Mar 03, 2003 at 10:10:48AM -0800, Keith Davies wrote:
                    >>
                    >> I'll post -- tonight, I think -- guidelines on converting LST syntax to
                    >> XML syntax. For the most part, because we're making such minor changes
                    >> to semantics, the changes will be obvious. There are some non-obvious
                    >> things I want done, though, so I'll describe them.
                    >
                    >Okay, I'm starting to go a little incoherent, so I'll post this now.
                    >The example at the bottom is incomplete; I'll update it tomorrow but I
                    >want to get what I got, out.
                    >
                    >Please read, consider, and discuss the guidelines below. I have also
                    >uploaded them to the Files area in the 20030303 LST -> XML folder.
                    >
                    >Keith
                    >

                    [snip.]

                    > 3. All files will identify their dependencies.
                    >
                    > In order to minimize unmatched references and incomplete links
                    > between data, all data files must identify the files that contain
                    > the elements they need. For instance, a file containing race
                    > definitions would almost certainly include class definitions to
                    > ensure that the preferred classes are found when the races are
                    > processed.
                    >
                    > It will be allowable for two files to be mutually dependent (though
                    > it's a good idea to avoid that when possible). The loader will be
                    > able to successfully deal with this.

                    This is not present now and will be a bitch to generate automaticaly from the existing files. Is this really needed for phase 1?

                    >XML Guidelines
                    >
                    > 4. All major elements will have XML IDs.
                    >
                    > Says it all, really. All major elements will have ID fields and
                    > values that comply to XML standards. This makes it possible to use
                    > third-party tools to process the data files. Also, by using static
                    > ID values we can insulate ourselves from spelling mistakes in names
                    > and relabeling things.
                    >
                    > A simple definition of XML IDs is that they begin with alphabetic
                    > characters, followed by some number of alphabetic or numerical
                    > characters or hyphen ('-') or period ('.'). (This is not a
                    > *strictly* accurate description but will suffice for our purposes.)
                    >
                    > IDs will be derived from the data being encoded. IDs will consist
                    > of at least two components, and possibly more.
                    >
                    > The first component will be the object type (*not* the data type).
                    > For instance, when encoding information about weapons the first
                    > component of these elements will be 'weapon', not 'equipment', even
                    > though the element type may be <equipment>. Part of preparing the
                    > translation instructions and schema for a LST file type will be
                    > identifying the component type. It is possible for a single LST
                    > file to produce multiple values for this first component.
                    >
                    > The second part will be the name of the object being described,
                    > modified to fit the specification above. The name will be changed
                    > to lowercase, all punctuation will be removed, and all spaces
                    > changed to hyphens.
                    >
                    > The third and following parts, if present, either differentiate
                    > between objects that would otherwise be the same or clarify the ID
                    > of the object.
                    >
                    > So, some specific examples:
                    >
                    > fireball => spell.fireball
                    > delayed blast fireball => spell.delayed-blast-fireball
                    > Melf's acid arrow => spell.melfs-acid-arrow
                    >
                    > Ranger => class.ranger
                    > Monte's Ranger => class.ranger.monte-cook
                    >
                    > We could instead use arbitrary ID values (for instance, initials of
                    > the person doing the data entry followed by a sequential number) --
                    > I could as effectively set the IDs above to kjd.18333, kjd.18334,
                    > kjd.18335. However, by encoding them as I have above it makes it
                    > easier to make links manually (I want the spell fireball... well,
                    > that's obvious, 'spell.fireball') and easier to troubleshoot links
                    > because it's clear what the ID is referring to.

                    This is another one that will be hard to automaticaly convert. Keep in mind that the converter will also have to work with the home made file. The problem is that you take the TYPE instead of the NAME to generate some IDs. Most object have multiple TYPEs, not just one. And there is nothing in the .lst files right now that identify the "main" type. The concept doesn't even exists at that level. Using file name is not an option since it will break home-made files.

                    What ID do you give to the .MOD and the .COPY= entities ?

                    BTW, I'm still would like to see why this is a desired thing to put in the scema :-).


                    > 5. Elements and attributes will be interpreted consistently.
                    >
                    > Tags will be made consistent. Their content and semantics will be
                    > the same in all places they are used. If there are currently two
                    > tags used in LST files that differ in content or interpretation
                    > either they will be made the same or (at least) one of them will be
                    > renamed.
                    >
                    > It is possible for two elements or attributes to have the same name
                    > but contain *slightly* different information. For instance, a 'ref'
                    > attribute will always contain an ID. Depending on the elements
                    > containing the ref attributes they might contain IDs of different
                    > element types, but they will still contain IDs.

                    I don't think there are any left like that if you exclude the PCC and the KIT files. I might be wrong though. The PCC will all vanished because there will be no longer any needs to specify the type of the file imported (Yopi!!!!)

                    BIOSET might be another one that will get weird.

                    > 6. The order of child elements will be fixed.
                    >
                    > Elements will appear in a consistent order within the parent. This
                    > makes it easier to validate the files. That is, if a major element
                    > allows child elements 'name', 'types', and 'cost' they will always
                    > appear in that order. If a child element is optional (such as
                    > 'cost' above) it might or might not be present, but if it is present
                    > it will follow 'types'.

                    I really don't think this is a good idea. The fact that tags on the lines are not order sensitive except when you use the same tag is a good thing. Time and again, we reorganise the orders to make them easier to read and new tags are seldom inserted at the right place the first time around.

                    This should be in the style guide but not inforce by the parser. Forcing the order is like the Cobol comments that needs to be in column 4, it will turn out to be a pain at some point.

                    In conclusion: style should not be enforce by the parser.

                    > 7. Order of child elements will be consistent between types.
                    >
                    > Where two major elements have the same child elements, those child
                    > elements will appear in the same order in both. Common child
                    > elements will be identified during this analysis and their common
                    > order determined.
                    >
                    > I expect we will take this opportunity to further globalize data
                    > elements. For instance, anything that can take prereqs will be able
                    > to take all prereqs, and -- unless it risks breaking the internal
                    > data model -- anything that can be applied can be applied by
                    > anything. For instance, if an existing LST data type can give a
                    > bonus at all, it will be able to give a bonus of any type, and I'd
                    > like to extend it to allow other kinds of changes (such as giving
                    > feats).
                    >
                    > As a result, I want to make some data types more or less generic.
                    > For instance, all bonus types will be defined and allowable anywhere
                    > any bonuses are allowed, prereqs will always behave the same way,
                    > and so on.

                    Again, it might be a good thing style wise but it must not be enforce by the parser.

                    As for a specific order of childs from one data type to another, experience as told us that it is not necessarely something we want. But since style should not be enforce by the parser, it is something that can be cleared out and thinker with over time :-).

                    >Style Guidelines
                    >

                    [snip.]

                    > 12. Related game elements will be clearly associated.
                    >
                    > As much as is reasonable, related information will be kept together.
                    > It will *not* be necessary for a program loading data files to infer
                    > relationships between data elements.
                    >
                    > Things that are intrinsically part of a parent will be fully
                    > contained by that parent. Things that are related to another item
                    > will refer to the master by ID.
                    >
                    > Some specific examples:
                    >
                    > Class levels will be child elements of the class. Thus:
                    >
                    > <class id="class.wizard">
                    > <name>Wizard</name>
                    > <hit-die>4</hit-die>
                    > <levels>
                    > <level level="1">
                    > <add-feat ref="feat.scribe-scroll"/>
                    > </level>
                    > <level level="5">
                    > <add-feat><choose type="wizard"/></add-feat>
                    > </level>
                    > <level level="10">
                    > <add-feat><choose type="wizard"/></add-feat>
                    > </level>
                    > </levels>
                    > </class>
                    >
                    > Subclasses will not be child elements of the class. Thus:
                    >
                    > <class id="class.wizard.illusionist" master="class.wizard">
                    > <name>Illusionist</name>
                    > <hit-die>4</hit-die>
                    > <!-- identify barred schools; I don't know this yet -->
                    > <levels>
                    > <level level="1">
                    > <add-feat ref="feat.scribe-scroll"/>
                    > </level>
                    > <level level="5">
                    > <add-feat><choose type="wizard"/></add-feat>
                    > </level>
                    > <level level="10">
                    > <add-feat><choose type="wizard"/></add-feat>
                    > </level>
                    > </levels>
                    > </class>

                    How do you link the class with the subclass then? Will each subclass have to repeat the whole level progression section (which would be bad)?

                    > 13. Closely-related encoding elements will be grouped.
                    >
                    > Where there are multiple child elements of similar nature, they will
                    > be grouped under a superior element.
                    >
                    > Specific example:
                    >
                    > When encoding prerequisites, they will be grouped together as
                    > below (bogus example):
                    >
                    > <class id="class.assassin">
                    > <name>Assassin</name>
                    > <prereqs>
                    > <prebab value="3"/>
                    > <preskill ref="skill.move-silently" ranks="8"/>
                    > <prespecial>Must kill a sentient humanoid for the sole purpose
                    > of becoming an assassin.</prespecial>
                    > </prereqs>
                    > </class>
                    >
                    > This was also demonstrated above by the <levels> element.

                    This seams like a cute thing when viewing the files in something like Internet Explorer but not really needed. This means one extra pair of delimeters to type. It also force us to put all the PRExxx tag together and make vertical formatting of the files more difficult. I would prefer 1 tag, 1 child.

                    Not related to item 13 but I would have tought that name would have been an argument, not a child. Each game entity has one and only one name (it's the first column at the beginning of the line). I think that would be a visual help for phase 1 since the name is the reference that ppl are used to see right now in the .lst files and in the GUI.

                    [snip.]

                    >Keith Davies
                    >keith.davies@...
                    >
                    >PCGen: <reaper/>, smartass
                    > "You just can't argue with a moron. It's like handling Nuclear
                    > waste. It's not good, it's not evil, but for Christ's sake, don't
                    > get any on you!!" -- Chuck, PCGen mailing list
                    >
                    >
                    >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/

                    -----------------------------------------------------------
                    Éric "Space Monkey" Beaudoin
                    >> In space, no one can hear you sleep...
                    >> Camels to can climb trees (and sometime eat them)
                    <mailto:beaudoer@...>
                  • Keith Davies
                    ... Good point. I d *like* it to be just so that the can t find /X/ problem goes away. OTOH, it isn t *strictly* required; I ll soften this. In the
                    Message 9 of 21 , Mar 4 6:51 AM
                    • 0 Attachment
                      On Tue, Mar 04, 2003 at 02:53:37AM -0500, Eric Beaudoin wrote:
                      > Some thoughts
                      >
                      > At 01:54 2003.03.04, Keith Davies wrote:
                      > >On Mon, Mar 03, 2003 at 10:10:48AM -0800, Keith Davies wrote:
                      > >>
                      > > 3. All files will identify their dependencies.
                      > >
                      > > In order to minimize unmatched references and incomplete links
                      > > between data, all data files must identify the files that contain
                      > > the elements they need. For instance, a file containing race
                      > > definitions would almost certainly include class definitions to
                      > > ensure that the preferred classes are found when the races are
                      > > processed.
                      > >
                      > > It will be allowable for two files to be mutually dependent (though
                      > > it's a good idea to avoid that when possible). The loader will be
                      > > able to successfully deal with this.
                      >
                      > This is not present now and will be a bitch to generate automaticaly
                      > from the existing files. Is this really needed for phase 1?

                      Good point. I'd *like* it to be just so that the 'can't find /X/'
                      problem goes away. OTOH, it isn't *strictly* required; I'll soften
                      this.

                      "In the future..."

                      The main benefit to this is that it clearly and unambiguously defines
                      the load order. If A requires B, then A indicates it and B will be
                      loaded (or at least opened) before A continues loading. It'd be (at
                      least theoretically, there are ways to prevent it) impossible to not
                      have the requirements met.

                      Tell you what, for the first part, how 'bout you just convert what's
                      present to XML, and I'll build a small utility to identify and place the
                      dependencies in the files. I think, once we get it to XML, this is will
                      be pretty easy; find all the IDs used by each file, and where a file has
                      external IDs in it list the files that contain that ID and slam them in.
                      There're only about 600 files right now; it'll suck, but only need to be
                      done once.

                      Hmm... maybe not. I think I'll make the utility so it can remember the
                      files to be inserted. Save me some work later.

                      > >XML Guidelines
                      > >
                      > > 4. All major elements will have XML IDs.
                      > >
                      > > Says it all, really. All major elements will have ID fields and
                      > > values that comply to XML standards. This makes it possible to use
                      > > third-party tools to process the data files. Also, by using static
                      > > ID values we can insulate ourselves from spelling mistakes in names
                      > > and relabeling things.
                      > >
                      > > A simple definition of XML IDs is that they begin with alphabetic
                      > > characters, followed by some number of alphabetic or numerical
                      > > characters or hyphen ('-') or period ('.'). (This is not a
                      > > *strictly* accurate description but will suffice for our purposes.)
                      > >
                      > > IDs will be derived from the data being encoded. IDs will consist
                      > > of at least two components, and possibly more.
                      > >
                      > > The first component will be the object type (*not* the data type).
                      > > For instance, when encoding information about weapons the first
                      > > component of these elements will be 'weapon', not 'equipment', even
                      > > though the element type may be <equipment>. Part of preparing the
                      > > translation instructions and schema for a LST file type will be
                      > > identifying the component type. It is possible for a single LST
                      > > file to produce multiple values for this first component.
                      > >
                      > > The second part will be the name of the object being described,
                      > > modified to fit the specification above. The name will be changed
                      > > to lowercase, all punctuation will be removed, and all spaces
                      > > changed to hyphens.
                      > >
                      > > The third and following parts, if present, either differentiate
                      > > between objects that would otherwise be the same or clarify the ID
                      > > of the object.
                      > >
                      > > So, some specific examples:
                      > >
                      > > fireball => spell.fireball
                      > > delayed blast fireball => spell.delayed-blast-fireball
                      > > Melf's acid arrow => spell.melfs-acid-arrow
                      > >
                      > > Ranger => class.ranger
                      > > Monte's Ranger => class.ranger.monte-cook
                      > >
                      > > We could instead use arbitrary ID values (for instance, initials of
                      > > the person doing the data entry followed by a sequential number) --
                      > > I could as effectively set the IDs above to kjd.18333, kjd.18334,
                      > > kjd.18335. However, by encoding them as I have above it makes it
                      > > easier to make links manually (I want the spell fireball... well,
                      > > that's obvious, 'spell.fireball') and easier to troubleshoot links
                      > > because it's clear what the ID is referring to.
                      >
                      > This is another one that will be hard to automaticaly convert. Keep in
                      > mind that the converter will also have to work with the home made
                      > file. The problem is that you take the TYPE instead of the NAME to
                      > generate some IDs. Most object have multiple TYPEs, not just one. And
                      > there is nothing in the .lst files right now that identify the "main"
                      > type. The concept doesn't even exists at that level. Using file name
                      > is not an option since it will break home-made files.

                      <shrug> the above is the way I'd like the IDs constructed. I've found
                      similar mechanisms to be very usable and useful in other projects. That
                      said, I think if we just take the existing NAME and smash it into an XML
                      ID that would be sufficient, probably base it on the file type. So, the
                      examples above would become

                      Fireball => spell.fireball
                      Delayed Blast Fireball => spell.delayed-blast-fireball
                      Melf's Acid Arrow => spell.melfs-acid-arrow

                      Ranger => class.ranger
                      Ranger (Monte Cook's) => class.ranger-monte-cooks

                      $id = $name;
                      $id =~ s/[^\w ]//g;
                      $id =~ s/\s+/-/g;
                      $id = "$filetype.$id"

                      > What ID do you give to the .MOD and the .COPY= entities ?

                      You don't. They aren't game items. .MOD will be put into another
                      namespace that has weaker requirements than the lst namespace. So, to
                      give Cleric a minimum Wis prereq, you'd do:

                      <mod:class ref="class.cleric">
                      <prereqs>
                      <prescore ref="att.wis" min="10" />
                      </prereqs>
                      </mod:class>

                      sort of thing. The structure is otherwise the same, but only fields
                      being changed need to be present. There is a mod:action attribute in
                      the fields present that defines what to do with the field; this defaults
                      to 'replace' (replacing a non-present field just inserts the new value)
                      but can also be 'delete'. So, if one file adds the above, another file
                      might do

                      <mod:class ref="class.cleric">
                      <prereqs mod:action="delete" />
                      </mod:class>

                      Similarly, I think there'll be a copy namespace that works much like the
                      mod namespace. All information will be copied from the target into the
                      new object, then subject to change. So, we might have

                      <copy:class id="class.cleric.2e" ref="class.cleric">
                      <name abbrev="Clr2">Cleric (2e)</name>
                      <prereqs>
                      <prescore ref="att.wis" min="9" />
                      </prereqs>
                      </copy:class>

                      > BTW, I'm still would like to see why this is a desired thing to put in
                      > the schema :-).

                      If nothing else, not having an ID will make life difficult, but

                      1. it makes certain optimizations in code easier -- Scott figures we can
                      probably get an order of magnitude performance gain by going to
                      unambiguous IDs. Granted, this could be gained if we just establish
                      clear rules for naming and names never, ever change, but that doesn't
                      meet...
                      2. XML specifies what characters may be present in IDs. If we build IDs
                      that are valid XML IDs we make it possible to use them in third-party
                      XML-specific tools.
                      3. By using XML IDs we will be able to use these third-party tools to
                      transform the XML data from one schema to another. This means that
                      we won't have to use ad hoc Perl scripts to do it, we can just write
                      a (relatively) simple XSLT script and run it over the data.

                      > > 5. Elements and attributes will be interpreted consistently.
                      > >
                      > > Tags will be made consistent. Their content and semantics will be
                      > > the same in all places they are used. If there are currently two
                      > > tags used in LST files that differ in content or interpretation
                      > > either they will be made the same or (at least) one of them will be
                      > > renamed.
                      > >
                      > > It is possible for two elements or attributes to have the same name
                      > > but contain *slightly* different information. For instance, a 'ref'
                      > > attribute will always contain an ID. Depending on the elements
                      > > containing the ref attributes they might contain IDs of different
                      > > element types, but they will still contain IDs.
                      >
                      > I don't think there are any left like that if you exclude the PCC and
                      > the KIT files. I might be wrong though. The PCC will all vanished
                      > because there will be no longer any needs to specify the type of the
                      > file imported (Yopi!!!!)
                      >
                      > BIOSET might be another one that will get weird.

                      If it's already gone, great. When we're done, they *will* be gone.

                      > > 6. The order of child elements will be fixed.
                      > >
                      > > Elements will appear in a consistent order within the parent. This
                      > > makes it easier to validate the files. That is, if a major element
                      > > allows child elements 'name', 'types', and 'cost' they will always
                      > > appear in that order. If a child element is optional (such as
                      > > 'cost' above) it might or might not be present, but if it is present
                      > > it will follow 'types'.
                      >
                      > I really don't think this is a good idea. The fact that tags on the
                      > lines are not order sensitive except when you use the same tag is a
                      > good thing. Time and again, we reorganise the orders to make them
                      > easier to read and new tags are seldom inserted at the right place the
                      > first time around.
                      >
                      > This should be in the style guide but not inforce by the parser.
                      > Forcing the order is like the Cobol comments that needs to be in
                      > column 4, it will turn out to be a pain at some point.
                      >
                      > In conclusion: style should not be enforce by the parser.

                      I think that *certain* fields should still have a fixed order. By
                      putting all required fields in a fixed order, we can actually ensure
                      that they are present using normal XML tools. If we have to check the
                      presence of required children *after* loading -- writing ad hoc code to
                      to do -- we add to the code that needs to be maintained. We'd be
                      throwing away one of the key benefits -- automated, 'free' validation of
                      the data. This does not strike me as a good idea.

                      I think the set of required tags for most items is pretty short. I
                      think we can gain the benefits I'm looking for by making their order
                      fixed but the rest can float.

                      > > 7. Order of child elements will be consistent between types.
                      > >
                      > > Where two major elements have the same child elements, those child
                      > > elements will appear in the same order in both. Common child
                      > > elements will be identified during this analysis and their common
                      > > order determined.
                      > >
                      > > I expect we will take this opportunity to further globalize data
                      > > elements. For instance, anything that can take prereqs will be able
                      > > to take all prereqs, and -- unless it risks breaking the internal
                      > > data model -- anything that can be applied can be applied by
                      > > anything. For instance, if an existing LST data type can give a
                      > > bonus at all, it will be able to give a bonus of any type, and I'd
                      > > like to extend it to allow other kinds of changes (such as giving
                      > > feats).
                      > >
                      > > As a result, I want to make some data types more or less generic.
                      > > For instance, all bonus types will be defined and allowable anywhere
                      > > any bonuses are allowed, prereqs will always behave the same way,
                      > > and so on.
                      >
                      > Again, it might be a good thing style wise but it must not be enforce
                      > by the parser.
                      >
                      > As for a specific order of childs from one data type to another,
                      > experience as told us that it is not necessarely something we want.
                      > But since style should not be enforce by the parser, it is something
                      > that can be cleared out and thinker with over time :-).

                      Actually, from above, let's soften this to required fields and common
                      fields. I want to keep the validation ability of XML.

                      > >Style Guidelines
                      > >
                      >
                      > [snip.]
                      >
                      > > 12. Related game elements will be clearly associated.
                      > >
                      > > As much as is reasonable, related information will be kept together.
                      > > It will *not* be necessary for a program loading data files to infer
                      > > relationships between data elements.
                      > >
                      > > Things that are intrinsically part of a parent will be fully
                      > > contained by that parent. Things that are related to another item
                      > > will refer to the master by ID.
                      > >
                      > > Some specific examples:
                      > >
                      > > Class levels will be child elements of the class. Thus:
                      > >
                      > > <class id="class.wizard">
                      > > <name>Wizard</name>
                      > > <hit-die>4</hit-die>
                      > > <levels>
                      > > <level level="1">
                      > > <add-feat ref="feat.scribe-scroll"/>
                      > > </level>
                      > > <level level="5">
                      > > <add-feat><choose type="wizard"/></add-feat>
                      > > </level>
                      > > <level level="10">
                      > > <add-feat><choose type="wizard"/></add-feat>
                      > > </level>
                      > > </levels>
                      > > </class>
                      > >
                      > > Subclasses will not be child elements of the class. Thus:
                      > >
                      > > <class id="class.wizard.illusionist" master="class.wizard">
                      > > <name>Illusionist</name>
                      > > <hit-die>4</hit-die>
                      > > <!-- identify barred schools; I don't know this yet -->
                      > > <levels>
                      > > <level level="1">
                      > > <add-feat ref="feat.scribe-scroll"/>
                      > > </level>
                      > > <level level="5">
                      > > <add-feat><choose type="wizard"/></add-feat>
                      > > </level>
                      > > <level level="10">
                      > > <add-feat><choose type="wizard"/></add-feat>
                      > > </level>
                      > > </levels>
                      > > </class>
                      >
                      > How do you link the class with the subclass then? Will each subclass
                      > have to repeat the whole level progression section (which would be
                      > bad)?

                      Good point. Actually, the copy mechanism described above:

                      <copy:class ref="class.wizard"
                      id="class.illusionist"
                      master="class.wizard">
                      <name>Illusionist</name>
                      <!-- identify barred schools; I don't know this yet -->
                      </copy>

                      Hmm... I like that. Simple.

                      The link is driven from the child to the parent; this removes the need
                      to modify the parent when more subclasses are added. For instance, IIRC
                      _Path of Magic_ adds more variant Wizard classes; rather than MODding
                      the Wizard class, we can just plug in these other classes.

                      > > 13. Closely-related encoding elements will be grouped.
                      > >
                      > > Where there are multiple child elements of similar nature, they will
                      > > be grouped under a superior element.
                      > >
                      > > Specific example:
                      > >
                      > > When encoding prerequisites, they will be grouped together as
                      > > below (bogus example):
                      > >
                      > > <class id="class.assassin">
                      > > <name>Assassin</name>
                      > > <prereqs>
                      > > <prebab value="3"/>
                      > > <preskill ref="skill.move-silently" ranks="8"/>
                      > > <prespecial>Must kill a sentient humanoid for the sole purpose
                      > > of becoming an assassin.</prespecial>
                      > > </prereqs>
                      > > </class>
                      > >
                      > > This was also demonstrated above by the <levels> element.
                      >
                      > This seams like a cute thing when viewing the files in something like
                      > Internet Explorer but not really needed. This means one extra pair of
                      > delimeters to type. It also force us to put all the PRExxx tag
                      > together and make vertical formatting of the files more difficult. I
                      > would prefer 1 tag, 1 child.

                      'vertical formatting is more difficult'? How so?

                      I've always considered prereqs, for example, to be closely enough
                      related that we want them in one place. I don't want to be looking
                      through the entire object to find all the prereqs. So, while XML does
                      not technically require it and we could do without, I think it's a good
                      idea for style reasons.

                      If there is strong enough dissent we can remove that, but I think there
                      is sufficient benefit to its presence to justify it.

                      > Not related to item 13 but I would have thought that name would have
                      > been an argument, not a child. Each game entity has one and only one
                      > name (it's the first column at the beginning of the line). I think
                      > that would be a visual help for phase 1 since the name is the
                      > reference that ppl are used to see right now in the .lst files and in
                      > the GUI.

                      I originally did this. However, there are a couple of attributes that
                      apply only to name (nameispi, abbrev/abb (I really should look this
                      up)); given that name is a data field and all other data fields are
                      children, I think that, for consistency, we should make name another
                      child.

                      OTOH, since it *is* almost the only data field required by all data
                      objects, that may be sufficient argument for making it an attribute.

                      I'm willing to go either way on this.


                      Keith
                      --
                      Keith Davies
                      keith.davies@...

                      PCGen: <reaper/>, smartass
                      "You just can't argue with a moron. It's like handling Nuclear
                      waste. It's not good, it's not evil, but for Christ's sake, don't
                      get any on you!!" -- Chuck, PCGen mailing list
                    • Keith Davies
                      Ah, now that I m a little more awake (45 minutes @ 60 mph does that...) I ll add to some of my comments below. ... I don t think there are actually *too* many
                      Message 10 of 21 , Mar 4 8:34 AM
                      • 0 Attachment
                        Ah, now that I'm a little more awake (45 minutes @ 60 mph does that...)
                        I'll add to some of my comments below.


                        On Tue, Mar 04, 2003 at 06:51:02AM -0800, Keith Davies wrote:
                        > On Tue, Mar 04, 2003 at 02:53:37AM -0500, Eric Beaudoin wrote:
                        > > Some thoughts
                        > >
                        > > At 01:54 2003.03.04, Keith Davies wrote:
                        > > >On Mon, Mar 03, 2003 at 10:10:48AM -0800, Keith Davies wrote:
                        > > >>
                        > > > 3. All files will identify their dependencies.
                        > > >
                        > > > In order to minimize unmatched references and incomplete links
                        > > > between data, all data files must identify the files that contain
                        > > > the elements they need. For instance, a file containing race
                        > > > definitions would almost certainly include class definitions to
                        > > > ensure that the preferred classes are found when the races are
                        > > > processed.
                        > > >
                        > > > It will be allowable for two files to be mutually dependent (though
                        > > > it's a good idea to avoid that when possible). The loader will be
                        > > > able to successfully deal with this.
                        > >
                        > > This is not present now and will be a bitch to generate automaticaly
                        > > from the existing files. Is this really needed for phase 1?
                        >
                        > Good point. I'd *like* it to be just so that the 'can't find /X/'
                        > problem goes away. OTOH, it isn't *strictly* required; I'll soften
                        > this.
                        >
                        > "In the future..."
                        >
                        > The main benefit to this is that it clearly and unambiguously defines
                        > the load order. If A requires B, then A indicates it and B will be
                        > loaded (or at least opened) before A continues loading. It'd be (at
                        > least theoretically, there are ways to prevent it) impossible to not
                        > have the requirements met.
                        >
                        > Tell you what, for the first part, how 'bout you just convert what's
                        > present to XML, and I'll build a small utility to identify and place the
                        > dependencies in the files. I think, once we get it to XML, this is will
                        > be pretty easy; find all the IDs used by each file, and where a file has
                        > external IDs in it list the files that contain that ID and slam them in.
                        > There're only about 600 files right now; it'll suck, but only need to be
                        > done once.
                        >
                        > Hmm... maybe not. I think I'll make the utility so it can remember the
                        > files to be inserted. Save me some work later.

                        I don't think there are actually *too* many dependencies between files.
                        There are some, but for the most part they should be pretty obvious.
                        Actually, there are more than there could be because of how associations
                        are made between things, but I don't want to risk changing that right
                        now.

                        > > >XML Guidelines
                        > > >
                        > > > 4. All major elements will have XML IDs.
                        > > >
                        > > > Says it all, really. All major elements will have ID fields and
                        > > > values that comply to XML standards. This makes it possible to use
                        > > > third-party tools to process the data files. Also, by using static
                        > > > ID values we can insulate ourselves from spelling mistakes in names
                        > > > and relabeling things.
                        > > >
                        > > > A simple definition of XML IDs is that they begin with alphabetic
                        > > > characters, followed by some number of alphabetic or numerical
                        > > > characters or hyphen ('-') or period ('.'). (This is not a
                        > > > *strictly* accurate description but will suffice for our purposes.)
                        > > >
                        > > > IDs will be derived from the data being encoded. IDs will consist
                        > > > of at least two components, and possibly more.
                        > > >
                        > > > The first component will be the object type (*not* the data type).
                        > > > For instance, when encoding information about weapons the first
                        > > > component of these elements will be 'weapon', not 'equipment', even
                        > > > though the element type may be <equipment>. Part of preparing the
                        > > > translation instructions and schema for a LST file type will be
                        > > > identifying the component type. It is possible for a single LST
                        > > > file to produce multiple values for this first component.
                        > > >
                        > > > The second part will be the name of the object being described,
                        > > > modified to fit the specification above. The name will be changed
                        > > > to lowercase, all punctuation will be removed, and all spaces
                        > > > changed to hyphens.
                        > > >
                        > > > The third and following parts, if present, either differentiate
                        > > > between objects that would otherwise be the same or clarify the ID
                        > > > of the object.
                        > > >
                        > > > So, some specific examples:
                        > > >
                        > > > fireball => spell.fireball
                        > > > delayed blast fireball => spell.delayed-blast-fireball
                        > > > Melf's acid arrow => spell.melfs-acid-arrow
                        > > >
                        > > > Ranger => class.ranger
                        > > > Monte's Ranger => class.ranger.monte-cook
                        > > >
                        > > > We could instead use arbitrary ID values (for instance, initials of
                        > > > the person doing the data entry followed by a sequential number) --
                        > > > I could as effectively set the IDs above to kjd.18333, kjd.18334,
                        > > > kjd.18335. However, by encoding them as I have above it makes it
                        > > > easier to make links manually (I want the spell fireball... well,
                        > > > that's obvious, 'spell.fireball') and easier to troubleshoot links
                        > > > because it's clear what the ID is referring to.
                        > >
                        > > This is another one that will be hard to automaticaly convert. Keep in
                        > > mind that the converter will also have to work with the home made
                        > > file. The problem is that you take the TYPE instead of the NAME to
                        > > generate some IDs. Most object have multiple TYPEs, not just one. And
                        > > there is nothing in the .lst files right now that identify the "main"
                        > > type. The concept doesn't even exists at that level. Using file name
                        > > is not an option since it will break home-made files.
                        >
                        > <shrug> the above is the way I'd like the IDs constructed. I've found
                        > similar mechanisms to be very usable and useful in other projects. That
                        > said, I think if we just take the existing NAME and smash it into an XML
                        > ID that would be sufficient, probably base it on the file type. So, the
                        > examples above would become
                        >
                        > Fireball => spell.fireball
                        > Delayed Blast Fireball => spell.delayed-blast-fireball
                        > Melf's Acid Arrow => spell.melfs-acid-arrow
                        >
                        > Ranger => class.ranger
                        > Ranger (Monte Cook's) => class.ranger-monte-cooks
                        >
                        > $id = $name;
                        > $id =~ s/[^\w ]//g;
                        > $id =~ s/\s+/-/g;
                        > $id = "$filetype.$id"

                        This would be close enough to what I described above. The script must
                        be able to identify the line type, right? While not optimal IMO, I
                        think it would be acceptable.

                        > > > Some specific examples:
                        > > >
                        > > > Class levels will be child elements of the class. Thus:
                        > > >
                        > > > <class id="class.wizard">
                        > > > <name>Wizard</name>
                        > > > <hit-die>4</hit-die>
                        > > > <levels>
                        > > > <level level="1">
                        > > > <add-feat ref="feat.scribe-scroll"/>
                        > > > </level>
                        > > > <level level="5">
                        > > > <add-feat><choose type="wizard"/></add-feat>
                        > > > </level>
                        > > > <level level="10">
                        > > > <add-feat><choose type="wizard"/></add-feat>
                        > > > </level>
                        > > > </levels>
                        > > > </class>
                        > > >
                        > > > Subclasses will not be child elements of the class. Thus:
                        > > >
                        > > > <class id="class.wizard.illusionist" master="class.wizard">
                        > > > <name>Illusionist</name>
                        > > > <hit-die>4</hit-die>
                        > > > <!-- identify barred schools; I don't know this yet -->
                        > > > <levels>
                        > > > <level level="1">
                        > > > <add-feat ref="feat.scribe-scroll"/>
                        > > > </level>
                        > > > <level level="5">
                        > > > <add-feat><choose type="wizard"/></add-feat>
                        > > > </level>
                        > > > <level level="10">
                        > > > <add-feat><choose type="wizard"/></add-feat>
                        > > > </level>
                        > > > </levels>
                        > > > </class>
                        > >
                        > > How do you link the class with the subclass then? Will each subclass
                        > > have to repeat the whole level progression section (which would be
                        > > bad)?
                        >
                        > Good point. Actually, the copy mechanism described above:
                        >
                        > <copy:class ref="class.wizard"
                        > id="class.illusionist"
                        > master="class.wizard">
                        > <name>Illusionist</name>
                        > <!-- identify barred schools; I don't know this yet -->
                        > </copy>
                        >
                        > Hmm... I like that. Simple.
                        >
                        > The link is driven from the child to the parent; this removes the need
                        > to modify the parent when more subclasses are added. For instance, IIRC
                        > _Path of Magic_ adds more variant Wizard classes; rather than MODding
                        > the Wizard class, we can just plug in these other classes.

                        Are there any subclasses or variant classes that can be used together?
                        I know that you can't be a Wizard and some sort of specialist wizard,
                        and that when you want to play a Psion you must specify a subclass, but
                        is it possible to play a multiclass who has levels of two subclasses of
                        a main class, or the main class and a subclass, or a subclass and a
                        variant?

                        Probably not -- according to published rules -- but I bet somebody's
                        going to want it supported. Bugger.

                        > > > 13. Closely-related encoding elements will be grouped.
                        > > >
                        > > > Where there are multiple child elements of similar nature, they will
                        > > > be grouped under a superior element.
                        > > >
                        > > > Specific example:
                        > > >
                        > > > When encoding prerequisites, they will be grouped together as
                        > > > below (bogus example):
                        > > >
                        > > > <class id="class.assassin">
                        > > > <name>Assassin</name>
                        > > > <prereqs>
                        > > > <prebab value="3"/>
                        > > > <preskill ref="skill.move-silently" ranks="8"/>
                        > > > <prespecial>Must kill a sentient humanoid for the sole purpose
                        > > > of becoming an assassin.</prespecial>
                        > > > </prereqs>
                        > > > </class>
                        > > >
                        > > > This was also demonstrated above by the <levels> element.
                        > >
                        > > This seams like a cute thing when viewing the files in something like
                        > > Internet Explorer but not really needed. This means one extra pair of
                        > > delimeters to type. It also force us to put all the PRExxx tag
                        > > together and make vertical formatting of the files more difficult. I
                        > > would prefer 1 tag, 1 child.
                        >
                        > 'vertical formatting is more difficult'? How so?
                        >
                        > I've always considered prereqs, for example, to be closely enough
                        > related that we want them in one place. I don't want to be looking
                        > through the entire object to find all the prereqs. So, while XML does
                        > not technically require it and we could do without, I think it's a good
                        > idea for style reasons.
                        >
                        > If there is strong enough dissent we can remove that, but I think there
                        > is sufficient benefit to its presence to justify it.

                        Another benefit I realized is tha currently all prereqs are combined
                        using an implicit 'and' -- all prereqs in the list must be satisfied
                        before the item may be taken. What if serial <prereq>s were used to
                        provide an implicit 'or', something like:

                        <class id="class.whatever">
                        <name>Whatever</name>
                        <prereqs>
                        <prebab value="5" />
                        </prereqs>
                        <prereqs>
                        <preskill ref="skill.move-silently" ranks="8" />
                        </prereqs>
                        </class>

                        Which would mean that BAB +5 or better or at least 8 ranks in Move
                        Silently. Or combine them:

                        <class id="class.whatever">
                        <name>Whatever</name>
                        <prereqs>
                        <prebab value="5" />
                        <preskill ref="skill.move-silently" ranks="4" />
                        </prereqs>
                        <prereqs>
                        <prebab value="3" />
                        <preskill ref="skill.move-silently" ranks="8" />
                        </prereqs>
                        </class>

                        Which would mean BAB +5 or better and at least 4 ranks in Move Silently,
                        or BAB +3 or better and at least 8 ranks in Move Silently.

                        Or nest them:

                        <class id="class.whatever">
                        <name>Whatever</name>
                        <prereqs>
                        <prebab value="5" />
                        <prereqs>
                        <preskill ref="skill.move-silently" ranks="4" />
                        </prereqs>
                        <prereqs>
                        <preskill ref="skill.hide" ranks="4" />
                        <preskill ref="skill.listen" ranks="4" />
                        </prereqs>
                        </prereqs>
                        </class>

                        BAB +5 or better, plus 4 ranks in Move Silently or 4 ranks in both Hide
                        and Listen.

                        Contrived, but there are benefits to grouping prereqs. I know there are
                        things that have optional prereqs... some prestige classes, I think, and
                        I know that there are other things in the game that have optional
                        prereqs (such as organizations from the _Path_ series).


                        Keith
                        --
                        Keith Davies
                        keith.davies@...

                        PCGen: <reaper/>, smartass
                        "You just can't argue with a moron. It's like handling Nuclear
                        waste. It's not good, it's not evil, but for Christ's sake, don't
                        get any on you!!" -- Chuck, PCGen mailing list
                      • Eric Beaudoin
                        ... Keep in mind that it has to work the home-made files and that we have to at least deal with the PCC RANK for pahse one otherwise the loader will all go
                        Message 11 of 21 , Mar 4 8:44 AM
                        • 0 Attachment
                          At 09:51 2003.03.04, Keith Davies wrote:
                          >On Tue, Mar 04, 2003 at 02:53:37AM -0500, Eric Beaudoin wrote:
                          >> Some thoughts
                          >>
                          >> At 01:54 2003.03.04, Keith Davies wrote:
                          >> >On Mon, Mar 03, 2003 at 10:10:48AM -0800, Keith Davies wrote:
                          >> >>
                          >> > 3. All files will identify their dependencies.
                          >> >
                          >> > In order to minimize unmatched references and incomplete links
                          >> > between data, all data files must identify the files that contain
                          >> > the elements they need. For instance, a file containing race
                          >> > definitions would almost certainly include class definitions to
                          >> > ensure that the preferred classes are found when the races are
                          >> > processed.
                          >> >
                          >> > It will be allowable for two files to be mutually dependent (though
                          >> > it's a good idea to avoid that when possible). The loader will be
                          >> > able to successfully deal with this.
                          >>
                          >> This is not present now and will be a bitch to generate automaticaly
                          >> from the existing files. Is this really needed for phase 1?
                          >
                          >Good point. I'd *like* it to be just so that the 'can't find /X/'
                          >problem goes away. OTOH, it isn't *strictly* required; I'll soften
                          >this.
                          >
                          >"In the future..."
                          >
                          >The main benefit to this is that it clearly and unambiguously defines
                          >the load order. If A requires B, then A indicates it and B will be
                          >loaded (or at least opened) before A continues loading. It'd be (at
                          >least theoretically, there are ways to prevent it) impossible to not
                          >have the requirements met.
                          >
                          >Tell you what, for the first part, how 'bout you just convert what's
                          >present to XML, and I'll build a small utility to identify and place the
                          >dependencies in the files. I think, once we get it to XML, this is will
                          >be pretty easy; find all the IDs used by each file, and where a file has
                          >external IDs in it list the files that contain that ID and slam them in.
                          >There're only about 600 files right now; it'll suck, but only need to be
                          >done once.
                          >
                          >Hmm... maybe not. I think I'll make the utility so it can remember the
                          >files to be inserted. Save me some work later.

                          Keep in mind that it has to work the home-made files and that we have to at least deal with the PCC RANK for pahse one otherwise the loader will all go beserk on us.


                          >> >XML Guidelines
                          >> >
                          >> > 4. All major elements will have XML IDs.
                          >> >
                          >> > Says it all, really. All major elements will have ID fields and
                          >> > values that comply to XML standards. This makes it possible to use
                          >> > third-party tools to process the data files. Also, by using static
                          >> > ID values we can insulate ourselves from spelling mistakes in names
                          >> > and relabeling things.
                          >> >
                          >> > A simple definition of XML IDs is that they begin with alphabetic
                          >> > characters, followed by some number of alphabetic or numerical
                          >> > characters or hyphen ('-') or period ('.'). (This is not a
                          >> > *strictly* accurate description but will suffice for our purposes.)
                          >> >
                          >> > IDs will be derived from the data being encoded. IDs will consist
                          >> > of at least two components, and possibly more.
                          >> >
                          >> > The first component will be the object type (*not* the data type).
                          >> > For instance, when encoding information about weapons the first
                          >> > component of these elements will be 'weapon', not 'equipment', even
                          >> > though the element type may be <equipment>. Part of preparing the
                          >> > translation instructions and schema for a LST file type will be
                          >> > identifying the component type. It is possible for a single LST
                          >> > file to produce multiple values for this first component.
                          >> >
                          >> > The second part will be the name of the object being described,
                          >> > modified to fit the specification above. The name will be changed
                          >> > to lowercase, all punctuation will be removed, and all spaces
                          >> > changed to hyphens.
                          >> >
                          >> > The third and following parts, if present, either differentiate
                          >> > between objects that would otherwise be the same or clarify the ID
                          >> > of the object.
                          >> >
                          >> > So, some specific examples:
                          >> >
                          >> > fireball => spell.fireball
                          >> > delayed blast fireball => spell.delayed-blast-fireball
                          >> > Melf's acid arrow => spell.melfs-acid-arrow
                          >> >
                          >> > Ranger => class.ranger
                          >> > Monte's Ranger => class.ranger.monte-cook
                          >> >
                          >> > We could instead use arbitrary ID values (for instance, initials of
                          >> > the person doing the data entry followed by a sequential number) --
                          >> > I could as effectively set the IDs above to kjd.18333, kjd.18334,
                          >> > kjd.18335. However, by encoding them as I have above it makes it
                          >> > easier to make links manually (I want the spell fireball... well,
                          >> > that's obvious, 'spell.fireball') and easier to troubleshoot links
                          >> > because it's clear what the ID is referring to.
                          >>
                          >> This is another one that will be hard to automaticaly convert. Keep in
                          >> mind that the converter will also have to work with the home made
                          >> file. The problem is that you take the TYPE instead of the NAME to
                          >> generate some IDs. Most object have multiple TYPEs, not just one. And
                          >> there is nothing in the .lst files right now that identify the "main"
                          >> type. The concept doesn't even exists at that level. Using file name
                          >> is not an option since it will break home-made files.
                          >
                          ><shrug> the above is the way I'd like the IDs constructed. I've found
                          >similar mechanisms to be very usable and useful in other projects. That
                          >said, I think if we just take the existing NAME and smash it into an XML
                          >ID that would be sufficient, probably base it on the file type. So, the
                          >examples above would become
                          >
                          > Fireball => spell.fireball
                          > Delayed Blast Fireball => spell.delayed-blast-fireball
                          > Melf's Acid Arrow => spell.melfs-acid-arrow
                          >
                          > Ranger => class.ranger
                          > Ranger (Monte Cook's) => class.ranger-monte-cooks
                          >
                          >$id = $name;
                          >$id =~ s/[^\w ]//g;
                          >$id =~ s/\s+/-/g;
                          >$id = "$filetype.$id"
                          $id = lc($id);

                          If you really want to build ID based on names, you will have to add the publisher in the equation otherwise we will not be able to get a unique ID. In other words, who get to use race.human? I beleive we need race.srd.human, race.msrd.human, race.kalamar.human, etc. If we add to the ID only when there is a collision, we will have weirdness when a new WotC products is turn into SRD and the one of the d20 publisher already has the name. This would also limit the ability of outside third party (like CMP) to produce their own files without having ID collision with the main distribution.

                          Names are not unique right now. In particular, there are SPELL with the same name for Wizard and Psionic and we're not talking about the same spell at all. We might have to resolve the unicity problem before we translate the .lst. We will need a function to resolve the reference in all the files for the translation and the function must return the correct reference every time.

                          Generating the IDs will turn to be an interesting problem.


                          >If nothing else, not having an ID will make life difficult, but
                          >
                          >1. it makes certain optimizations in code easier -- Scott figures we can
                          > probably get an order of magnitude performance gain by going to
                          > unambiguous IDs. Granted, this could be gained if we just establish
                          > clear rules for naming and names never, ever change, but that doesn't
                          > meet...
                          >2. XML specifies what characters may be present in IDs. If we build IDs
                          > that are valid XML IDs we make it possible to use them in third-party
                          > XML-specific tools.
                          >3. By using XML IDs we will be able to use these third-party tools to
                          > transform the XML data from one schema to another. This means that
                          > we won't have to use ad hoc Perl scripts to do it, we can just write
                          > a (relatively) simple XSLT script and run it over the data.

                          No Perl is suppose to be a good thing? :-)


                          >> > 6. The order of child elements will be fixed.
                          >> >
                          >> > Elements will appear in a consistent order within the parent. This
                          >> > makes it easier to validate the files. That is, if a major element
                          >> > allows child elements 'name', 'types', and 'cost' they will always
                          >> > appear in that order. If a child element is optional (such as
                          >> > 'cost' above) it might or might not be present, but if it is present
                          >> > it will follow 'types'.
                          >>
                          >> I really don't think this is a good idea. The fact that tags on the
                          >> lines are not order sensitive except when you use the same tag is a
                          >> good thing. Time and again, we reorganise the orders to make them
                          >> easier to read and new tags are seldom inserted at the right place the
                          >> first time around.
                          >>
                          >> This should be in the style guide but not inforce by the parser.
                          >> Forcing the order is like the Cobol comments that needs to be in
                          >> column 4, it will turn out to be a pain at some point.
                          >>
                          >> In conclusion: style should not be enforce by the parser.
                          >
                          >I think that *certain* fields should still have a fixed order. By
                          >putting all required fields in a fixed order, we can actually ensure
                          >that they are present using normal XML tools. If we have to check the
                          >presence of required children *after* loading -- writing ad hoc code to
                          >to do -- we add to the code that needs to be maintained. We'd be
                          >throwing away one of the key benefits -- automated, 'free' validation of
                          >the data. This does not strike me as a good idea.
                          >
                          >I think the set of required tags for most items is pretty short. I
                          >think we can gain the benefits I'm looking for by making their order
                          >fixed but the rest can float.
                          >
                          >> > 7. Order of child elements will be consistent between types.
                          >> >
                          >> > Where two major elements have the same child elements, those child
                          >> > elements will appear in the same order in both. Common child
                          >> > elements will be identified during this analysis and their common
                          >> > order determined.
                          >> >
                          >> > I expect we will take this opportunity to further globalize data
                          >> > elements. For instance, anything that can take prereqs will be able
                          >> > to take all prereqs, and -- unless it risks breaking the internal
                          >> > data model -- anything that can be applied can be applied by
                          >> > anything. For instance, if an existing LST data type can give a
                          >> > bonus at all, it will be able to give a bonus of any type, and I'd
                          >> > like to extend it to allow other kinds of changes (such as giving
                          >> > feats).
                          >> >
                          >> > As a result, I want to make some data types more or less generic.
                          >> > For instance, all bonus types will be defined and allowable anywhere
                          >> > any bonuses are allowed, prereqs will always behave the same way,
                          >> > and so on.
                          >>
                          >> Again, it might be a good thing style wise but it must not be enforce
                          >> by the parser.
                          >>
                          >> As for a specific order of childs from one data type to another,
                          >> experience as told us that it is not necessarely something we want.
                          >> But since style should not be enforce by the parser, it is something
                          >> that can be cleared out and thinker with over time :-).
                          >
                          >Actually, from above, let's soften this to required fields and common
                          >fields. I want to keep the validation ability of XML.

                          I feel very strongly againts enforcing fixed order of both the arguments and the childs. It's never a good idea to modify the language because of a tool's shortcoming. The tool will get better and can be improved.

                          The shortcoming can be metigated by having a separate tools to do extra syntax validation on the files so that users can test their files properly. Also, since we are talking about using persistance, the validation will eventually happen only when the files are changed.

                          Ppl who know XML are not expecting order to be important. The principal of least surprise is an important one.

                          BTW, I'm surprise that the mandantory arguments are not validate by the schema. This means that schema cannot be used to represent xhtml without adding external validation to it?

                          >> >Style Guidelines
                          >> >
                          >>
                          >> [snip.]
                          >>
                          >> > 12. Related game elements will be clearly associated.
                          >> >
                          >> > As much as is reasonable, related information will be kept together.
                          >> > It will *not* be necessary for a program loading data files to infer
                          >> > relationships between data elements.
                          >> >
                          >> > Things that are intrinsically part of a parent will be fully
                          >> > contained by that parent. Things that are related to another item
                          >> > will refer to the master by ID.
                          >> >
                          >> > Some specific examples:
                          >> >
                          >> > Class levels will be child elements of the class. Thus:
                          >> >
                          >> > <class id="class.wizard">
                          >> > <name>Wizard</name>
                          >> > <hit-die>4</hit-die>
                          >> > <levels>
                          >> > <level level="1">
                          >> > <add-feat ref="feat.scribe-scroll"/>
                          >> > </level>
                          >> > <level level="5">
                          >> > <add-feat><choose type="wizard"/></add-feat>
                          >> > </level>
                          >> > <level level="10">
                          >> > <add-feat><choose type="wizard"/></add-feat>
                          >> > </level>
                          >> > </levels>
                          >> > </class>
                          >> >
                          >> > Subclasses will not be child elements of the class. Thus:
                          >> >
                          >> > <class id="class.wizard.illusionist" master="class.wizard">
                          >> > <name>Illusionist</name>
                          >> > <hit-die>4</hit-die>
                          >> > <!-- identify barred schools; I don't know this yet -->
                          >> > <levels>
                          >> > <level level="1">
                          >> > <add-feat ref="feat.scribe-scroll"/>
                          >> > </level>
                          >> > <level level="5">
                          >> > <add-feat><choose type="wizard"/></add-feat>
                          >> > </level>
                          >> > <level level="10">
                          >> > <add-feat><choose type="wizard"/></add-feat>
                          >> > </level>
                          >> > </levels>
                          >> > </class>
                          >>
                          >> How do you link the class with the subclass then? Will each subclass
                          >> have to repeat the whole level progression section (which would be
                          >> bad)?
                          >
                          >Good point. Actually, the copy mechanism described above:
                          >
                          ><copy:class ref="class.wizard"
                          > id="class.illusionist"
                          > master="class.wizard">
                          > <name>Illusionist</name>
                          > <!-- identify barred schools; I don't know this yet -->
                          ></copy>
                          >
                          >Hmm... I like that. Simple.
                          >
                          >The link is driven from the child to the parent; this removes the need
                          >to modify the parent when more subclasses are added. For instance, IIRC
                          >_Path of Magic_ adds more variant Wizard classes; rather than MODding
                          >the Wizard class, we can just plug in these other classes.

                          Moding and Subclassing do not do the same thing. Mod change the original element and do not add new elements. Every Wizards are differents from then on. SUBCLASS was made with specialist in mind. You chose wizard but you can/have to chose a particular flavor of wizard.

                          COPY right now really copy the object in memory whereas SUBCLASS just add to the existhing object. Francly, I don't care about this diffence but I thought I'd mentionned it in case it make a difference for you.


                          >> > 13. Closely-related encoding elements will be grouped.
                          >> >
                          >> > Where there are multiple child elements of similar nature, they will
                          >> > be grouped under a superior element.
                          >> >
                          >> > Specific example:
                          >> >
                          >> > When encoding prerequisites, they will be grouped together as
                          >> > below (bogus example):
                          >> >
                          >> > <class id="class.assassin">
                          >> > <name>Assassin</name>
                          >> > <prereqs>
                          >> > <prebab value="3"/>
                          >> > <preskill ref="skill.move-silently" ranks="8"/>
                          >> > <prespecial>Must kill a sentient humanoid for the sole purpose
                          >> > of becoming an assassin.</prespecial>
                          >> > </prereqs>
                          >> > </class>
                          >> >
                          >> > This was also demonstrated above by the <levels> element.
                          >>
                          >> This seams like a cute thing when viewing the files in something like
                          >> Internet Explorer but not really needed. This means one extra pair of
                          >> delimeters to type. It also force us to put all the PRExxx tag
                          >> together and make vertical formatting of the files more difficult. I
                          >> would prefer 1 tag, 1 child.
                          >
                          >'vertical formatting is more difficult'? How so?

                          The columns will be large enough as they are, no need to get them larger if we need to. Vertical formatting might not be possible anyway so it's not a big point. That's actually one bad thing about the XML format, we will have to look at the data one record at a time instead of looking at tables like we used to.


                          >I've always considered prereqs, for example, to be closely enough
                          >related that we want them in one place. I don't want to be looking
                          >through the entire object to find all the prereqs. So, while XML does
                          >not technically require it and we could do without, I think it's a good
                          >idea for style reasons.

                          Let's not impose style in the language. They can be grouped togetter without adding the extra element.

                          >If there is strong enough dissent we can remove that, but I think there
                          >is sufficient benefit to its presence to justify it.
                          >
                          >> Not related to item 13 but I would have thought that name would have
                          >> been an argument, not a child. Each game entity has one and only one
                          >> name (it's the first column at the beginning of the line). I think
                          >> that would be a visual help for phase 1 since the name is the
                          >> reference that ppl are used to see right now in the .lst files and in
                          >> the GUI.
                          >
                          >I originally did this. However, there are a couple of attributes that
                          >apply only to name (nameispi, abbrev/abb (I really should look this
                          >up)); given that name is a data field and all other data fields are
                          >children, I think that, for consistency, we should make name another
                          >child.
                          >
                          >OTOH, since it *is* almost the only data field required by all data
                          >objects, that may be sufficient argument for making it an attribute.
                          >
                          >I'm willing to go either way on this.

                          Yea, this will become clearer when we start deciding what need to be an argument. As for PI and OGL, i beleive it's the whole element that is PI and/or OGL, not just the name. I could be wrong there.


                          >Keith
                          >--
                          >Keith Davies
                          >keith.davies@...
                          >
                          >PCGen: <reaper/>, smartass
                          > "You just can't argue with a moron. It's like handling Nuclear
                          > waste. It's not good, it's not evil, but for Christ's sake, don't
                          > get any on you!!" -- Chuck, PCGen mailing list
                          >
                          >
                          >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/

                          -----------------------------------------------------------
                          Éric "Space Monkey" Beaudoin
                          >> In space, no one can hear you sleep...
                          >> Camels to can climb trees (and sometime eat them)
                          <mailto:beaudoer@...>
                        • Keith Davies
                          Sorry for not clipping; I was in a hurry and didn t have time to find good places.... K. ... Good point. Are you sure, though, that using RANK will be needed
                          Message 12 of 21 , Mar 5 8:00 AM
                          • 0 Attachment
                            Sorry for not clipping; I was in a hurry and didn't have time to find
                            good places....

                            K.


                            On Tue, Mar 04, 2003 at 11:44:33AM -0500, Eric Beaudoin wrote:
                            > At 09:51 2003.03.04, Keith Davies wrote:
                            > >On Tue, Mar 04, 2003 at 02:53:37AM -0500, Eric Beaudoin wrote:
                            > >> Some thoughts
                            > >>
                            > >> At 01:54 2003.03.04, Keith Davies wrote:
                            > >> >On Mon, Mar 03, 2003 at 10:10:48AM -0800, Keith Davies wrote:
                            > >> >>
                            > >> > 3. All files will identify their dependencies.
                            > >> >
                            > >> > In order to minimize unmatched references and incomplete links
                            > >> > between data, all data files must identify the files that contain
                            > >> > the elements they need. For instance, a file containing race
                            > >> > definitions would almost certainly include class definitions to
                            > >> > ensure that the preferred classes are found when the races are
                            > >> > processed.
                            > >> >
                            > >> > It will be allowable for two files to be mutually dependent (though
                            > >> > it's a good idea to avoid that when possible). The loader will be
                            > >> > able to successfully deal with this.
                            > >>
                            > >> This is not present now and will be a bitch to generate automaticaly
                            > >> from the existing files. Is this really needed for phase 1?
                            > >
                            > >Good point. I'd *like* it to be just so that the 'can't find /X/'
                            > >problem goes away. OTOH, it isn't *strictly* required; I'll soften
                            > >this.
                            > >
                            > >"In the future..."
                            > >
                            > >The main benefit to this is that it clearly and unambiguously defines
                            > >the load order. If A requires B, then A indicates it and B will be
                            > >loaded (or at least opened) before A continues loading. It'd be (at
                            > >least theoretically, there are ways to prevent it) impossible to not
                            > >have the requirements met.
                            > >
                            > >Tell you what, for the first part, how 'bout you just convert what's
                            > >present to XML, and I'll build a small utility to identify and place the
                            > >dependencies in the files. I think, once we get it to XML, this is will
                            > >be pretty easy; find all the IDs used by each file, and where a file has
                            > >external IDs in it list the files that contain that ID and slam them in.
                            > >There're only about 600 files right now; it'll suck, but only need to be
                            > >done once.
                            > >
                            > >Hmm... maybe not. I think I'll make the utility so it can remember the
                            > >files to be inserted. Save me some work later.
                            >
                            > Keep in mind that it has to work the home-made files and that we have
                            > to at least deal with the PCC RANK for pahse one otherwise the loader
                            > will all go beserk on us.

                            Good point. Are you sure, though, that using RANK will be needed if the
                            file relationships are in place? The RANK mechanism is used to try to
                            ensure that, for example, the PHB is loaded before the splat books. If
                            the splat books have the PHB as a prereq, and prereqs are loaded before,
                            or at least in conjunction with (for those who insist on circular
                            references), the PHB will be loaded before the splat books. I don't see
                            a problem here.

                            I need to examine how loading works now, before I go any further. I
                            think that, unless I find something different, we'll continue with the
                            existing load semantics. They seem awkward, though.

                            > >> >XML Guidelines
                            > >> >
                            > >> > 4. All major elements will have XML IDs.
                            > >> >
                            > >> > Says it all, really. All major elements will have ID fields and
                            > >> > values that comply to XML standards. This makes it possible to use
                            > >> > third-party tools to process the data files. Also, by using static
                            > >> > ID values we can insulate ourselves from spelling mistakes in names
                            > >> > and relabeling things.
                            > >> >
                            > >> > A simple definition of XML IDs is that they begin with alphabetic
                            > >> > characters, followed by some number of alphabetic or numerical
                            > >> > characters or hyphen ('-') or period ('.'). (This is not a
                            > >> > *strictly* accurate description but will suffice for our purposes.)
                            > >> >
                            > >> > IDs will be derived from the data being encoded. IDs will consist
                            > >> > of at least two components, and possibly more.
                            > >> >
                            > >> > The first component will be the object type (*not* the data type).
                            > >> > For instance, when encoding information about weapons the first
                            > >> > component of these elements will be 'weapon', not 'equipment', even
                            > >> > though the element type may be <equipment>. Part of preparing the
                            > >> > translation instructions and schema for a LST file type will be
                            > >> > identifying the component type. It is possible for a single LST
                            > >> > file to produce multiple values for this first component.
                            > >> >
                            > >> > The second part will be the name of the object being described,
                            > >> > modified to fit the specification above. The name will be changed
                            > >> > to lowercase, all punctuation will be removed, and all spaces
                            > >> > changed to hyphens.
                            > >> >
                            > >> > The third and following parts, if present, either differentiate
                            > >> > between objects that would otherwise be the same or clarify the ID
                            > >> > of the object.
                            > >> >
                            > >> > So, some specific examples:
                            > >> >
                            > >> > fireball => spell.fireball
                            > >> > delayed blast fireball => spell.delayed-blast-fireball
                            > >> > Melf's acid arrow => spell.melfs-acid-arrow
                            > >> >
                            > >> > Ranger => class.ranger
                            > >> > Monte's Ranger => class.ranger.monte-cook
                            > >> >
                            > >> > We could instead use arbitrary ID values (for instance, initials of
                            > >> > the person doing the data entry followed by a sequential number) --
                            > >> > I could as effectively set the IDs above to kjd.18333, kjd.18334,
                            > >> > kjd.18335. However, by encoding them as I have above it makes it
                            > >> > easier to make links manually (I want the spell fireball... well,
                            > >> > that's obvious, 'spell.fireball') and easier to troubleshoot links
                            > >> > because it's clear what the ID is referring to.
                            > >>
                            > >> This is another one that will be hard to automaticaly convert. Keep in
                            > >> mind that the converter will also have to work with the home made
                            > >> file. The problem is that you take the TYPE instead of the NAME to
                            > >> generate some IDs. Most object have multiple TYPEs, not just one. And
                            > >> there is nothing in the .lst files right now that identify the "main"
                            > >> type. The concept doesn't even exists at that level. Using file name
                            > >> is not an option since it will break home-made files.
                            > >
                            > ><shrug> the above is the way I'd like the IDs constructed. I've found
                            > >similar mechanisms to be very usable and useful in other projects. That
                            > >said, I think if we just take the existing NAME and smash it into an XML
                            > >ID that would be sufficient, probably base it on the file type. So, the
                            > >examples above would become
                            > >
                            > > Fireball => spell.fireball
                            > > Delayed Blast Fireball => spell.delayed-blast-fireball
                            > > Melf's Acid Arrow => spell.melfs-acid-arrow
                            > >
                            > > Ranger => class.ranger
                            > > Ranger (Monte Cook's) => class.ranger-monte-cooks
                            > >
                            > >$id = $name;
                            > >$id =~ s/[^\w ]//g;
                            > >$id =~ s/\s+/-/g;
                            > >$id = "$filetype.$id"
                            > $id = lc($id);

                            whoops, right.

                            > If you really want to build ID based on names, you will have to add
                            > the publisher in the equation otherwise we will not be able to get a
                            > unique ID. In other words, who get to use race.human? I beleive we
                            > need race.srd.human, race.msrd.human, race.kalamar.human, etc. If we
                            > add to the ID only when there is a collision, we will have weirdness
                            > when a new WotC products is turn into SRD and the one of the d20
                            > publisher already has the name. This would also limit the ability of
                            > outside third party (like CMP) to produce their own files without
                            > having ID collision with the main distribution.

                            Originally I did that -- it was something like 'wotc.spell.fireball' or
                            'spell.wotc.fireball' (I forget which). I found that it generally
                            wasn't needed.

                            > Names are not unique right now. In particular, there are SPELL with
                            > the same name for Wizard and Psionic and we're not talking about the
                            > same spell at all. We might have to resolve the unicity problem before
                            > we translate the .lst. We will need a function to resolve the
                            > reference in all the files for the translation and the function must
                            > return the correct reference every time.

                            That would, of course, do it. Make all the names unique, at least
                            within a single data type, then create the ID as above. That makes
                            sense.

                            I still believe that we need unique ID values for all items loaded;
                            regardless of it being LST, XML, or RDBMS, this *is* a database, and
                            having unique IDs makes things much easier to work with.

                            > Generating the IDs will turn to be an interesting problem.

                            What I would probably do is automate key generation, store the keys in a
                            hash. Where we run into collisions, log the error to a file for
                            resolution.

                            Another option would be to treat each file individually, with no
                            awareness of other files whatsoever. It is possible and legitimate (if
                            really tacky) within the system for two elements to have the same ID.
                            Case in point, there is a feat that appears in two of the splat books
                            (forget what feat); both books would encode that feat according to the
                            text in each book (it may have changed between books) and both would
                            have the same ID assigned. When loading both splat books *the first
                            time* I expect the loader to notice this and toss up a dialog to the
                            user that basically says 'found two items with the same ID. Here they
                            are. What should I do?' and displays the two items. The user could
                            choose to use one of them, discard both, or maybe even put a new ID on
                            one of them... though I don't like that last option.

                            I don't know that we're going to have a lot of ID collision, though,
                            apart from these cases. What say we just go with the fully-automated
                            method described above, logging duplicated IDs as we go? Then we can
                            figure out what to do when we've got a better idea of the scope of the
                            problem.

                            Now, for home-created files, I suspect we'd do pretty much the same
                            thing. For the most part I expect that home-created files will have
                            truly custom stuff... and for that, we might want to go with the purely
                            arbitrary IDs -- start string and a number.

                            > >If nothing else, not having an ID will make life difficult, but
                            > >
                            > >1. it makes certain optimizations in code easier -- Scott figures we can
                            > > probably get an order of magnitude performance gain by going to
                            > > unambiguous IDs. Granted, this could be gained if we just establish
                            > > clear rules for naming and names never, ever change, but that doesn't
                            > > meet...
                            > >2. XML specifies what characters may be present in IDs. If we build IDs
                            > > that are valid XML IDs we make it possible to use them in third-party
                            > > XML-specific tools.
                            > >3. By using XML IDs we will be able to use these third-party tools to
                            > > transform the XML data from one schema to another. This means that
                            > > we won't have to use ad hoc Perl scripts to do it, we can just write
                            > > a (relatively) simple XSLT script and run it over the data.
                            >
                            > No Perl is suppose to be a good thing? :-)

                            Perl kicks ass. Don't get me wrong. However, there are simpler tools
                            for dealing with XML, especially transformations from one schema to
                            another.

                            > >> > 6. The order of child elements will be fixed.
                            > >> >
                            > >> > Elements will appear in a consistent order within the parent. This
                            > >> > makes it easier to validate the files. That is, if a major element
                            > >> > allows child elements 'name', 'types', and 'cost' they will always
                            > >> > appear in that order. If a child element is optional (such as
                            > >> > 'cost' above) it might or might not be present, but if it is present
                            > >> > it will follow 'types'.
                            > >>
                            > >> I really don't think this is a good idea. The fact that tags on the
                            > >> lines are not order sensitive except when you use the same tag is a
                            > >> good thing. Time and again, we reorganise the orders to make them
                            > >> easier to read and new tags are seldom inserted at the right place the
                            > >> first time around.
                            > >>
                            > >> This should be in the style guide but not inforce by the parser.
                            > >> Forcing the order is like the Cobol comments that needs to be in
                            > >> column 4, it will turn out to be a pain at some point.
                            > >>
                            > >> In conclusion: style should not be enforce by the parser.
                            > >
                            > >I think that *certain* fields should still have a fixed order. By
                            > >putting all required fields in a fixed order, we can actually ensure
                            > >that they are present using normal XML tools. If we have to check the
                            > >presence of required children *after* loading -- writing ad hoc code to
                            > >to do -- we add to the code that needs to be maintained. We'd be
                            > >throwing away one of the key benefits -- automated, 'free' validation of
                            > >the data. This does not strike me as a good idea.
                            > >
                            > >I think the set of required tags for most items is pretty short. I
                            > >think we can gain the benefits I'm looking for by making their order
                            > >fixed but the rest can float.
                            > >
                            > >> > 7. Order of child elements will be consistent between types.
                            > >> >
                            > >> > Where two major elements have the same child elements, those child
                            > >> > elements will appear in the same order in both. Common child
                            > >> > elements will be identified during this analysis and their common
                            > >> > order determined.
                            > >> >
                            > >> > I expect we will take this opportunity to further globalize data
                            > >> > elements. For instance, anything that can take prereqs will be able
                            > >> > to take all prereqs, and -- unless it risks breaking the internal
                            > >> > data model -- anything that can be applied can be applied by
                            > >> > anything. For instance, if an existing LST data type can give a
                            > >> > bonus at all, it will be able to give a bonus of any type, and I'd
                            > >> > like to extend it to allow other kinds of changes (such as giving
                            > >> > feats).
                            > >> >
                            > >> > As a result, I want to make some data types more or less generic.
                            > >> > For instance, all bonus types will be defined and allowable anywhere
                            > >> > any bonuses are allowed, prereqs will always behave the same way,
                            > >> > and so on.
                            > >>
                            > >> Again, it might be a good thing style wise but it must not be enforce
                            > >> by the parser.
                            > >>
                            > >> As for a specific order of childs from one data type to another,
                            > >> experience as told us that it is not necessarely something we want.
                            > >> But since style should not be enforce by the parser, it is something
                            > >> that can be cleared out and thinker with over time :-).
                            > >
                            > >Actually, from above, let's soften this to required fields and common
                            > >fields. I want to keep the validation ability of XML.
                            >
                            > I feel very strongly againts enforcing fixed order of both the
                            > arguments and the childs. It's never a good idea to modify the
                            > language because of a tool's shortcoming. The tool will get better and
                            > can be improved.

                            Attribute order cannot be enforced, but attribute presence can. Child
                            element order can, as can the presence as long as there is a required
                            order. This is using DTDs, which I am most familiar with. Using XSD
                            (XML Schema) apparently does give greater flexibility with validation,
                            and it supports namespaces, so I expect that we'll move to it or
                            something similar.

                            Schema's a pain in the ass, though.

                            > The shortcoming can be metigated by having a separate tools to do
                            > extra syntax validation on the files so that users can test their
                            > files properly. Also, since we are talking about using persistance,
                            > the validation will eventually happen only when the files are changed.

                            Meh, don't worry about it. We'll just mark ordinality ranges (min and
                            max allowed/required) and be done with it. If the data isn't present,
                            the item is not legitimate and will be rejected, but we can allow
                            processing to continue. I expect to need this later anyway when we go
                            to the next stage.

                            Okay, I changed my mind. Order is not required, but ordinality must be
                            specified and followed. The loader will deal with determining validity
                            of the elements.

                            > Ppl who know XML are not expecting order to be important. The
                            > principal of least surprise is an important one.

                            Really? I've always found XML with strict ordering requirements easier
                            to use simply because, for each element, it's children are easy to
                            predict.

                            > BTW, I'm surprise that the mandantory arguments are not validate by
                            > the schema. This means that schema cannot be used to represent xhtml
                            > without adding external validation to it?

                            I've never used XHTML. I understood that it is simply HTML made
                            XML-compliant.

                            > >> >Style Guidelines
                            > >> >
                            > >>
                            > >> [snip.]
                            > >>
                            > >> > 12. Related game elements will be clearly associated.
                            > >> >
                            > >> > As much as is reasonable, related information will be kept together.
                            > >> > It will *not* be necessary for a program loading data files to infer
                            > >> > relationships between data elements.
                            > >> >
                            > >> > Things that are intrinsically part of a parent will be fully
                            > >> > contained by that parent. Things that are related to another item
                            > >> > will refer to the master by ID.
                            > >> >
                            > >> > Some specific examples:
                            > >> >
                            > >> > Class levels will be child elements of the class. Thus:
                            > >> >
                            > >> > <class id="class.wizard">
                            > >> > <name>Wizard</name>
                            > >> > <hit-die>4</hit-die>
                            > >> > <levels>
                            > >> > <level level="1">
                            > >> > <add-feat ref="feat.scribe-scroll"/>
                            > >> > </level>
                            > >> > <level level="5">
                            > >> > <add-feat><choose type="wizard"/></add-feat>
                            > >> > </level>
                            > >> > <level level="10">
                            > >> > <add-feat><choose type="wizard"/></add-feat>
                            > >> > </level>
                            > >> > </levels>
                            > >> > </class>
                            > >> >
                            > >> > Subclasses will not be child elements of the class. Thus:
                            > >> >
                            > >> > <class id="class.wizard.illusionist" master="class.wizard">
                            > >> > <name>Illusionist</name>
                            > >> > <hit-die>4</hit-die>
                            > >> > <!-- identify barred schools; I don't know this yet -->
                            > >> > <levels>
                            > >> > <level level="1">
                            > >> > <add-feat ref="feat.scribe-scroll"/>
                            > >> > </level>
                            > >> > <level level="5">
                            > >> > <add-feat><choose type="wizard"/></add-feat>
                            > >> > </level>
                            > >> > <level level="10">
                            > >> > <add-feat><choose type="wizard"/></add-feat>
                            > >> > </level>
                            > >> > </levels>
                            > >> > </class>
                            > >>
                            > >> How do you link the class with the subclass then? Will each subclass
                            > >> have to repeat the whole level progression section (which would be
                            > >> bad)?
                            > >
                            > >Good point. Actually, the copy mechanism described above:
                            > >
                            > ><copy:class ref="class.wizard"
                            > > id="class.illusionist"
                            > > master="class.wizard">
                            > > <name>Illusionist</name>
                            > > <!-- identify barred schools; I don't know this yet -->
                            > ></copy:class>
                            > >
                            > >Hmm... I like that. Simple.
                            > >
                            > >The link is driven from the child to the parent; this removes the need
                            > >to modify the parent when more subclasses are added. For instance, IIRC
                            > >_Path of Magic_ adds more variant Wizard classes; rather than MODding
                            > >the Wizard class, we can just plug in these other classes.
                            >
                            > Moding and Subclassing do not do the same thing. Mod change the
                            > original element and do not add new elements. Every Wizards are
                            > differents from then on. SUBCLASS was made with specialist in mind.
                            > You chose wizard but you can/have to chose a particular flavor of
                            > wizard.

                            It can be used for other purposes, though. I can see subraces (various
                            flavors of elf or dwarf, subskills (like Knowledge, for instance), and
                            so on. What say we have a namespace 'sub' that creates a subordinate
                            copy of an identified element then applies changes to it? It will
                            behave much like copy but more accurately describes what is happening
                            and, incidentally, makes it easier to identify and change later on if we
                            decide to?

                            So, the example above would be

                            <sub:class ref="class.wizard"
                            id="class.illusionist"
                            master="class.wizard">
                            <name>Illusionist</name>
                            <!-- identify barred schools; I don't know this yet -->
                            </sub:class>

                            Makes it clear that it is closely related to the parent, gives us the
                            ability to sub... um, create a subelement of more things and provides an
                            interface consistent with the thing being subbed.

                            > COPY right now really copy the object in memory whereas SUBCLASS just
                            > add to the existhing object. Francly, I don't care about this diffence
                            > but I thought I'd mentionned it in case it make a difference for you.

                            So... what use is COPY, then? I don't think I see the benefit to just
                            duplicating something in memory.

                            > >> > 13. Closely-related encoding elements will be grouped.
                            > >> >
                            > >> > Where there are multiple child elements of similar nature, they will
                            > >> > be grouped under a superior element.
                            > >> >
                            > >> > Specific example:
                            > >> >
                            > >> > When encoding prerequisites, they will be grouped together as
                            > >> > below (bogus example):
                            > >> >
                            > >> > <class id="class.assassin">
                            > >> > <name>Assassin</name>
                            > >> > <prereqs>
                            > >> > <prebab value="3"/>
                            > >> > <preskill ref="skill.move-silently" ranks="8"/>
                            > >> > <prespecial>Must kill a sentient humanoid for the sole purpose
                            > >> > of becoming an assassin.</prespecial>
                            > >> > </prereqs>
                            > >> > </class>
                            > >> >
                            > >> > This was also demonstrated above by the <levels> element.
                            > >>
                            > >> This seams like a cute thing when viewing the files in something like
                            > >> Internet Explorer but not really needed. This means one extra pair of
                            > >> delimeters to type. It also force us to put all the PRExxx tag
                            > >> together and make vertical formatting of the files more difficult. I
                            > >> would prefer 1 tag, 1 child.
                            > >
                            > >'vertical formatting is more difficult'? How so?
                            >
                            > The columns will be large enough as they are, no need to get them
                            > larger if we need to. Vertical formatting might not be possible anyway
                            > so it's not a big point. That's actually one bad thing about the XML
                            > format, we will have to look at the data one record at a time instead
                            > of looking at tables like we used to.

                            Inside the program it'll still be loaded into tables. We don't have
                            time to make changes of the kind of scope needed to change that.

                            > >I've always considered prereqs, for example, to be closely enough
                            > >related that we want them in one place. I don't want to be looking
                            > >through the entire object to find all the prereqs. So, while XML does
                            > >not technically require it and we could do without, I think it's a good
                            > >idea for style reasons.
                            >
                            > Let's not impose style in the language. They can be grouped togetter
                            > without adding the extra element.

                            I think there are sufficient benefits to include the parent element.

                            > >If there is strong enough dissent we can remove that, but I think there
                            > >is sufficient benefit to its presence to justify it.
                            > >
                            > >> Not related to item 13 but I would have thought that name would have
                            > >> been an argument, not a child. Each game entity has one and only one
                            > >> name (it's the first column at the beginning of the line). I think
                            > >> that would be a visual help for phase 1 since the name is the
                            > >> reference that ppl are used to see right now in the .lst files and in
                            > >> the GUI.
                            > >
                            > >I originally did this. However, there are a couple of attributes that
                            > >apply only to name (nameispi, abbrev/abb (I really should look this
                            > >up)); given that name is a data field and all other data fields are
                            > >children, I think that, for consistency, we should make name another
                            > >child.
                            > >
                            > >OTOH, since it *is* almost the only data field required by all data
                            > >objects, that may be sufficient argument for making it an attribute.
                            > >
                            > >I'm willing to go either way on this.
                            >
                            > Yea, this will become clearer when we start deciding what need to be
                            > an argument. As for PI and OGL, i beleive it's the whole element that
                            > is PI and/or OGL, not just the name. I could be wrong there.

                            I saw NAMEISPI and DESCISPI somewhere (the tag doco, I think), but I
                            didn't notice them in the line/tag doco you sent me the other day. It
                            may be that they are not present in the data, in which case we might
                            consider their removal and just put a 'ispi' attribute at the top of the
                            game data description. The entire object or nothing, simple.


                            Keith
                            --
                            Keith Davies
                            keith.davies@...

                            PCGen: <reaper/>, smartass
                            "You just can't argue with a moron. It's like handling Nuclear
                            waste. It's not good, it's not evil, but for Christ's sake, don't
                            get any on you!!" -- Chuck, PCGen mailing list
                          • Devon Jones
                            ... [Snip] ... This opens up one fantastic thing. I m sick and tired of my players loading up something like oriental adventures, and as a result, all
                            Message 13 of 21 , Mar 5 9:41 AM
                            • 0 Attachment
                              Keith Davies wrote:

                              >On Mon, Mar 03, 2003 at 10:10:48AM -0800, Keith Davies wrote:
                              >
                              >
                              >>I'll post -- tonight, I think -- guidelines on converting LST syntax to
                              >>XML syntax. For the most part, because we're making such minor changes
                              >>to semantics, the changes will be obvious. There are some non-obvious
                              >>things I want done, though, so I'll describe them.
                              >>
                              >>
                              >
                              >Okay, I'm starting to go a little incoherent, so I'll post this now.
                              >The example at the bottom is incomplete; I'll update it tomorrow but I
                              >want to get what I got, out.
                              >
                              >Please read, consider, and discuss the guidelines below. I have also
                              >uploaded them to the Files area in the 20030303 LST -> XML folder.
                              >
                              >Keith
                              >
                              >
                              >In an effort to reduce the degree and scope of change in the data model
                              >when converting to XML, we will be doing a more or less direct
                              >translation of the existing LST tags to XML elements and attributes.
                              >There are certain guidelines to be followed in doing this translation.
                              >This document contains those guidelines and the reason behind them.
                              >
                              >For those unfamiliar with XML, a document describing references to XML
                              >information will be written. Don't worry if you don't understand some
                              >of the technical information about XML below, it will become clear
                              >later.
                              >
                              >FILE-SPECIFIC GUIDELINES
                              >
                              >
                              >
                              [Snip]

                              > 3. All files will identify their dependencies.
                              >
                              > In order to minimize unmatched references and incomplete links
                              > between data, all data files must identify the files that contain
                              > the elements they need. For instance, a file containing race
                              > definitions would almost certainly include class definitions to
                              > ensure that the preferred classes are found when the races are
                              > processed.
                              >
                              > It will be allowable for two files to be mutually dependent (though
                              > it's a good idea to avoid that when possible). The loader will be
                              > able to successfully deal with this.
                              >
                              This opens up one fantastic thing. I'm sick and tired of my players
                              loading up something like oriental adventures, and as a result, all
                              characters modified in that session now depend on OA *Rolls Eyes*. Even
                              if we don't export all the data with every .pcg, we have the capability
                              with this and the finer grained dependancy stuff you talk about in later
                              messages to be accurate about what sources a character *really* depends
                              on - not just a list of what files were loaded when the character was
                              created.

                              [Snip]

                              >XML Guidelines
                              >
                              > 4. All major elements will have XML IDs.
                              >
                              > Says it all, really. All major elements will have ID fields and
                              > values that comply to XML standards. This makes it possible to use
                              > third-party tools to process the data files. Also, by using static
                              > ID values we can insulate ourselves from spelling mistakes in names
                              > and relabeling things.
                              >
                              > A simple definition of XML IDs is that they begin with alphabetic
                              > characters, followed by some number of alphabetic or numerical
                              > characters or hyphen ('-') or period ('.'). (This is not a
                              > *strictly* accurate description but will suffice for our purposes.)
                              >
                              > IDs will be derived from the data being encoded. IDs will consist
                              > of at least two components, and possibly more.
                              >
                              > The first component will be the object type (*not* the data type).
                              > For instance, when encoding information about weapons the first
                              > component of these elements will be 'weapon', not 'equipment', even
                              > though the element type may be <equipment>. Part of preparing the
                              > translation instructions and schema for a LST file type will be
                              > identifying the component type. It is possible for a single LST
                              > file to produce multiple values for this first component.
                              >
                              > The second part will be the name of the object being described,
                              > modified to fit the specification above. The name will be changed
                              > to lowercase, all punctuation will be removed, and all spaces
                              > changed to hyphens.
                              >
                              > The third and following parts, if present, either differentiate
                              > between objects that would otherwise be the same or clarify the ID
                              > of the object.
                              >
                              > So, some specific examples:
                              >
                              > fireball => spell.fireball
                              > delayed blast fireball => spell.delayed-blast-fireball
                              > Melf's acid arrow => spell.melfs-acid-arrow
                              >
                              > Ranger => class.ranger
                              > Monte's Ranger => class.ranger.monte-cook
                              >
                              I know this is a detail that will be not be important for some time, but
                              I think it's important to at least point it out - with things like
                              Melf's Acid Arrow, we should use the SRD name (Acid Arrow), and let the
                              CMP datasets .MOD Acid Arrow to add the PI.

                              Basically what I intend from this is that none of the IDs should have PI
                              in them - so that we don't get sued ;)

                              [Snip]

                              > 13. Closely-related encoding elements will be grouped.
                              >
                              > Where there are multiple child elements of similar nature, they will
                              > be grouped under a superior element.
                              >
                              > Specific example:
                              >
                              > When encoding prerequisites, they will be grouped together as
                              > below (bogus example):
                              >
                              > <class id="class.assassin">
                              > <name>Assassin</name>
                              > <prereqs>
                              > <prebab value="3"/>
                              > <preskill ref="skill.move-silently" ranks="8"/>
                              > <prespecial>Must kill a sentient humanoid for the sole purpose
                              > of becoming an assassin.</prespecial>
                              > </prereqs>
                              > </class>
                              >
                              > This was also demonstrated above by the <levels> element.
                              >
                              >
                              This is fantastic, as it can eventually lead to much more sophesticated
                              loading and parsing - such as that mentioned in a different message
                              relating to OR with prerequisites.

                              This should probably be used for most elements. Prereqs, Bonuses,
                              etc. this will IMHO make things *WAY* more supportable.

                              [Snip]

                              >Examples
                              >
                              > Here are some examples of encoded data elements; they should give an
                              > indication of what the translations should provide.
                              >
                              > Domain:
                              >
                              > <domain id="domain.name" ispi="">
                              > <name ispi="">Name</name>
                              > <desc ispi="">Brief description</desc>
                              > <prereqs>
                              > <!-- all prereq types; I show only those present in CVS data -->
                              > <prealign />
                              > <preclass />
                              > </prereqs>
                              > <bonuses>
                              > <bonus-skill />
                              > <bonus-var />
                              > </bonuses>
                              > </domain>
                              >
                              >
                              This one brings up one if my serious irritations with the existant LST
                              paradigm.
                              Some books, like Legends and Lore:Spells and Spellcraft offer alternate
                              spells for Domains. In my personal campaign lst files, I do a whole
                              heck of alot of this - but there is no way to *CLEAR* other elements out
                              of the DOMAINS: tag for spells - so then players end up having 2 spells
                              for some levels in their domains, and I basically just have to tell them
                              to ignore the wrong ones (or remove them from known spells). I *REALLY*
                              think we need a way to in <mod:whatever> tags to not just redeclare
                              things (because with many things, like the CLASSES: tag for spells, you
                              *want* them to be additive, instead of clearing the whole list) but be
                              able to explicitly Replace, Erase, Add or Subtract from any tag that the
                              <mod:whatever> is modifying, so long as in doing so it doesn't break the
                              rules for that particular tag (like erase the name).

                              Soulcatcher
                              (Devon Jones)
                              PCGen Code Monkey
                            • Eric Beaudoin
                              ... [snip.] ... The RANK is usefull to see which .MOD gets apply before which other .MOD. It also (I beleive) help resolve if a .COPY copy the .MOD object or
                              Message 14 of 21 , Mar 5 10:24 PM
                              • 0 Attachment
                                At 11:00 2003.03.05, Keith Davies wrote:
                                >Sorry for not clipping; I was in a hurry and didn't have time to find
                                >good places....
                                >
                                >K.

                                [snip.]

                                >>
                                >> Keep in mind that it has to work the home-made files and that we have
                                >> to at least deal with the PCC RANK for pahse one otherwise the loader
                                >> will all go beserk on us.
                                >
                                >Good point. Are you sure, though, that using RANK will be needed if the
                                >file relationships are in place? The RANK mechanism is used to try to
                                >ensure that, for example, the PHB is loaded before the splat books. If
                                >the splat books have the PHB as a prereq, and prereqs are loaded before,
                                >or at least in conjunction with (for those who insist on circular
                                >references), the PHB will be loaded before the splat books. I don't see
                                >a problem here.
                                >
                                >I need to examine how loading works now, before I go any further. I
                                >think that, unless I find something different, we'll continue with the
                                >existing load semantics. They seem awkward, though.

                                The RANK is usefull to see which .MOD gets apply before which other .MOD. It also (I beleive) help resolve if a .COPY copy the .MOD object or the original.


                                [snip.]

                                >> If you really want to build ID based on names, you will have to add
                                >> the publisher in the equation otherwise we will not be able to get a
                                >> unique ID. In other words, who get to use race.human? I beleive we
                                >> need race.srd.human, race.msrd.human, race.kalamar.human, etc. If we
                                >> add to the ID only when there is a collision, we will have weirdness
                                >> when a new WotC products is turn into SRD and the one of the d20
                                >> publisher already has the name. This would also limit the ability of
                                >> outside third party (like CMP) to produce their own files without
                                >> having ID collision with the main distribution.
                                >
                                >Originally I did that -- it was something like 'wotc.spell.fireball' or
                                >'spell.wotc.fireball' (I forget which). I found that it generally
                                >wasn't needed.

                                >> Names are not unique right now. In particular, there are SPELL with
                                >> the same name for Wizard and Psionic and we're not talking about the
                                >> same spell at all. We might have to resolve the unicity problem before
                                >> we translate the .lst. We will need a function to resolve the
                                >> reference in all the files for the translation and the function must
                                >> return the correct reference every time.
                                >
                                >That would, of course, do it. Make all the names unique, at least
                                >within a single data type, then create the ID as above. That makes
                                >sense.
                                >
                                >I still believe that we need unique ID values for all items loaded;
                                >regardless of it being LST, XML, or RDBMS, this *is* a database, and
                                >having unique IDs makes things much easier to work with.

                                I'd like use the name and use it as unique key (and forget the ID altogether).

                                >> Generating the IDs will turn to be an interesting problem.
                                >
                                >What I would probably do is automate key generation, store the keys in a
                                >hash. Where we run into collisions, log the error to a file for
                                >resolution.
                                >
                                >Another option would be to treat each file individually, with no
                                >awareness of other files whatsoever. It is possible and legitimate (if
                                >really tacky) within the system for two elements to have the same ID.
                                >Case in point, there is a feat that appears in two of the splat books
                                >(forget what feat); both books would encode that feat according to the
                                >text in each book (it may have changed between books) and both would
                                >have the same ID assigned. When loading both splat books *the first
                                >time* I expect the loader to notice this and toss up a dialog to the
                                >user that basically says 'found two items with the same ID. Here they
                                >are. What should I do?' and displays the two items. The user could
                                >choose to use one of them, discard both, or maybe even put a new ID on
                                >one of them... though I don't like that last option.
                                >
                                >I don't know that we're going to have a lot of ID collision, though,
                                >apart from these cases. What say we just go with the fully-automated
                                >method described above, logging duplicated IDs as we go? Then we can
                                >figure out what to do when we've got a better idea of the scope of the
                                >problem.
                                >
                                >Now, for home-created files, I suspect we'd do pretty much the same
                                >thing. For the most part I expect that home-created files will have
                                >truly custom stuff... and for that, we might want to go with the purely
                                >arbitrary IDs -- start string and a number.

                                I beleive many are .MOD and even .COPY so they reference an item and mke little modification to it (e.g. adding the DESC: tag to feats our the page number with SOURCEPAGE: ).

                                We must also think that this XML definition might becaume a de-facto standard. We should make sure that application outside of the PCGEN project can work with the data (basicaly, we should not think only of ourselves). So, with that in mind, I wonder how we would convert a Jamis Buck's NPC to our format? It won't have IDs. The only option I see if we really needs the IDs is to generate them from other arguments that are mandantory. That way, when we import data from somewhere else, we'll be able to produce the ID.

                                >> >If nothing else, not having an ID will make life difficult, but
                                >> >
                                >> >1. it makes certain optimizations in code easier -- Scott figures we can
                                >> > probably get an order of magnitude performance gain by going to
                                >> > unambiguous IDs. Granted, this could be gained if we just establish
                                >> > clear rules for naming and names never, ever change, but that doesn't
                                >> > meet...
                                >> >2. XML specifies what characters may be present in IDs. If we build IDs
                                >> > that are valid XML IDs we make it possible to use them in third-party
                                >> > XML-specific tools.
                                >> >3. By using XML IDs we will be able to use these third-party tools to
                                >> > transform the XML data from one schema to another. This means that
                                >> > we won't have to use ad hoc Perl scripts to do it, we can just write
                                >> > a (relatively) simple XSLT script and run it over the data.
                                >>
                                >> No Perl is suppose to be a good thing? :-)
                                >
                                >Perl kicks ass. Don't get me wrong. However, there are simpler tools
                                >for dealing with XML, especially transformations from one schema to
                                >another.

                                I found it funny that you thought you had to respond to that one ;-)



                                [snip.]


                                >> I feel very strongly againts enforcing fixed order of both the
                                >> arguments and the childs. It's never a good idea to modify the
                                >> language because of a tool's shortcoming. The tool will get better and
                                >> can be improved.
                                >
                                >Attribute order cannot be enforced, but attribute presence can. Child
                                >element order can, as can the presence as long as there is a required
                                >order. This is using DTDs, which I am most familiar with. Using XSD
                                >(XML Schema) apparently does give greater flexibility with validation,
                                >and it supports namespaces, so I expect that we'll move to it or
                                >something similar.
                                >
                                >Schema's a pain in the ass, though.

                                I never thought we wanted to use DTD since you've been talking about schemas all along. I thought we wanted to stay away of it because it's not very flexible and do not allow to do much data type validation.

                                Since you don't like XML Schema, did you look into the alternatives: RELAX-NG or Schematron ?


                                >I've never used XHTML. I understood that it is simply HTML made
                                >XML-compliant.

                                More or less yes. One thing for sure, there are no enforce order with it.


                                >> >> >Style Guidelines
                                >> >> >
                                >> >>
                                >> >> [snip.]
                                >> >>
                                >> >> > 12. Related game elements will be clearly associated.
                                >> >> >
                                >> >> > As much as is reasonable, related information will be kept together.
                                >> >> > It will *not* be necessary for a program loading data files to infer
                                >> >> > relationships between data elements.
                                >> >> >
                                >> >> > Things that are intrinsically part of a parent will be fully
                                >> >> > contained by that parent. Things that are related to another item
                                >> >> > will refer to the master by ID.
                                >> >> >
                                >> >> > Some specific examples:
                                >> >> >
                                >> >> > Class levels will be child elements of the class. Thus:
                                >> >> >
                                >> >> > <class id="class.wizard">
                                >> >> > <name>Wizard</name>
                                >> >> > <hit-die>4</hit-die>
                                >> >> > <levels>
                                >> >> > <level level="1">
                                >> >> > <add-feat ref="feat.scribe-scroll"/>
                                >> >> > </level>
                                >> >> > <level level="5">
                                >> >> > <add-feat><choose type="wizard"/></add-feat>
                                >> >> > </level>
                                >> >> > <level level="10">
                                >> >> > <add-feat><choose type="wizard"/></add-feat>
                                >> >> > </level>
                                >> >> > </levels>
                                >> >> > </class>
                                >> >> >
                                >> >> > Subclasses will not be child elements of the class. Thus:
                                >> >> >
                                >> >> > <class id="class.wizard.illusionist" master="class.wizard">
                                >> >> > <name>Illusionist</name>
                                >> >> > <hit-die>4</hit-die>
                                >> >> > <!-- identify barred schools; I don't know this yet -->
                                >> >> > <levels>
                                >> >> > <level level="1">
                                >> >> > <add-feat ref="feat.scribe-scroll"/>
                                >> >> > </level>
                                >> >> > <level level="5">
                                >> >> > <add-feat><choose type="wizard"/></add-feat>
                                >> >> > </level>
                                >> >> > <level level="10">
                                >> >> > <add-feat><choose type="wizard"/></add-feat>
                                >> >> > </level>
                                >> >> > </levels>
                                >> >> > </class>
                                >> >>
                                >> >> How do you link the class with the subclass then? Will each subclass
                                >> >> have to repeat the whole level progression section (which would be
                                >> >> bad)?
                                >> >
                                >> >Good point. Actually, the copy mechanism described above:
                                >> >
                                >> ><copy:class ref="class.wizard"
                                >> > id="class.illusionist"
                                >> > master="class.wizard">
                                >> > <name>Illusionist</name>
                                >> > <!-- identify barred schools; I don't know this yet -->
                                >> ></copy:class>
                                >> >
                                >> >Hmm... I like that. Simple.
                                >> >
                                >> >The link is driven from the child to the parent; this removes the need
                                >> >to modify the parent when more subclasses are added. For instance, IIRC
                                >> >_Path of Magic_ adds more variant Wizard classes; rather than MODding
                                >> >the Wizard class, we can just plug in these other classes.
                                >>
                                >> Moding and Subclassing do not do the same thing. Mod change the
                                >> original element and do not add new elements. Every Wizards are
                                >> differents from then on. SUBCLASS was made with specialist in mind.
                                >> You chose wizard but you can/have to chose a particular flavor of
                                >> wizard.
                                >
                                >It can be used for other purposes, though. I can see subraces (various
                                >flavors of elf or dwarf, subskills (like Knowledge, for instance), and
                                >so on. What say we have a namespace 'sub' that creates a subordinate
                                >copy of an identified element then applies changes to it? It will
                                >behave much like copy but more accurately describes what is happening
                                >and, incidentally, makes it easier to identify and change later on if we
                                >decide to?

                                Yea, there is another thing with subclassing though, you narmally have a chooser that pop to let you select which sub-class you use. In the case of the Specialist Wizard, you can choose the Wizard or one of the specialist and then a second chooser appear (if you chosed the a specialist) to let you choose the schools you won't get. In the case of the Psionics, you need to choose a speciality (there is no base psy). So, right now SUBCLASS most internaly be very deeply link to the CLASS. We need a code monkey to tell us for sure I guess.

                                The race are done with template right now. Sub for race is a good idea but it will need to happen after phase 1 or it would change internal.


                                >So, the example above would be
                                >
                                > <sub:class ref="class.wizard"
                                > id="class.illusionist"
                                > master="class.wizard">
                                > <name>Illusionist</name>
                                > <!-- identify barred schools; I don't know this yet -->
                                > </sub:class>
                                >
                                >Makes it clear that it is closely related to the parent, gives us the
                                >ability to sub... um, create a subelement of more things and provides an
                                >interface consistent with the thing being subbed.
                                >
                                >> COPY right now really copy the object in memory whereas SUBCLASS just
                                >> add to the existhing object. Francly, I don't care about this diffence
                                >> but I thought I'd mentionned it in case it make a difference for you.
                                >
                                >So... what use is COPY, then? I don't think I see the benefit to just
                                >duplicating something in memory.

                                New Name.COPY=Original Name NEWTAG:newvalue ...

                                The .COPY create a new object that you then modify. The original object stays in and can also be accessed. .MOD modify the original object.

                                The is also a syntax to remove an object (.REMOVE I think).


                                >> >> > 13. Closely-related encoding elements will be grouped.
                                >> >> >
                                >> >> > Where there are multiple child elements of similar nature, they will
                                >> >> > be grouped under a superior element.
                                >> >> >
                                >> >> > Specific example:
                                >> >> >
                                >> >> > When encoding prerequisites, they will be grouped together as
                                >> >> > below (bogus example):
                                >> >> >
                                >> >> > <class id="class.assassin">
                                >> >> > <name>Assassin</name>
                                >> >> > <prereqs>
                                >> >> > <prebab value="3"/>
                                >> >> > <preskill ref="skill.move-silently" ranks="8"/>
                                >> >> > <prespecial>Must kill a sentient humanoid for the sole purpose
                                >> >> > of becoming an assassin.</prespecial>
                                >> >> > </prereqs>
                                >> >> > </class>
                                >> >> >
                                >> >> > This was also demonstrated above by the <levels> element.
                                >> >>
                                >> >> This seams like a cute thing when viewing the files in something like
                                >> >> Internet Explorer but not really needed. This means one extra pair of
                                >> >> delimeters to type. It also force us to put all the PRExxx tag
                                >> >> together and make vertical formatting of the files more difficult. I
                                >> >> would prefer 1 tag, 1 child.
                                >> >
                                >> >'vertical formatting is more difficult'? How so?
                                >>
                                >> The columns will be large enough as they are, no need to get them
                                >> larger if we need to. Vertical formatting might not be possible anyway
                                >> so it's not a big point. That's actually one bad thing about the XML
                                >> format, we will have to look at the data one record at a time instead
                                >> of looking at tables like we used to.
                                >
                                >Inside the program it'll still be loaded into tables. We don't have
                                >time to make changes of the kind of scope needed to change that.

                                I'm talking about the human looking at the data files. He looks at the books and see tables. Right now, he looks at the files and also see tables. It would have been nice to find a way to format our XML in table.

                                It will a long time before having an editor that his good enough to convince the main data monkeys to move away from their favorite text editor. We should try to make a format that will be workable. If you are not convince about this, just check the number of Code Monkeys that still prefer using a standard text editor for Java (starting with Bryan) even though the Java EDI have become quite mature and well supported.


                                >> >I've always considered prereqs, for example, to be closely enough
                                >> >related that we want them in one place. I don't want to be looking
                                >> >through the entire object to find all the prereqs. So, while XML does
                                >> >not technically require it and we could do without, I think it's a good
                                >> >idea for style reasons.
                                >>
                                >> Let's not impose style in the language. They can be grouped togetter
                                >> without adding the extra element.
                                >
                                >I think there are sufficient benefits to include the parent element.

                                I guess we agree to disagree. Since there is no grouping of family of tags right now with the .lst files, I suggest we pospone this debate for phase 3.

                                >> >If there is strong enough dissent we can remove that, but I think there
                                >> >is sufficient benefit to its presence to justify it.
                                >> >
                                >> >> Not related to item 13 but I would have thought that name would have
                                >> >> been an argument, not a child. Each game entity has one and only one
                                >> >> name (it's the first column at the beginning of the line). I think
                                >> >> that would be a visual help for phase 1 since the name is the
                                >> >> reference that ppl are used to see right now in the .lst files and in
                                >> >> the GUI.
                                >> >
                                >> >I originally did this. However, there are a couple of attributes that
                                >> >apply only to name (nameispi, abbrev/abb (I really should look this
                                >> >up)); given that name is a data field and all other data fields are
                                >> >children, I think that, for consistency, we should make name another
                                >> >child.
                                >> >
                                >> >OTOH, since it *is* almost the only data field required by all data
                                >> >objects, that may be sufficient argument for making it an attribute.
                                >> >
                                >> >I'm willing to go either way on this.
                                >>
                                >> Yea, this will become clearer when we start deciding what need to be
                                >> an argument. As for PI and OGL, i beleive it's the whole element that
                                >> is PI and/or OGL, not just the name. I could be wrong there.
                                >
                                >I saw NAMEISPI and DESCISPI somewhere (the tag doco, I think), but I
                                >didn't notice them in the line/tag doco you sent me the other day. It
                                >may be that they are not present in the data, in which case we might
                                >consider their removal and just put a 'ispi' attribute at the top of the
                                >game data description. The entire object or nothing, simple.

                                When we roll out the new OGL compliant sources, you will see a lot more of those. You will also see them in the CMP files. They need to stay there.

                                You might be right though, a single ispi might be all we need. You would have to check with Paul King for this one.


                                >Keith
                                >--
                                >Keith Davies
                                >keith.davies@...
                                >
                                >PCGen: <reaper/>, smartass
                                > "You just can't argue with a moron. It's like handling Nuclear
                                > waste. It's not good, it's not evil, but for Christ's sake, don't
                                > get any on you!!" -- Chuck, PCGen mailing list
                                >
                                >
                                >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/

                                -----------------------------------------------------------
                                Éric "Space Monkey" Beaudoin
                                >> In space, no one can hear you sleep...
                                >> Camels to can climb trees (and sometime eat them)
                                <mailto:beaudoer@...>
                              • Eric Beaudoin
                                ... Have you tried DOMAINS:.CLEAR[tab]DOMAINS:new domain If this do not already work, make a FREQ for it. That s the official way to do it with the .lst files.
                                Message 15 of 21 , Mar 5 10:31 PM
                                • 0 Attachment
                                  At 12:41 2003.03.05, Devon Jones wrote:
                                  >This one brings up one if my serious irritations with the existant LST
                                  >paradigm.
                                  >Some books, like Legends and Lore:Spells and Spellcraft offer alternate
                                  >spells for Domains. In my personal campaign lst files, I do a whole
                                  >heck of alot of this - but there is no way to *CLEAR* other elements out
                                  >of the DOMAINS: tag for spells - so then players end up having 2 spells
                                  >for some levels in their domains, and I basically just have to tell them
                                  >to ignore the wrong ones (or remove them from known spells). I *REALLY*
                                  >think we need a way to in <mod:whatever> tags to not just redeclare
                                  >things (because with many things, like the CLASSES: tag for spells, you
                                  >*want* them to be additive, instead of clearing the whole list) but be
                                  >able to explicitly Replace, Erase, Add or Subtract from any tag that the
                                  ><mod:whatever> is modifying, so long as in doing so it doesn't break the
                                  >rules for that particular tag (like erase the name).
                                  >
                                  >Soulcatcher
                                  >(Devon Jones)
                                  >PCGen Code Monkey

                                  Have you tried DOMAINS:.CLEAR[tab]DOMAINS:new domain

                                  If this do not already work, make a FREQ for it. That's the official way to do it with the .lst files.

                                  Same type of functionnality will have to be provided by the XML syntax.


                                  -----------------------------------------------------------
                                  Éric "Space Monkey" Beaudoin
                                  >> In space, no one can hear you sleep...
                                  >> Camels to can climb trees (and sometime eat them)
                                  <mailto:beaudoer@...>
                                • CC Americas 1 Carstensen James
                                  ... altogether). Two questions: 1. With a name, how do we ensure it is unique? 2. From an end result side, if the name of an object (class, race, eq, feat,
                                  Message 16 of 21 , Mar 6 6:52 AM
                                  • 0 Attachment
                                    Eric wrote:
                                    >>That would, of course, do it. Make all the names unique, at least
                                    >>within a single data type, then create the ID as above. That makes
                                    >>sense.
                                    >>
                                    >>I still believe that we need unique ID values for all items loaded;
                                    >>regardless of it being LST, XML, or RDBMS, this *is* a database, and
                                    >>having unique IDs makes things much easier to work with.
                                    >
                                    >I'd like use the name and use it as unique key (and forget the ID
                                    altogether).

                                    Two questions:

                                    1. With a name, how do we ensure it is unique?

                                    2. From an end result side, if the name of an object (class, race, eq,
                                    feat, spell, etc) gets .MODded, should that change the unique key or
                                    not?

                                    Cheers,
                                    Blue
                                  • Keith Davies
                                    ... Ah. Right. Damn. Okay. This ll complicate the loader a bit -- I was hoping for a fairly simple process as found -- but I think we can deal with it.
                                    Message 17 of 21 , Mar 6 8:17 AM
                                    • 0 Attachment
                                      On Thu, Mar 06, 2003 at 01:24:44AM -0500, Eric Beaudoin wrote:
                                      > At 11:00 2003.03.05, Keith Davies wrote:
                                      >
                                      > >I need to examine how loading works now, before I go any further. I
                                      > >think that, unless I find something different, we'll continue with the
                                      > >existing load semantics. They seem awkward, though.
                                      >
                                      > The RANK is usefull to see which .MOD gets apply before which other
                                      > .MOD. It also (I beleive) help resolve if a .COPY copy the .MOD object
                                      > or the original.

                                      Ah. Right. Damn. Okay. This'll complicate the loader a bit -- I was
                                      hoping for a fairly simple 'process as found' -- but I think we can deal
                                      with it.

                                      > >I still believe that we need unique ID values for all items loaded;
                                      > >regardless of it being LST, XML, or RDBMS, this *is* a database, and
                                      > >having unique IDs makes things much easier to work with.
                                      >
                                      > I'd like use the name and use it as unique key (and forget the ID altogether).

                                      <shrug> call it 'name', call it 'id', doesn't matter as long as there is
                                      one and it conforms to XML ID specification. It's customary to call it
                                      'id', though, and I think that when people see 'name' they're going to
                                      be prone to put in exactly what it says in the book.

                                      > I beleive many are .MOD and even .COPY so they reference an item and
                                      > make little modification to it (e.g. adding the DESC: tag to feats or
                                      > the page number with SOURCEPAGE: ).

                                      If we put in an interim file that maps the current NAME values to ids we
                                      should be able to minimize the impact here. Good point, though.

                                      > We must also think that this XML definition might becaume a de-facto
                                      > standard.

                                      I hope not, at least not this one. This schema is a little too rough
                                      yet.

                                      > We should make sure that application outside of the PCGEN
                                      > project can work with the data (basicaly, we should not think only of
                                      > ourselves). So, with that in mind, I wonder how we would convert a
                                      > Jamis Buck's NPC to our format? It won't have IDs. The only option I
                                      > see if we really needs the IDs is to generate them from other
                                      > arguments that are mandantory. That way, when we import data from
                                      > somewhere else, we'll be able to produce the ID.

                                      That would work okay. Or, if interoperability is needed, have the
                                      third-party software generate IDs. While we want to make it easy for
                                      others to interact with and use the data, the primary focus is to make
                                      it work for ourselves.

                                      > >Schema's a pain in the ass, though.
                                      >
                                      > I never thought we wanted to use DTD since you've been talking about
                                      > schemas all along. I thought we wanted to stay away of it because it's
                                      > not very flexible and do not allow to do much data type validation.

                                      By schema I was referring to file data model; schema is a pretty common
                                      term (I thought) for data models in general.

                                      > Since you don't like XML Schema, did you look into the alternatives:
                                      > RELAX-NG or Schematron ?

                                      Actually, as I said elsewhere, I think we'll end up going with something
                                      we build ourselves that is more tuned to gaming information. We don't
                                      need the full power of XSD; I think we can (later) build a data language
                                      that will suffice for describing types of gaming information. Matter of
                                      fact, we might want to hammer that out because it gets rid of lots of
                                      the concerns I have about validation.

                                      > >I've never used XHTML. I understood that it is simply HTML made
                                      > >XML-compliant.
                                      >
                                      > More or less yes. One thing for sure, there are no enforce order with it.

                                      Largely because it's a document/presentation mechanism that has to be
                                      able to handle arbitrary text and formatting. This schema is used to
                                      handle d20 (in the future, more or less general) gaming information.
                                      Two significantly different purposes. There are rules about data
                                      required and the like for various data types, and for the cost of a bit
                                      of discipline we can make it easier to validate and enforce these rules.

                                      > >> Moding and Subclassing do not do the same thing. Mod change the
                                      > >> original element and do not add new elements. Every Wizards are
                                      > >> differents from then on. SUBCLASS was made with specialist in mind.
                                      > >> You chose wizard but you can/have to chose a particular flavor of
                                      > >> wizard.
                                      > >
                                      > >It can be used for other purposes, though. I can see subraces (various
                                      > >flavors of elf or dwarf, subskills (like Knowledge, for instance), and
                                      > >so on. What say we have a namespace 'sub' that creates a subordinate
                                      > >copy of an identified element then applies changes to it? It will
                                      > >behave much like copy but more accurately describes what is happening
                                      > >and, incidentally, makes it easier to identify and change later on if we
                                      > >decide to?
                                      >
                                      > Yea, there is another thing with subclassing though, you narmally have
                                      > a chooser that pop to let you select which sub-class you use. In the
                                      > case of the Specialist Wizard, you can choose the Wizard or one of the
                                      > specialist and then a second chooser appear (if you chosed the a
                                      > specialist) to let you choose the schools you won't get. In the case
                                      > of the Psionics, you need to choose a speciality (there is no base
                                      > psy). So, right now SUBCLASS most internaly be very deeply link to the
                                      > CLASS. We need a code monkey to tell us for sure I guess.

                                      It's not terribly difficult to key these relationships back from the
                                      sub<item> to the parent. During load we can even build a list in the
                                      parent that has links back to the children/subs.

                                      > The race are done with template right now. Sub for race is a good idea
                                      > but it will need to happen after phase 1 or it would change internal.

                                      We can convert from our schema to the internal model, as long as we
                                      don't lost any information during the conversion to XML.

                                      > >So, the example above would be
                                      > >
                                      > > <sub:class ref="class.wizard"
                                      > > id="class.illusionist"
                                      > > master="class.wizard">
                                      > > <name>Illusionist</name>
                                      > > <!-- identify barred schools; I don't know this yet -->
                                      > > </sub:class>
                                      > >
                                      > >Makes it clear that it is closely related to the parent, gives us the
                                      > >ability to sub... um, create a subelement of more things and provides an
                                      > >interface consistent with the thing being subbed.
                                      > >
                                      > >> COPY right now really copy the object in memory whereas SUBCLASS just
                                      > >> add to the existhing object. Francly, I don't care about this diffence
                                      > >> but I thought I'd mentionned it in case it make a difference for you.
                                      > >
                                      > >So... what use is COPY, then? I don't think I see the benefit to just
                                      > >duplicating something in memory.
                                      >
                                      > New Name.COPY=Original Name NEWTAG:newvalue ...
                                      >
                                      > The .COPY create a new object that you then modify. The original
                                      > object stays in and can also be accessed. .MOD modify the original
                                      > object.

                                      Ah, okay, so it's pretty much like I described above:

                                      <copy:class id="class.new-wizard" ref="class.wizard">
                                      <!-- make changes -->
                                      </copy:class>

                                      It keeps everything inherited from the referenced item, gives it a new
                                      ID, and allows changes of the inherited data.

                                      > The is also a syntax to remove an object (.REMOVE I think).

                                      <mod:class ref="class.sorcerer" action="remove" />

                                      > >> The columns will be large enough as they are, no need to get them
                                      > >> larger if we need to. Vertical formatting might not be possible
                                      > >> anyway so it's not a big point. That's actually one bad thing about
                                      > >> the XML format, we will have to look at the data one record at a
                                      > >> time instead of looking at tables like we used to.
                                      > >
                                      > >Inside the program it'll still be loaded into tables. We don't have
                                      > >time to make changes of the kind of scope needed to change that.
                                      >
                                      > I'm talking about the human looking at the data files. He looks at the
                                      > books and see tables. Right now, he looks at the files and also see
                                      > tables. It would have been nice to find a way to format our XML in
                                      > table.

                                      Ah, okay, I see now. Yep, nothing for it. XML is verbose, and they way
                                      we're talking about supporting it (especially with the ordinality stuff
                                      we were talking about the other day) we're stuck with that.

                                      > It will a long time before having an editor that his good enough to
                                      > convince the main data monkeys to move away from their favorite text
                                      > editor. We should try to make a format that will be workable. If you
                                      > are not convince about this, just check the number of Code Monkeys
                                      > that still prefer using a standard text editor for Java (starting with
                                      > Bryan) even though the Java EDI have become quite mature and well
                                      > supported.

                                      Hey, I cut C/C++ code using vi/vim. I know what you mean.

                                      > >> >I've always considered prereqs, for example, to be closely enough
                                      > >> >related that we want them in one place. I don't want to be
                                      > >> >looking through the entire object to find all the prereqs. So,
                                      > >> >while XML does not technically require it and we could do without,
                                      > >> >I think it's a good idea for style reasons.
                                      > >>
                                      > >> Let's not impose style in the language. They can be grouped
                                      > >> togetter without adding the extra element.
                                      > >
                                      > >I think there are sufficient benefits to include the parent element.
                                      >
                                      > I guess we agree to disagree. Since there is no grouping of family of
                                      > tags right now with the .lst files, I suggest we pospone this debate
                                      > for phase 3.

                                      Trade you -- give you this (though I think it's useful) for IDs (which I
                                      think will be necessary).

                                      > >I saw NAMEISPI and DESCISPI somewhere (the tag doco, I think), but I
                                      > >didn't notice them in the line/tag doco you sent me the other day.
                                      > >It may be that they are not present in the data, in which case we
                                      > >might consider their removal and just put a 'ispi' attribute at the
                                      > >top of the game data description. The entire object or nothing,
                                      > >simple.
                                      >
                                      > When we roll out the new OGL compliant sources, you will see a lot
                                      > more of those. You will also see them in the CMP files. They need to
                                      > stay there.
                                      >
                                      > You might be right though, a single ispi might be all we need. You
                                      > would have to check with Paul King for this one.

                                      Will do. I think that CMP files and PCGen files will be separate
                                      distros and this won't be a particular problem, but I'll ask.


                                      Keith
                                      --
                                      Keith Davies
                                      keith.davies@...

                                      PCGen: <reaper/>, smartass
                                      "You just can't argue with a moron. It's like handling Nuclear
                                      waste. It's not good, it's not evil, but for Christ's sake, don't
                                      get any on you!!" -- Chuck, PCGen mailing list
                                    • Keith Davies
                                      ... It will. It won t be as elegant as I d been planning (you still have to mod the spell :/) but it ll be there. Keith -- Keith Davies
                                      Message 18 of 21 , Mar 6 8:20 AM
                                      • 0 Attachment
                                        On Thu, Mar 06, 2003 at 01:31:22AM -0500, Eric Beaudoin wrote:
                                        >
                                        > Have you tried DOMAINS:.CLEAR[tab]DOMAINS:new domain
                                        >
                                        > If this do not already work, make a FREQ for it. That's the official
                                        > way to do it with the .lst files.
                                        >
                                        > Same type of functionnality will have to be provided by the XML
                                        > syntax.

                                        It will. It won't be as elegant as I'd been planning (you still have to
                                        mod the spell :/) but it'll be there.


                                        Keith
                                        --
                                        Keith Davies
                                        keith.davies@...

                                        PCGen: <reaper/>, smartass
                                        "You just can't argue with a moron. It's like handling Nuclear
                                        waste. It's not good, it's not evil, but for Christ's sake, don't
                                        get any on you!!" -- Chuck, PCGen mailing list
                                      • Keith Davies
                                        ... dunno. See, we can have the same name for different data types; IDs make that irrelevant. ... I would think that if an item is MODed the ID stays the same
                                        Message 19 of 21 , Mar 6 8:23 AM
                                        • 0 Attachment
                                          On Thu, Mar 06, 2003 at 09:52:53AM -0500, CC Americas 1 Carstensen James wrote:
                                          > Eric wrote:
                                          > >>That would, of course, do it. Make all the names unique, at least
                                          > >>within a single data type, then create the ID as above. That makes
                                          > >>sense.
                                          > >>
                                          > >>I still believe that we need unique ID values for all items loaded;
                                          > >>regardless of it being LST, XML, or RDBMS, this *is* a database, and
                                          > >>having unique IDs makes things much easier to work with.
                                          > >
                                          > >I'd like use the name and use it as unique key (and forget the ID
                                          > > altogether).
                                          >
                                          > Two questions:
                                          >
                                          > 1. With a name, how do we ensure it is unique?

                                          dunno. See, we can have the same name for different data types; IDs
                                          make that irrelevant.

                                          > 2. From an end result side, if the name of an object (class, race,
                                          > eq, feat, spell, etc) gets .MODded, should that change the unique key
                                          > or not?

                                          I would think that if an item is MODed the ID stays the same because
                                          that identifies the item and it's still the same item. If an item gets
                                          COPYed the new item would need a new ID assigned.

                                          Of course, it may be desirable to MOD the ID of an item, but I don't
                                          even like to think about the semantics and behavior of that. I think
                                          this case might be handled better by

                                          <copy:item ref="item.id" id="item.new-id" />
                                          <mod:item ref="item.id" action="delete" />

                                          because we could probably expect this to be handled properly by the
                                          program anyway. Still thinking on this.


                                          Keith
                                          --
                                          Keith Davies
                                          keith.davies@...

                                          PCGen: <reaper/>, smartass
                                          "You just can't argue with a moron. It's like handling Nuclear
                                          waste. It's not good, it's not evil, but for Christ's sake, don't
                                          get any on you!!" -- Chuck, PCGen mailing list
                                        • Keith Davies
                                          ... I don t know about this fine-grained dependency stuff; as it stands if you want to load an XML file you get everything that s in it. While we *could*
                                          Message 20 of 21 , Mar 6 8:38 AM
                                          • 0 Attachment
                                            On Wed, Mar 05, 2003 at 10:41:06AM -0700, Devon Jones wrote:
                                            > Keith Davies wrote:
                                            >
                                            > >On Mon, Mar 03, 2003 at 10:10:48AM -0800, Keith Davies wrote:
                                            > >
                                            > > It will be allowable for two files to be mutually dependent
                                            > > (though it's a good idea to avoid that when possible). The
                                            > > loader will be able to successfully deal with this.
                                            > >
                                            > This opens up one fantastic thing. I'm sick and tired of my players
                                            > loading up something like oriental adventures, and as a result, all
                                            > characters modified in that session now depend on OA *Rolls Eyes*.
                                            > Even if we don't export all the data with every .pcg, we have the
                                            > capability with this and the finer grained dependancy stuff you talk
                                            > about in later messages to be accurate about what sources a character
                                            > *really* depends on - not just a list of what files were loaded when
                                            > the character was created.

                                            I don't know about this 'fine-grained dependency' stuff; as it stands if
                                            you want to load an XML file you get everything that's in it. While we
                                            *could* load (or at least, keep) just the bits we're interested in, it
                                            makes for an awkward file-handling model.

                                            Now, one possibility I was considering is that PCGen maintains a central
                                            store of data, and when people want to add new data files they get
                                            'loaded' -- the items read, pulled apart, the 'index files' you were
                                            talking about created, and the items written out to files containing
                                            minimal information each. Identify a minimal subset of information
                                            needed for all items and load that so that at all times so it's
                                            available and points at the files that contain the rest of the data.
                                            Defer loading of the rest of the information until it's needed (such as,
                                            when displaying a list of equipment, only the name and cost are present
                                            and descriptions get loaded as and when needed).

                                            This is *not* even considered for this phase. It makes things more
                                            complex than they are now and doesn't do a lot to make things better.
                                            Also, having that many files would be prohibitive in system space
                                            (though if we could JAR them all or something it might be worthwhile.

                                            Later...

                                            > > So, some specific examples:
                                            > >
                                            > > fireball => spell.fireball
                                            > > delayed blast fireball => spell.delayed-blast-fireball
                                            > > Melf's acid arrow => spell.melfs-acid-arrow
                                            > >
                                            > > Ranger => class.ranger
                                            > > Monte's Ranger => class.ranger.monte-cook
                                            > >
                                            > I know this is a detail that will be not be important for some time,
                                            > but I think it's important to at least point it out - with things like
                                            > Melf's Acid Arrow, we should use the SRD name (Acid Arrow), and let
                                            > the CMP datasets .MOD Acid Arrow to add the PI.

                                            For SRD files, I agree. However, eventually non-OGL files will be
                                            available, and I needed an example that had punctuation in it. Melf's
                                            Acid Arrow (as opposed to Acid Arrow) was chosen deliberately for the
                                            purpose of discussion and example.

                                            For PCGen files, of course we'll stick to the SRD name.

                                            > Basically what I intend from this is that none of the IDs should have
                                            > PI in them - so that we don't get sued ;)

                                            If the item being described is PI, it makes sense to keep it in the
                                            ID... we're not going to get busted for the ID if the data is
                                            acceptable.

                                            > This is fantastic, as it can eventually lead to much more sophesticated
                                            > loading and parsing - such as that mentioned in a different message
                                            > relating to OR with prerequisites.
                                            >
                                            > This should probably be used for most elements. Prereqs, Bonuses,
                                            > etc. this will IMHO make things *WAY* more supportable.

                                            I think it should be as well, but we might not do it right now.

                                            One thing I'd *really* like to see is breaking the various dot-, comma-,
                                            and pipe-lists into proper lists so they don't need to be parsed and
                                            examined so often.


                                            Keith
                                            --
                                            Keith Davies
                                            keith.davies@...

                                            PCGen: <reaper/>, smartass
                                            "You just can't argue with a moron. It's like handling Nuclear
                                            waste. It's not good, it's not evil, but for Christ's sake, don't
                                            get any on you!!" -- Chuck, PCGen mailing list
                                          Your message has been successfully submitted and would be delivered to recipients shortly.