Should I use Elements or Attributes in XML? [duplicate]

Usage of attributes or elements is usually decided by the data you are trying to model.

For instance, if a certain entity is PART of the data, then it is advisable to make it an element. For example the name of the employee is an essential part of the employee data.

Now if you want to convey METADATA about data (something that provides additional information about the data) but is not really part of the data, then it is better to make it an attribute.For instance, lets say each employee has a GUID needed for back end processing, then making it an attribute is better.(GUID is not something that conveys really useful information to someone looking at the xml, but might be necessary for other purposes)

There is no rule as such that says something should be an attribute or a element.

Its not necessary to AVOID attributes at all costs..Sometimes they are easier to model, than elements. It really depends on the data you are trying to represent.

My 0.02 five years after the OP is the exact opposite. Let me explain.

1. Use elements when you're grouping similar data, and attributes ofthat data.
2. Don't use elements for everything.
3. If the data repeats (1 to many), it's probably an element
4. If the data never repeats, and only makes sense when correlated tosomething else, it's an attribute.
5. If data doesn't have other attributes (i.e. a name), then it's an attribute
6. Group like elements together to support collection parsing (i.e. /xml/character)
7. Re-use similar element names to support parsing data
8. Never, ever, use numbers in element names to show position. (i.e. character1, character2) This practice makes it very hard to parse (see #6, parsing code must /character1, /character2, etc. not simply /character.

Considered another way:

• Start by thinking of all your data as an attribute.
• Logically group attributes into elements. If you know your data, you'll rarely need to convert attribute to an element. You probably already know when an element (collection, or repeated data) is necessary
• Group elements together logically
• When you run into the case the you need to expand, add new elements / attributes based on the logical structure an process above. Adding a new collection of child elements won't "break" your design, and will be easier to read over time.

For example, looking at a simple collection of books and major characters, the title won't ever have "children", it's a simple element. Every character has a name and age.

    <book title='Hitchhiker&apos;s Guide to the Galaxy' author='Douglas Adams'>        <character name='Zaphod Beeblebrox' age='100'/>        <character name='Arthur Dent' age='42'/>        <character name='Ford Prefect' age='182'/>    </book>    <book title='On the Road' author='Jack Kerouac'>        <character name='Dean Moriarty' age='30'/>        <character name='Old Bull Lee' age='42'/>        <character name='Sal Paradise' age='42'/>    </book>

You could argue that a book could have multiple authors. OK, just expand by adding new author elements (optionally remove the original @author). Sure, you've broken the original structure, but in practice it's pretty rare, and easy to work around. Any consumer of your original XML that assumed a single author will have to change anyway (they are likely changing their DB to move author from a column in the 'book' table to an 'author' table).

<book title='Hitchhiker&apos;s Guide to the Galaxy'>    <author name='Douglas Adams'/>    <author name='Some Other Guy'/>    <character name='Zaphod Beeblebrox' age='100'/>    <character name='Arthur Dent' age='42'>    <character name='Ford Prefect' age='182'/></book>

Not least important is that putting things in attributes makes for less verbose XML.

Compare

<person name="John" age="23" sex="m"/>

Against

<person>    <name>        John    </name>    <age>        <years>            23        </years>    </age>    <sex>        m    </sex></person>

Yes, that was a little biased and exaggerated, but you get the point