XML best practices: attributes vs additional elements

Question

What's the difference between the two and when should I use each:

<person>
     <firstname>Joe</firstname>
     <lastname>Plumber</lastname>
</person>

versus

<person firstname="Joe" lastname="Plumber" />

Thanks

Answer 1

There are element centric and attribute centric XML, in your example, the first one is element centric, the second is attribute centric.

Most of the time, these two patterns are equivalent, however there are some exceptions.

Attribute centric

• Smaller size than element centric.
• Not very interoperable, since most XML parsers will think the user data is presented by the element, Attributes are used to describe the element.
• There is no way to present nullable value for some data type. e.g. nullable int
• Can not express complex type.

Element centric

• Complex type can be only presented as an element node.
• Very interoperable
• Bigger size than attribute centric. (Compression can be used to reduce the size significantly.)
• Nullable data can be expressed with attribute xsi:nil="true"
• Faster to parse since the parser only looks to elements for user data.

Practical

If you really care about the size of your XML, use an attribute whenever you can, if it is appropriate. Use elements where you need something nullable, a complex type, or to hold a large text value. If you don't care about the size of XML or you have compression enabled during transportation, stick with elements as they are more extensible.

Background

In DOT NET, XmlSerializer can serialize properties of objects into either attributes or elements. In the recent WCF framework, DataContract serializer can only serialize properties into elements and it is faster than XmlSerializer; the reason is obvious, it just needs to look for user data from elements while deserializing.

Here an article that explains it as well Element vs attribute

Answer 2

Sometime in the future when you add an <address> property, you won't want to make it an XML attribute. This is because an <address> might be a more complex element made up of street address, city, country, etc.

For this reason, you may want to choose the first subelement form unless you're really sure that the attribute won't need to go much deeper. The first form allows for greater extensibility in the future.

If you're at all concerned about space, compress your XML.

Answer 3

In my company, we would favour the 2nd approach.

The way we think about it is that "firstname" and "lastname" are attributes of the "person" node, rather than sub-fields of the "person" node. It's a subtle difference.

In my opinion the 2nd approach is more concise, and readability/maintainability is significantly improved, which is very important.

Of course it would depend on your application. I don't think there is a blanket rule that covers all scenarios.

Answer 4

I found following information very helpful in explaining the choice of attributes vs elements in a short fashion

Some of the problems with using attributes are:

attributes cannot contain multiple values (elements can)
attributes cannot contain tree structures (elements can)
attributes are not easily expandable (for future changes)

Attributes are difficult to read and maintain. Use elements for data. Use attributes for information that is not relevant to the data.

source : http://www.w3schools.com/xml/xml_attributes.asp

Answer 5

Attributes are not order sensitive. This may be an advantage or a disadvantage depending on your situation.

Attributes cannot be duplicated. If "Joe" has two first names, then nodes are the only way to go.