Notes on XML, Elements, and Attributes
Post from April 23, 2009 (↻ February 3, 2017), filed under Web Development.
This and many other posts are also available as a pretty, well-behaved e-book: 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,
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 very 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 the Author
Jens Oliver Meiert is a technical lead and author (sum.cumo, W3C, O’Reilly). He loves trying things, including in the realms of philosophy, art, and adventure. Here on meiert.com he shares and generalizes and exaggerates some of his thoughts and experiences.
If you have any thoughts or questions (or recommendations) about what he writes, leave a comment or a message.
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 😉.