Notes on XML, Elements, and Attributes
Post from April 23, 2009 (↻ June 1, 2020), filed under Web Development.
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,
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.
I’m Jens Oliver Meiert, and I’m a web developer (engineering manager) and author. I love trying things, sometimes including philosophy, art, and adventure. Here on meiert.com I share some of my views and experiences.
If you have questions or suggestions about what I write, please leave a comment (if available) or a message.
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 😉.
Have a look at the most popular posts, possibly including:
Perhaps my most relevant book: CSS Optimization Basics (2018). Writing CSS is a craft. As craftspeople we strive to write high quality CSS. In CSS Optimization Basics I lay out some of the most important aspects of such CSS. Available at Amazon, Google Play Books, and Leanpub.
Looking for a way to comment? Comments have been disabled, unfortunately.