XML Attributes vs Elements [duplicate]

Question

This question already has answers here:

XML attribute vs XML element (20 answers)

Closed 5 years ago.

When should you use XML attributes and when should you use XML elements?

e.g.

<customData>
  <records>
    <record name="foo" description="bar" />
  </records>
</customData>

or

<customData>
  <records>
    <record>
      <name>foo</name>
      <description>bar</description>
    </record>
  </records>
</customData>

Answer 1

It's largely a matter of preference. I use Elements for grouping and attributes for data where possible as I see this as more compact than the alternative.

For example I prefer.....

<?xml version="1.0" encoding="utf-8"?>
<data>
    <people>
        <person name="Rory" surname="Becker" age="30" />
        <person name="Travis" surname="Illig" age="32" />
        <person name="Scott" surname="Hanselman" age="34" />
    </people>
</data>

...Instead of....

<?xml version="1.0" encoding="utf-8"?>
<data>
    <people>
        <person>
            <name>Rory</name>
            <surname>Becker</surname>
            <age>30</age>
        </person>
        <person>
            <name>Travis</name>
            <surname>Illig</surname>
            <age>32</age>
        </person>
        <person>
            <name>Scott</name>
            <surname>Hanselman</surname>
            <age>34</age>
        </person>
    </people>
</data>

However if I have data which does not represent easily inside of say 20-30 characters or contains many quotes or other characters that need escaping then I'd say it's time to break out the elements... possibly with CData blocks.

<?xml version="1.0" encoding="utf-8"?>
<data>
    <people>
        <person name="Rory" surname="Becker" age="30" >
            <comment>A programmer whose interested in all sorts of misc stuff. His Blog can be found at http://rorybecker.blogspot.com and he's on twitter as @RoryBecker</comment>
        </person>
        <person name="Travis" surname="Illig" age="32" >
            <comment>A cool guy for who has helped me out with all sorts of SVn information</comment>
        </person>
        <person name="Scott" surname="Hanselman" age="34" >
            <comment>Scott works for MS and has a great podcast available at http://www.hanselminutes.com </comment>
        </person>
    </people>
</data>

Answer 2

Personally I like using attributes for simple single-valued properties. Elements are (obviously) more suitable for complex types or repeated values.

For single-valued properties, attributes lead to more compact XML and simpler addressing in most APIs.

Answer 3

The limitations on attributes tell you where you can and can't use them: the attribute names must be unique, their order cannot be significant, and both the name and the value can contain only text. Elements, by contrast, can have non-unique names, have significant ordering, and can have mixed content.

Attributes are usable in domains where they map onto data structures that follow those rules: the names and values of properties on an object, of columns in a row of a table, of entries in a dictionary. (But not if the properties aren't all value types, or the entries in the dictionary aren't strings.)

Answer 4

One of the better thought-out element vs attribute arguments comes from the UK GovTalk guidelines. This defines the modelling techniques used for government-related XML exchanges, but it stands on its own merits and is worth considering.

Schemas MUST be designed so that elements are the main holders of information content in the XML instances. Attributes are more suited to holding ancillary metadata – simple items providing more information about the element content. Attributes MUST NOT be used to qualify other attributes where this could cause ambiguity.

Unlike elements, attributes cannot hold structured data. For this reason, elements are preferred as the principal holders of information content. However, allowing the use of attributes to hold metadata about an element's content (for example, the format of a date, a unit of measure or the identification of a value set) can make an instance document simpler and easier to understand.

A date of birth might be represented in a message as:

 <DateOfBirth>1975-06-03</DateOfBirth> 

However, more information might be required, such as how that date of birth has been verified. This could be defined as an attribute, making the element in a message look like:

<DateOfBirth VerifiedBy="View of Birth Certificate">1975-06-03</DateOfBirth> 

The following would be inappropriate:

<DateOfBirth VerifiedBy="View of Birth Certificate" ValueSet="ISO 8601" Code="2">1975-06-03</DateOfBirth>   

It is not clear here whether the Code is qualifying the VerifiedBy or the ValueSet attribute. A more appropriate rendition would be:

 <DateOfBirth>    
   <VerifiedBy Code="2">View of Birth Certificate</VerifiedBy>     
   <Value ValueSet="ISO 8601">1975-06-03</Value>
 </DateOfBirth>

Answer 5

As a general rule, I avoid attributes altogether. Yes, attributes are more compact, but elements are more flexible, and flexibility is one of the most important advantages of using a data format like XML. What is a single value today can become a list of values tomorrow.

Also, if everything's an element, you never have to remember how you modeled any particular bit of information. Not using attributes means you have one less thing to think about.

Answer 6

My personal rule of thumb: if an element can contain only one of that thing, and its an atomic data (id, name, age, type, etc...) it should be an attribute otherwise an element.