by Uche Ogbuji, principal consultant, Fourthought, Inc. First published by IBM at IBM developerWorks XML (www.ibm.com/developerworks/xml). All rights retained by IBM and the author.

The oldest question asked by adopters of XML is when to use elements and when to use attributes in XML design. As with most design issues, this question rarely has absolute answers, but developers have also experienced a lack of very clear guidelines to help them make this decision. In this article, Uche Ogbuji offers a set of guiding principles for what to put in elements and what to put in attributes.

Several frequently pondered questions of DTD design in SGML have followed the legacy to its offshoot, XML. Regardless of what XML schema language you use, you might find yourself asking:
* When do I use elements and when do I use attributes for presenting bits of information?
* When do I require an order for elements, and when do I just allow arbitrary order?
* When do I use wrapper elements around sequences of similar elements?

In my experience working with users of XML, the first question is by far the most common. In some cases the answer is pretty unambiguous:
* If the information in question could be itself marked up with elements, put it in an element.
* If the information is suitable for attribute form, but could end up as multiple attributes of the same name on the same element, use child elements instead.
* If the information is required to be in a standard DTD-like attribute type such as ID, IDREF, or ENTITY, use an attribute.
* If the information should not be normalized for white space, use elements. (XML processors normalize attributes in ways that can change the raw text of the attribute value.)

Unfortunately, design decisions don't often fall into such neat categories. The question remains how to make the right choice in the gray areas. The usual answer is No single answer is right, use your best judgment. But this is not very helpful for those trying to find their feet with XML. True, even experts do not always agree on what to do in certain situations, but this is no reason not to offer basic guidelines for choosing between XML and attributes.
First I want to comment on two guidelines that I have heard and do not recommend. I have heard Just make everything an element.

The reasons given range from Attributes just complicate things to Attributes can stunt extensibility. But if you do not use attributes, you are leaving out a very important aspect of XML's power, and you're probably better off using some delimited text format.

I have also heard If it is the sort of material you would expect to display in a browser, use element content. The problem with this guideline is that it encourages people to think of XML content design in terms of presentation, two considerations that should not be mixed. I present a very similar guideline in this article, but I express it in terms of the intent of the content, rather than in terms of presentation.

In the rest of this article, I present a set of guidelines that I do recommend when choosing between elements and attributes.
Recommended guidelines

I have divided these guidelines into a set of principles that I think frame the choice between elements and attributes overall. None of the guidelines are meant to be absolute; use them as rules of thumb and feel free to break the rules whenever your particular needs require it. Principle of core content:

If you consider the information in question to be part of the essential material that is being expressed or communicated in the XML, put it in an element. For human-readable documents this generally means the core content that is being communicated to the reader.

For machine-oriented records formats this generally means the data that comes directly from the problem domain. If you consider the information to be peripheral or incidental to the main communication, or purely intended to help applications process the main communication, use attributes. This avoids cluttering up the core content with auxiliary material. For machine-oriented records formats, this generally means application-specific notations on the main data from the problem-domain.

As an example, I have seen many XML formats, usually home-grown in businesses, where document titles were placed in an attribute. I think a title is such a fundamental part of the communication of a document that it should always be in element content. On the other hand, I have often seen cases where internal product identifiers were thrown as elements into descriptive records of the product. In some of these cases, attributes were more appropriate because the specific internal product code would not be of primary interest to most readers or processors of the document, especially when the ID was of a very long or inscrutable format.