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

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)

Answer 2

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 3

Although I also have an instinctive preference for wrapped collections, it is interesting to note that Google have a different opinion.

XML elements that merely wrap repeating child elements SHOULD NOT be used. [Rationale: They are not used in Atom and add nothing.]

Answer 4

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 5

If you will need to validate your XML with an XSD and wish to stick to the Venetian Blind style of structuring your XSD with all types explicit, and if you wish to enforce some local attribute uniqueness on those repetitive child elements (eg when mapping to dictionary when deserializing): you will have nowhere to put your xs:key definitions. Those are not allowed under xs:complexType , only under elements. So you will be forced to have an extra container like <books><book/><book/></books> . This is not a conceptual, but a tools limitation.