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

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)

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>

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>

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.]