• entries
191
861
• views
117768

# XMHell

185 views

When I first started on my current project, oh, say about 3 years ago, I said to myself "Well, I would like an extensible data storage format, since my game entities will all be very highly dynamic. I think XML is probably the way to go, but at the moment, I don't have time to learn XML, write about it (this was for a book), and use it efficiently, so I'll roll my own limited format!".

Fast forward 3 years, I'm now taking the project out of mothballs, and decided to make it everything that it deserved to be.

One of the things I always wanted to do was use XML for the data storage. When I decided to use .NET, I had an epiphany... .NET has XML classes built in; this should be a snap!

20 failed snaps later, I'm thinking of throwing out the whole idea.

XML seems like a poor substitute for what I need. Even more, I feel like I tried using a torque wrench to pound a nail.

Does XML offer me what I need? Of course.
Do I have to fight with it and use it in strange, twisted, unnatural ways? Yeah.
Is XML the solution I want? I don't know.

For example; For the bloody life of me, I can't figure out what the hell the point of XML attributes are, except for uneccessarily ambiguating the language (is ambiguating a word?).

I see examples all over the internet like this:

"3" unit="cups">Flour

Now what I don't get is how this is legal, and yet this, is also perfectly legal:

    3    cups    Flour

Or any of 100 other permutations. It seems to me that there are 500,000 different ways to represent a complex object in XML... so which way is the right way?

At the moment, I'm using XML like this:

	<long name="id" value="46575"/>	"name" value="Big Room"/>	<long name="region" value="047"/>	<float name="databank var 1" value="3.14159"/>	<br>		<string name=<span class="cpp-literal">"name"</span> value=<span class="cpp-literal">"Prevent Users From Leaving Unless They Have Item"</span>/><br>		<<span class="cpp-keyword">long</span> name=<span class="cpp-literal">"item"</span> value=<span class="cpp-literal">"42566"</span>/><br>

	"long" name="id">46575"	"string" name="name">Big Room	"long" name="region">047	"float" name="databank var 1">3.14159	<br>		<data type=<span class="cpp-literal">"string"</span> name=<span class="cpp-literal">"name"</span>>Prevent Users From Leaving Unless They Have Item</data><br>		<data type=<span class="cpp-literal">"long"</span> name=<span class="cpp-literal">"item"</span>><span class="cpp-number">42566</span></data><br>

This seems to be more along the lines of what XML designers like to use... but it's bigger, and I don't like the arbitrariness of treating types, names, and content as attributes and content. Argh.

Quote:
 * "XML is a giant step in no direction at all" -- Erik Naggum * "Some people, when confronted with a problem, think 'I know, I'll use XML.' Now they have two problems." -- dirtsimple.org * "XML is like violence - if it isn't working properly, you aren't using enough of it." -- Anon

*sigh*

The final approach seems fine. Jut don't overdesign it[lol]

One thought is why don't you use python scripts (well, not just python, I mean directly an scripting approach) directly instead of XML files when writing entities. My point is when you change the neccessary parameters for one entity class, can you automaticly refresh all entity files?

XML itself attributes no meaning to the entities that you place within in (speaking here mainly about elements and attributes here, which are the primary meat in any XML based solution).

as far as your frustration concerning attributes versus subelements, I would use the following rule of thumb:

If an entity(for lack of better term) can have no more than one of something, use an attribute. If an entity can have more than one of something, use a subelement.

For example:

a "point" might be an entity for which "x" and "y" are meaningful (assuming a 2d coordinate system). These values are assumed to be 0 if absent, but a point cannot have more than one x or y value, so they should be attributes, i.e.

<point x="13" y="37"/>

but now take a line segment, which requires two points. rather than having x1, y1, x2, y2, use point entities:

<line>
<point x="13" y="37"/>
<point x="37" y="13"/>
</line>

and in fact, line now becomes "polyline" or "linelist" as you could add as many points as you like.

or, you can keep going with the "XML doesn't do exactly what I want it to do exactly the way I want to do it, I will therefore discard this potentially very useful tool".

Yeah, although XML has huge potensial, it's pretty limiting when it comes to having everything in the right format. If you make any progress with it, please let us know....

## Create an account

Register a new account