XML Scripting Start

Personally I'd go for

<Unit id="1"> ...

But of course it's a matter of style.

If you specify that numbers must be included in element names, that will prevent a DTD or schema being made for your XML format (Not that that is a major problem) - as in a DTD or schema there must be a finite number of possible named elements and attributes (I think).

Mark

Thank you for the reply. I just wanted to see if it was okay, as in style, to do something such as this; your suggestion is better.

I want to make it easy for other people to edit objects in the game without having to go decipher how am I organizing things.

My personal preference is not to have text between tags, to always use attributes.

<unit class="worker" name="MA-Worker Class A" research="false" available="true" hp="10" />

If there are any attributes that can have multiple values I break them off into their own sections. I also use sections for information that isn't really about the element, like upgrades, weapons etc.

For example, all workers can be upgraded into super workers or individual workers 'promoted' to soliders or super workers at a lower tech level...

<class name="worker" hp="10" cost="100">    <upgrade techlevel="3" cost="2000" result="super worker" obsolete="true" />    <promote techlevel="2" cost="150" result="solider" />    <promote techlevel="2" cost="50" result="super worker" /></class><class name="super worker" hp="20" cost="100" techlevel="2" /><class name="solider" hp="40" cost="200" techlevel="1" />

And to have units in a map you could have something like this

<map name="badlands">    <unit class="worker" id="1" x="345" y="10">    <unit class="super worker" id="2" x="340" y="20"></map>

You can take this as far as you want, it could also be possible to modify a unit's starting health just by adding a hp attribute.

I also like having default values for the attributes that aren't there so the file doesn't get cluttered with excess information. I haven't used a techlevel attribute for the worker class, the default value would be techlevel 0, always available.


I also think markr is correct, a dtd only works for elements with specific names.

On the contrary, using more elements is the suggested approach in many books like Effective XML. The relevant section.

Using more elements when needed is the idea. For each of my examples there isn't much need to further segment any of the attributes, they are either whole numbers or string references to other elements. Grouping these elements may be a good idea.

To quote the link posted:

Quote:

In general, however, if I suspect that an element might usefully be further divided, I will divide it

I can see no use to further divide "super worker" a string reference to another element, or "200" an integer.


The real question not answered in that chapter is whether a single attribute of an element should be in a child element or a property.

<person>    <age>32</age></person>

or

<person age="32" />

If the attribute has no further structure, and is singular (like age) I don't see why it can't be a property. Otherwise there is no use for the property structure in xml files.

Edit:

co-ordinates and some sort of upgrade, cost combo would be some structures I'd probably start thinking about abstracting out of the game examples I gave.

this is a relevant chapter.

Property is the collective term for attribute and child elements.

You're right about that chapter being relevant, though! The first paragraph is a good synopsis of where this discussion might lead:

Quote:

There's a recurring mild flame war on the xml-dev mailing list about when one should use attributes and when one should use elements. There's a slightly hotter one about whether one should ever use attributes at all. The bottom line is that it's really up to you. Do what feels right for your application. Most developers prefer to use attributes for metadata as opposed to the data itself, but this is a very rough rule of thumb at best. Of course, what's data and what's metadata depends heavily on who is reading your documents for what purpose.

Personally (professionally?), I'm on the side of using elements for just about everything and avoiding attributes for just about everything (apart from numbers, like the id example makr gave).