Sign in to follow this  

XML: Elements vs Attributes

This topic is 4714 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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?

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
Quote:
Original post by HarryW
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.


Thirded :)

Also, elements for things with parent relationships to other data, of course :)

Share this post


Link to post
Share on other sites
Quote:
Original post by RavyneAlso, elements for things with parent relationships to other data, of course :)
Generally that's probably best but I'd say this depends on whether it can be a parent to one other but of data, or many. If it's only one, then I'd put forward a case for using an attribute whose value is the unique identifier for the child element, although it's less readable, and that may be a concern if you want to hand-edit this data.

Share this post


Link to post
Share on other sites

This topic is 4714 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this