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

Re: [pcgen-xml] XML plan summary

Expand Messages
  • 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 1 of 21 , Mar 4, 2003
      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 2 of 21 , Mar 5, 2003
        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 3 of 21 , Mar 5, 2003
          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 4 of 21 , Mar 5, 2003
            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 5 of 21 , Mar 5, 2003
              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 6 of 21 , Mar 6, 2003
                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 7 of 21 , Mar 6, 2003
                  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 8 of 21 , Mar 6, 2003
                    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 9 of 21 , Mar 6, 2003
                      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 10 of 21 , Mar 6, 2003
                        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.