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

RE: [pcgen-xml] XML plan summary

Expand Messages
  • 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 1 of 21 , Mar 3, 2003
    • 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 2 of 21 , Mar 3, 2003
      • 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 3 of 21 , Mar 3, 2003
        • 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 4 of 21 , Mar 3, 2003
          • 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 5 of 21 , Mar 3, 2003
            • 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 6 of 21 , Mar 3, 2003
              • 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 7 of 21 , Mar 3, 2003
                • 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 8 of 21 , Mar 4, 2003
                  • 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 9 of 21 , Mar 4, 2003
                    • 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 10 of 21 , Mar 4, 2003
                      • 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 11 of 21 , Mar 5, 2003
                        • 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 12 of 21 , Mar 5, 2003
                          • 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 13 of 21 , Mar 5, 2003
                            • 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 14 of 21 , Mar 5, 2003
                              • 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 15 of 21 , Mar 6, 2003
                                • 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 16 of 21 , Mar 6, 2003
                                  • 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 17 of 21 , Mar 6, 2003
                                    • 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 18 of 21 , Mar 6, 2003
                                      • 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 19 of 21 , Mar 6, 2003
                                        • 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.