There is no clear documentation/best practice for this, but, consider the alternatives, as you have:

As Element text:

• it can be easier to display the data as xhtml, etc, where the text content is considered text, rather than markup or meta-data.
• there can be more than one. If you need child content with multiple age or name rows, attributes won’t allow this
• if you need row level meta data, you have the option of using the attributes of <name> or <age> for this purpose

As Attributes:

• the XML is more compact
• XSLT and DocTypes are simpler to specify
• you don’t have to worry about whitespace (padding, indenting, line breaks), or other items that can be introduced (comments, PI’s) in PCDATA areas (element text)
• there can be only one! you don’t have to worry about child content containing multiple age attributes.

I have spent a lot of time working with XML, and, in my opinion, for pure data communication, attributes should be used whenever possible. If the XML is likely to be used for presentation (XSLT, xhtml, etc.) then it may be better as text content (but not necessarily).

Principles of XML design: When to use elements versus attributes by Uche Ogbuji from IBM is probably one of the best resources on the matter.

At the core of the decision is that attributes are ‘done’ things. You can’t change them or modify them or nest them. They are order independent and and distinct within the element (you can’t have two of the same thing).

If any of these constraints are things that may change, make the data a child node of the XML.

In your example, you have a person who has a name and an age. I have a first, middle, and last name… and a nickname. And some people have maiden names, multiple middle names, or honorifics – how would you put in John Ronald Reuel Tolkien into such a structure?

And so we have someone who has two middle names that have an order to them. This should clearly show that no, an attribute isn’t the best choice for this.

_{I can’t find it currently, but in the above linked document there is a statement that names are things that require a bit of thought leading to “I hope to expand on the treatment of people’s names in markup in a future article.” If anyone has a lead on this, please leave a comment or edit it into this spot.}

On the other hand, the age is something that has a rather fixed structure (I’d suggest the birthday rather than an integer). As such, representing this information in a well known and understood format makes sense in an attribute. A person has one, and only one birthday and there is no ‘ordering’ to it that you want to preserve.

Uche Ogbuji identifies three core principles in properly designing an xml format. The following are abbreviated quotes from the above linked document.

• Principle of structured information
  If the information is expressed in a structured form, especially if the structure may be extensible, use elements. On the other hand: If the information is expressed as an atomic token, use attributes
• Principle of readability
  If the information is intended to be read and understood by a person, use elements. If the information is most readily understood and digested by a machine, use attributes.
• Principle of element/attribute binding
  Use an element if you need its value to be modified by another attribute

And so, names should elements – they are structured data that is not an atomic token, they are more likely to be read by a human than a computer and they may be modified by another attribute on the name itself.

Dates should be attributes – they are data that is an atomic token, they are more likely the read by a computer than a human (and then transformed into the human’s preferred format if need be), and lastly they are unlikely to be modified by other attributes on them.

Another consideration beyong rolfl’s ones is the number of fields.
More than a small number of attributes becomes a mess, and hard to read (that’s assuming you want your xml to be human readable, but as a programmer you’re going to want to do that for testing at least).

Also, if you expect the data structure of one of the fields to change over time, don’t make it an attribute.
For example, your name field. Maybe in the future this would become

<name>
  <firstName>George</firstName>
  <lastName>Orwell</lastName>
  <maidenName></maidenName>
  <nickName>Robert</nickName>
</name>

If you expect something like that to happen, making it an attribute would mean more refactoring code later.

For the Persons tag, it is normal to have more tags of Person, it makes sense, a list of Persons have some entities, not attributes.

The story is different for Person and its components. A Person doesn’t contain a name, the name is an attribute of the Person, so I’d stick with attributes instead of new tags. Tags are useful when you have repetitive things like Addresses, you can’t do it with attributes.

If we think in HTML context, you don’t have an input with a name tag with a value, do you?