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
> >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
I hope not, at least not this one. This schema is a little too rough
> 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
> 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
Ah, okay, so it's pretty much like I described above:
<copy:class id="class.new-wizard" ref="class.wizard">
<!-- make changes -->
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
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
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,
> 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.
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