Use a parent XML element as a container for reoccurring child elements?

Question

Let's say you want to allow some particular XML element to occur 0+ times. For example, the <record> element can occur multiple times:

<repository>
  <record>Record 1</record>
  <record>Record 2</record>
  <record>Record 3</record>
</repository>

Are there any compelling reasons to include a parent element as a container for these? For example, the following uses the <recordSet> element to contain the <record> elements:

<repository>
  <recordSet>
    <record>Record 1</record>
    <record>Record 2</record>
    <record>Record 3</record>
  </recordSet>
</repository>

I tried to find any related questions before posing this, so my apologies if it has been asked already. Thanks in advance for any and all input!

---

Edit - July 22, 2009:

Thanks to everyone for the excellent feedback! (I would comment / vote people up, but I don't have enough reputation points quite yet.) I'll probably go ahead with this route, and I also wanted to thank @16bytes for their advice, including to simply name the parent by using the plural of the reoccurring child elements.

Answer 1

Having a parent element makes it simpler to identify sections of the XML and makes it simpler for handlers to map the child elements to a collection. If you have a system that forbids the use of attributes (some do, it's annoying), you also need to use wrapper elements to distinguish properties (such as ids) that belong to particular children.

Other than that it is valid to omit the parent element and can make the file markedly less verbose.

In your first example, a user element could be mingled in with the records, this is valid but it might be hard to spot:

<repository>
  <record>Record 1</record>
  <record>Record 2</record>
  <user>Bill</user>
  <record>Record 3</record>
</repository>

Whereas with a surrounding element you can separate the collection, and have multiple instances of that collection:

<repositories>
  <users>
    <user>Bill</user>
  </users>
  <repository>
    <id>id1</id>
    <recordSet>
      <id>recordSet1</id>
      <record>Record 1</record>
      <record>Record 2</record>
      <record>Record 3</record>
    </recordSet>
    <recordSet>
      <id>recordSet2</id>
      <record>Record 1</record>
      <record>Record 2</record>
      <record>Record 3</record>
    </recordSet>
  </repository>
  <repository>
    <id>id2</id>
    <recordSet>
      <record>Record 1</record>
      <record>Record 2</record>
      <record>Record 3</record>
    </recordSet>
  </repository>
</repositories>

Answer 2

That is useful if in your <repository> you want to allow for multiple <recordSet> elements:

<repository>
  <recordSet id="1">
    <record>Record 1</record>
    <record>Record 2</record>
    <record>Record 3</record>
  </recordSet>
  <recordSet id="2">
    <record>Record 2.1</record>
    <record>Record 2.2</record>
    <record>Record 2.3</record>
  </recordSet>
</repository>

Answer 3

You've stumbled across the second of my XML design guide rules (the first being use attributes only for IDs and real meta data, the third being don't use namespaces unless you know what you're doing) that I try to use when designing xml documents. In addition to being a good rule-of-thumb, it also makes your document:

• easier to model in XML Schema or other validation languages
  • also easier to re-use the complex-type
• easier to read (IMHO)
• easier for users to grok when traversing your document
• (aforementioned) easier to bind to an OOP object of your choice

One suggestion, I would try:

<Root>
   <Items>
     <Item>a</Item>
     <Item>b</Item>
     <Item>c</Item>
   </Items>
</Root>

The simpler "s" suffix is more succinct and easier to remember and apply. If you use a generic collection noun, you or a colleague will forget which one eventually, so you'd see Sets mixed with Lists mixed with Container. But that's more style than good practice and I don't want to start a religious war ;)

(UpperCamel for elements!, lowerCamel for attributes! --sorry)