ratified XML plan (was: XML plan
- Hi All,
this is the message I posted to PCGen BoD; Bryan responded with 'sounds
good'. We're a go, using the plan outlined below.
Below is a document I prepared describing how XML will be incorporated
into PCGen. This is not how I would *prefer* to do this task, but due
to various and assorted concerns about data integrity during the
conversion I have amended my original plan to that below.
Preparation will begin immediately. Prep includes completing the
intermediate XML schema, documenting it, analysis of extant code and
data files, creation of conversion utilities for distributed LST files,
and design and planning for changes to be made to source code. Actual
implementation of changes to source code and distributed data files will
begin only after 5.0.0 is released. This is in order to avoid any
impact on the schedule for 5.0.0. It is my expectation that, if the
needed resources and support are available when the XML implementation
is begun, it will be ready for testing (5.9.*) about one month after
The document below is a summary of my conclusions and design decisions.
There are some things in it that may be unpopular with some people; the
decisions I made are for expediency, conformance to standards, and/or
expected uses of the files and related technology. I will document the
reasoning behind my decisions below as time and opportunity allow. I'm
going to be rather busy for the next couple months, though....
Questions or comments?
The plans for including XML in PCGen have been changed because of time
limitations and concerns expressed. For now, incorporating XML into
PCGen will be done in a fashion that will have as little impact as
possible. This means the following changes will be made:
1. All data file I/O will be moved to persistence from core.
2. XML I/O classes will be built to parallel the LST file I/O classes.
3. All data files distributed by PCGen will be converted to XML
The XML schema to be used will be derived from the existing LST schema.
This is necessary in order to minimize work required to interact with
the existing internal data model (IDM). As a result, we will not be
able to gain all the benefits available to us as side effects of moving
to XML. However, it will give data monkeys the opportunity to gain some
familiarity with the technology before we redesign the IDM.
By and large, the semantics of the various tags used will be maintained.
I expect there to be some changes, but they should be easily understood.
For the most part, any changes made will be because they are either
necessary for XML or because they will aid later work.
Some key changes -- that I will be very difficult to talk out of -- are:
1. All game-level entities will have XML ID values. These ID tags will
be much like existing NAME tags, but will conform to XML standards.
2. Everything will be case-sensitive. All XML tags will be lowercase.
All ID values will be lowercase... which means that all references to
those IDs will be lowercase.
3. It will not be possible to mix LST and XML files during a load
instruction. That is, it will not be possible to have an XML file
load a LST file, nor vice-versa.
4. All LST files will be converted at once, not type by type. I'd
rather have a week of pain then drag it out over a month, and I don't
see much to be gained. Branching temporarily may be a good idea;
implementationally we'll do it type by type, but merge only after all
types have been done.
5. Different file extensions will be used; I suggest prepending an 'x'
to the file extension for XML files (xlst, xpcg).
I'd suggest the following version path:
5.0.* core branch, continues current development
5.1.* XML incorporation branch. Performs all changes described above.
5.2.* merge two branches; core feature freeze, support
5.3.* branch again; branch removes LST support
5.7.* merge again (bug fixes into dev)
5.9.* dev becomes prime, heavy testing (beta)
6.0.0 formal release of XML support
I expect that several of these versions will be short-lived. After the
changes made above, yanking LST support shouldn't take much.
Known effects of the conversion:
1. Data files will be heterogeneous. Any file will be able to contain
any tags, within the rules defined for the files. That is, there
will be rules of ordering the tags, but a single file will be capable
of containing all data types. It will be possible to perform a
single export containing *all* data required to process a character,
for example. However, while all XML files will use the same syntax,
extensions may be used to differentiate between uses (for instance,
data files and character files will have different extensions).
2. It is possible (heh, it has happened) that more than a single source
may describe the same thing. This is the only case where the same ID
may be used for two XML elements; a facility will be included to
handle this situation. For instance, there is a feat described in
two different splat books; it is the same feat in both, though there
may be a difference in definition. It will be possible to specify
which of the definitions is to be used.
3. Related, more than one XML element will be allowed to have the same
name. It will be allowable to have a spell and a feat have the same
name, or even to have two classes to have the same name
(differentiated by ID). This is, IMO, a happy side-effect.
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