RE: [Xenocide-programming] XML facility-item data

[mamutas <ma...@pr...>]

First option is the easiest to read which is important, cause XML will be
created by human.
And XML allows making entry optional, so the user could put only necessary
entries.
The parser will follow what is in DTD, so it should not be a big deal for
the parser to detect what entry is expected.

-----Original Message-----
From: xen...@li...
[mailto:xen...@li...] On Behalf Of Cpt.
Boxershorts
Sent: Wednesday, April 07, 2004 10:38 PM
To: xen...@li...
Subject: RE: [Xenocide-programming] XML facility-item data


Hey all,

	One more question, and then I should have the config files
posted as soon as I finish the design docs.

	I'm finishing up the cross-references between different items,
research nodes, crafts, etc., and I've come up with three possible ways
to record it.

So that everybody understands what I'm talking about, a cross reference
is where one entry points to another entry, e.g. the Pistol Ammo Clip
item has a reference to the Pistol item that indicates which item it can
reload.

That's a simple one....two items, same document, same 'type'.  In the
research tree, there are references to six different entry types (other
topics, crafts, items, personnel, facilities, and missions)  The
specific 'type' must be able to be determined by the parser so it knows
which document to look in for the associated entry.

The first way is to have a separate xml element for each reference type.
So it would look like this:

<craft craftid="craft1"/>
<item itemid="item1"/>
<facility facilityid="facility1"/>

	Pros:  Each element immediately defines the 'type' of reference.
Minimal processing (just a select case, really) is needed to determine
where the associated document is.
	Cons:  Not every entry uses all element types, so the xml is
overly complicated. The parser would need to recognize and watch for all
the different possible reference elements.  Adding a new reference
element might require extensive code work.

The second idea is to combine them into one element with multiple
attributes.  Only one of the attributes would ever be used.

<reference craftid="craft1"/>
<reference itemid="item1"/>
<facility facilityid="facility1"/>

	Pros: easy to read, easy for the parser to know what element is
a reference. 
	Cons:  More process intensive.  Each attribute would have to be
tested for a valid value to find the id value.

Third idea takes it a step farther.  Since in xml, a unique identifier
must start with an alphabetic character, I ened up changing all the id
values from "1, 2, 3..." to "item1, item2, item3..." with the actual
'type' as a prefix to the id (it seemed better than using an arbitrary
string).  So technically, with a bit of string manipulation, you can
tell what 'type' the reference is to, and there's no need for multiple
attributes:

<reference refid="craft1"/>
<reference refid="item1"/>
<facility refid="facility1"/>

	Pros:  Easy to read, easy to pick the id value out
	Cons:  String manipulation is major processor hog.

Thought?

-The Captain 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.650 / Virus Database: 416 - Release Date: 4/4/2004