Notes on XML, Elements, and Attributes
Post from April 23, 2009 (↻ June 5, 2021), 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 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, and I’m an engineering lead—currently manager for Developer Experience at LivePerson—and author. I’ve worked as a technical lead for Google, I’m close to W3C and WHATWG, and I write and review books for O’Reilly. 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 a question or suggestion about what I write, please leave a comment (if available) or a message. Thank you!
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 😉.
Maybe this is interesting to you, too:
- Next: The Result of Maturity Is Simplicity
- Previous: Why CSS Needs No Variables
- More under Web Development, or from 2009
- Most popular posts
Looking for a way to comment? Comments have been disabled, unfortunately.
Get a good look at web development? Try The Web Development Glossary (2020). With explanations and definitions for literally thousands of terms from Web Development and related fields, building on Wikipedia as well as the MDN Web Docs. Available at Apple Books, Kobo, Google Play Books, and Leanpub.