Surgical Words

A few years ago when I was learning XML, I struggled to understand the distinction between tags and attributes. I knew what they were, but couldn’t figure out when to use which one. In some instances, both seem appropriate. For example, take a customer record:

<customer>
  <id>4222</id>
  <name>John A. Doe</name>
  <address>123 Beech St., Anytown, USA</address>
</customer>

This is the type and structure of examples given in XML tutorials. However, one could also mark up the data like this:

<customer id="4222" name="John A. Doe" address="123 Anytown, USA"/>

So what, exactly, is the distinction? I realized the obvious after a day of thinking:

Can you have more than one of the item?

This means the first example is wrong. A customer can’t have more than one id, and this is the fatal flaw of the tutorials.

Depending on the complexity of our application, a customer could possibly have more than one name or address, but for the majority of basic database-structured applications, the all-attribute example above is more appropriate.

Regardless of how you go and write XML, be sure not to commit the mistake of differentiating between tags and attributes purely by how deep, or nested, the tag is.

In an application with multiple names and addresss, here’s how I would structure the XML:

<customer id="4442">
  <name first="John" middle="A" last="Calvin" />
  <address title="Home" street="123 Beech St." city="Anytown" country="USA" />
<customer>

Even while writing this example, I automatically started to break the address into tags for street and city. After a second, I realized: an address can only have one street and city.

It’s a hard habit to break.