What are the benefits of using a container element for lists in XML?

Question

When specifying XML formats containing a list of elements, there is often a choice of two different styles. One uses the container element for the list, the other does not. As an example: when specifying a document with several pages, this can be done:

<document> <title>...</title> <pages> <page>...</page> <page>...</page> </pages> </document> 

Or simply:

 <document> <title>...</title> <page>...</page> <page>...</page> </document> 

What are the advantages and disadvantages of each approach?

Some that I can think of are as follows:

• the first allows you to express an explicit empty list (useful if the list itself is a conceptual object)
• the first is probably a little better for error recovery (although it doesn't matter if XSD checking is used)
• last shorter
• the latter does not require a distinction between adding the first element or any subsequent element (without controlling the container element)

EDIT

To clarify: I assume that the pages element does not make sense. There are no other elements inside, there are no attached attributes, and it is difficult to find any other name than "pages", "pageList" or similar for it.

EDIT 2

I found another entry on the same issue. Although the answer is responsible for the container / parent element, it seems to be suitable for treating the container as an actual object or assuming that it is easier to model the circuit with an additional container element (which I tend to disagree with).

Answer 1

In the example you indicated, the difference is subtle, however, two examples actually represent completely different things :

• The second example is a document with a title and many pages.
• The first example, however, has a document with a title and a set of pages

As I said, in your example the difference is redundant and therefore easy to miss, so instead consider the following minor variations:

 <document> <title>...</title> <contents> <page>...</page> <page>...</page> </contents> <chapter name="chapterName"> <page>...</page> <page>...</page> </chapter> <index> <page>...</page> <page>...</page> </index> </document> 

In this case, the document contains many collections of pages. (Of course, some may argue that you could have presented it differently the same way):

 <document> <title>...</title> <page section="contents">...</page> <page section="chapter1">...</page> <page section="index">...</page> </document> 

However, you would have to change the page element, in the example above, I would say it is worse (why should the page know what it contains?)

Another subtle consideration is that often ordering elements means something:

 <document> <page>...</page> <title>...</title> <page>...</page> <page>...</page> </document> 

In this example, we have (for some reason) a page in front of the heading - obviously not possible with collections. Another consideration is that each collection may also (for example) have a title .

My point is that they represent different things - in fact, this is not the case when pro vs is so suitable for choosing the format that most closely matches your data model.

Answer 2

This is indeed a matter of personal choice, although the first form is more powerful, IMO. t does multiple pages , for example. pages with a different name. It just depends on your requirement.

 <document> <title>...</title> <pages name="page1"> <page>...</page> <page>...</page> </pages> <pages name="page2"> <page>...</page> <page>...</page> </pages> </document>