XML: Elements vs Attributes

Started by
10 comments, last by HarryW 19 years, 3 months ago
It seems to me that using an element to store a property, or an attribute are just two different ways to do the same thing.
<enemy>
    <x_position>4</x_position>
    <y_position>6</y_position>
    <health>10</health>
</enemy>
or...
<enemy x_position="4" y_position="6" health="10" />
Some tutorials I've read say that attributes should be used sparingly, while others seem to go all out with the attributes. I know this is probably just a style issue, and it could go either way, but what way do you prefer and why?
--------------------------<modena> - Comfortably Nub
Advertisement
When I used XML for my settings for test engines - I used the attributes method. It ended up looking like this: (edit: I hope I have not mixed up the terms attribute and element - if I have please correct me)

<?xml version="1.0" encoding="utf-8" ?><RTS_Game>	<Settings 		Width = "800"		Height = "600"		BPP = "32"		FullScreen = "0"		X = "0"		Y = "0"		Title = "Data-Driven RTS Game"	/></RTS_Game>


I think it is much easier to read - not to mention smaller! When I made my XML parser and was wokring with multi GB files - I needed to save as much space as possible - and attribtues are what saved me!

Now don't get me wrong! They are not the solution for everything - but if you have multiple data of a type belonging to the same element, such as in lot of game applications - why not use the attributes? I'm sorry for only addressing the game aspect, but it is the only experience I have in using XML with. As for that code you presented - I'd take the second over the first - but if you make your own parser - adding in support for the second is a challenge [wink].

Quote:It seems to me that using an element to store a property, or an attribute are just two different ways to do the same thing.


You are absolutly correct - there is no difference in what they accompish. Some would perfer using one or the other just for looks, but as I said, the first method is significantly larger in final size - if you use descriptive naming for the elements. I hope this helps some!

- Drew
I'm using xml as a file format for a map editor. My first thought was to use mainly attributes for things like position, item name, etc but after reading a few tutorials I decided to use elements only. No particular reason besides others had recomended this.

m-sambo
Except that attributes are much more restricted than elements, there aren't any strong reasons for using one over the other.
John BoltonLocomotive Games (THQ)Current Project: Destroy All Humans (Wii). IN STORES NOW!
Quote:Original post by m-sambo
I'm using xml as a file format for a map editor. My first thought was to use mainly attributes for things like position, item name, etc but after reading a few tutorials I decided to use elements only. No particular reason besides others had recomended this.

m-sambo


The main reason I would rec. attributes for maps is becasue of size. Here is an example from a Map Maker I made a while back using XML and MFC.

This is the optimized attribute form. The file size was 45kb. It represented the graphic index layers. As you can see everything is as compact as possible to get the smallest possible map.
<?xml version="1.0" encoding="utf-8" ?><Map><D0_0><h L0="0" L1="0" L2="0" L3="0" /></D0_0><D0_1><h L0="0" L1="0" L2="0" L3="0" /></D0_1><D0_2><h L0="0" L1="0" L2="0" L3="0" /></D0_2><D0_3><h L0="0" L1="0" L2="0" L3="0" /></D0_3><D0_4><h L0="0" L1="0" L2="0" L3="0" /></D0_4>...


Now if I would had used the other method, I would be adding so much additional data that would bloat the map. Normally I had a nicer format to this map, It was like:

<?xml version="1.0" encoding="utf-8" ?><Map><Row_0_Col_0><Layers Layer_0="0" Layer_1="0" Layer_2="0" Layer_3="0" /></Row_0_Col_0>...


But as you can see the extra code. Now if I were to use the <> </> method for all of those elements were looking at at least a 50% increase in data size. The first method had 46 characters in the first line and the second method had about 86. With the element style, add at least another 40 characters. Now for small maps this is acceptable - but try making a 100x100 tiled map!

I am not saying you should use either or - its just from experience, I know that you want the most amount of data represented in the least possible size - of which the attributes method is superior to. If you need to see real proof of the size difference, I think I still have my map generator that switches between expanded names and short optimized names. I'm sure I can dig it out or just write another one. Good luck!

- Drew
Logically, anything that can have more than one instance should (and has to be!) be an element, and things that occur once should be attributes. For example, there can be many 'enemy' instances so it should be an element, but there will only be one x_position (within the enemy element), so it should be an attribute of enemy.

Practically, it doesn't really matter.

Personally I would make as much as possible attributes.
i just like to think of elements as classes, and attributes as variables. Then I make use of them accordingly (innertext, i've never found the need for innertext).
Quote:Original post by Drew_Benton

I am not saying you should use either or - its just from experience, I know that you want the most amount of data represented in the least possible size - of which the attributes method is superior to. If you need to see real proof of the size difference, I think I still have my map generator that switches between expanded names and short optimized names. I'm sure I can dig it out or just write another one. Good luck!

- Drew


Yeah in my case it makes a large difference in file size too. My editor is not a game map editor exactly but rather a mapping application for those that play interactive fiction. These maps are limited to rooms and connectors with text descriptions and don't consist of a large number of rooms normally so file size isn't a major consideration for me. Having said that I may reimplement my code to make use of attributes at some point anyway. :)

Mike
I'd second what Kibble said: attributes for one-to-one relationships, elements for many-to-one relationships.

This is really a database normalisation issue, where elements are records and attributes are fields. You can pretty much figure out what the 'right' structure is by going through the steps you'd take to normalise a database - and it isn't complicated, if you haven't done that before.
Harry.
Personally, I'd say, anything which can only occur once can safely be an attribute. Attributes take up less room than elements and should be used if size is a concern. In some programming environments, attributes might be easier / quicker to work with too.

But

<row c1="0" c2="1" etc...


I consider an anti-pattern and should be avoided.

Mark

This topic is closed to new replies.

Advertisement