Notes on XML, Elements, and Attributes

Published on April 23, 2009 (↻ February 5, 2024), filed under Web Development (RSS feed for all categories).

This and many other posts are also available as a pretty, well-behaved ebook: On Web Development.

Contrary to what one might expect, I’m not bringing in much XML design experience with my occasional contributions to the HTML 5 specification. However, knowledge of the design of markup languages is something I consider beneficial for my job as a web professional as well. A few notes on XML design, inspired by internal and external documentation:

• Attributes mean more restrictions than elements. Every XML design contains some elements. An XML design that only features elements is simplest, but not necessarily most appropriate.

• Elements are handy if data are exposed to the user. If these data are not shown, using an attribute might be more useful.

• Elements should be used when information is represented that can be considered an independent object, and when there is some kind of parent and child relationship.

• Several occurrences in a data model are often better handled by elements rather than attributes. This avoids enumerated attributes like, for instance, foo1, foo2, foo3, &c.

• To order data, elements are more useful than attributes. Attributes are “inherently unordered.”

Update (November 27, 2014)

I found Uche Ogbuji’s article on principles of XML design useful, too. For example:

• The general principle of data going into elements, metadata into attributes.

• The principle of structured information: If the information is expressed in a structured form, especially if the structure may be extensible, use elements. But: If the information is expressed as an atomic token, use attributes.

• The principle of readability: If the information is intended to be read and understood by a person, use elements. But: If the information is most readily understood and digested by a machine, use attributes.

• The principle of element/attribute binding: Use an element if you need its value to be modified by another attribute.

About Me

I’m Jens (long: Jens Oliver Meiert), and I’m a frontend engineering leader and tech author/publisher. I’ve worked as a technical lead for companies like Google and as an engineering manager for companies like Miro, I’m close to W3C and WHATWG, and I write and review books for O’Reilly and Frontend Dogma.

I love trying things, not only in web development (and engineering management), but also in other areas like philosophy. Here on meiert.com I share some of my views and experiences.

If you’d like to do me a favor, interpret charitably (I speak three languages, and they do collide), yet be critical and give feedback for me to fix issues, learn, and improve. Thank you!

Comments (Closed)

1. On April 23, 2009, 23:15 CEST, Steffen said:

   My thoughts on that considering only the information structure aspects of the document:

   As long as the information is and stays flat, I would prefer an attribute for brevity.

   If information is extensible in nature (concerning cardinality and depth) you should opt for an element, which also contributes to simplification of validation (thinking of xsd or dtd).

   That said, I can’t resist to state that the style attribute must be considered as an anti pattern (I know, you will like that, Jens 😉), looking at sth. like style=”a: 1; b: 2; c: url(y) #3 […];’. It’s ignoring the (x/ht)ml grammar and starts a completely new one instead of using means of XML.

   I wonder, if this would still be the design of choice today with the growing popularity of extensible (in terms of namespaces) documents - neglecting all backward compatibility and nostalgic feelings 😉.

2. On April 24, 2009, 15:10 CEST, Jens Oliver Meiert said:

   Interesting, thanks Steffen! Would be lovely to hear some thoughts on that from other HTML WG members—and I can follow, but not comment on the history of @style.