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

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 2

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.

Answer 3

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 4

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 eliminated the size significantly)
• Nullable data can be expressed with attribute xsi:nil="true"
• Faster to parse since the parser only looks for elements for user data.

Practical

If you really care about the size of XML, use attribute whenever you can if it is appropriate, Leave the nullable, complex type and node which gonna hold large text value as elements, If you don't care the size of XML or you have compression enable during tranportation, stick with elements. It is more extensible.

Background

In DOT NET, XmlSerializer can serialize properties of objects into either attributes or elements. In the recently 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 a article explains it as well Element vs attribute

Answer 5

You may also want to see the answers to this question I posed a while back. I found the answers useful.