Re: Why XML?
- You discount the status of XML as a standard far too much.
Because XML is a standard, there are a myriad of (free) tools that
enable coders to very easily harness all of its power.
Because XML is a standard, MORE people will be able to maintain data
files - because they won't have to learn a new standard.
And I believe I saw a recent statement that the data files are
becoming XML over on the main pcgen list. That the code gods feel
it's the best way to go to support what PCGen must do to gain WotC
Which to answer the last part of your email, yes, it seems that PCGen
MUST remove any notion of the game mechanics out of its CODE and into
its DATA. XML can represent mechanics very well.
Java can also load, compile, and code "on-the-fly". Though I doubt
this will be necessary if the code gods implement the XML schema
--- In pcgen-xml@y..., "mauriceonmaplate" <stevescottuk@h...> wrote:
> As far as I can see, XML introduction has one advantage, which is
> that it is a 'Standard', and a number of disadvantages.
> The advantage may be ephemeral, in that XML is context-ignorant.
> As I see it we need to standardize, so that Tag's used in multiple
> places work the same. But I have two extreme cases that I would
> to ask about.
> USER EDIT
> Lst files are good in that they are [relatively] easy to edit.
> Moving to XML may make editing so much harder that people will shy
> away from it, and PCGen.
> IF the ability to Edit the source data is important, surely we need
> to retain something as simple as the LST files, but improve them by
> The alternate end of the spectrum is to have the source data held
> such a way that it is complete and nothing in the program relates
> D20 or any other product. I believe this was something required or
> advised by WOTC.
> Some languages can take in 'code' and 'compile' it on the fly. I
> wonder if this is possible in Java?
> Some languages can create Objects which can be stored and then read
> into another program, can Java?
> Are there any other ways the basic requirement can be worked in
> Steve [Amateur Programmer, Java-Novice, former Manager]
- On Fri, Aug 23, 2002 at 07:55:34PM +0000, merton_monk wrote:
> We're going to steer clear of descriptions - even paraphrased onesAhhhh... now that I've exhumed myself from under this weekend's email
> for now. At some point I hope I'm able to sit down with a sofrware
> lawyer and figure out to what extent we (and by that I mean me!) are
> liable for users who enter in verbatim text. I don't want to get
> into a legal quibbling discussion here - I've been in them too much
> lately! So consider it a Benevolent Dictator Directive (hey - I get
> to issue those from time to time!) that we don't include any
> descriptions at all. However, we can plan/design for them assuming
> that we can use that at some point. I think that most publishers are
> fine if we include summary-type descriptions, but it's a touchy
> issue. For now we'll go the safe route.
and can reply to things (supposedly) intelligently....
This is my intent. It'll be designed in, but (so far as I know) will
not be used in the official files. I expect the 'brief descriptions'
-- the one-liners like "creates a big, hot ball of fire" or "lets you
move through combat more safely" -- will still be present in the data,
To a certain degree I'm overdesigning the schema. I can see some things
that make sense to include even if we won't be using them right away.
Case in point, the rules currently call for cleric spells, and domain
spells. I plan to support a cleric list, lists for domains, and a
specific list for each god. Thus, if all clerics of a god have access
to a particular set of spells, but not all other clerics do, they can be
granted 'directly' by the god. They may or may not also be domain
spells. Incidentally, I'm also planning to support multiple pantheons.
The dwarven clerics, for example, will have different spells available
to them than clerics of the Imperial gods, which will be different from
the spells of the clerics of the jungle spirits. Or not.
Another example is skills. It will be possible to define subskills for
pretty much any skill, much like Perform. For instance, my
Knowledge(Religion) has a whole bunch of subcategories such as 'dwarven
pantheon', 'Naurond' (specific dwarven god), 'Vudun' (another pantheon),
etc.; as ranks are gained these subskills may be selected. Similarly
with Craft -- the specific skill taken may have subskills
(Craft(Weaponsmith) has subskills based on the different ways of
creating weapons, or different categories... 4 ranks gets a decent
grounding in the common weapons of the culture, but exotic weapons
would require more ranks and masterwork items might require special
Another thing is prerequisites on a larger range of things, including:
- feats (currently done)
- classes (currently done)
- class levels ('in order to reach 8th level, /x/ must be done', or
'must have /y/ feat in order to reach 5th level')
- skills (must have /x/ feat to learn this skill... which I've seen in
- race (why not? Earlier editions of D&D used to have this)
Overbuilt, perhaps, but at least it won't have to be hacked in later....
PCGen: <reaper/>, smartass
"While information might or might not want to be free, it definitely
doesn't want to live under a DRM" -- Jonas, on PCGen