tags:

views:

190

answers:

8

In XML, how should a list be represented?

With an enclosing list entity:

<person>
    <firstname>Joe</firstname>
    <lastname>Bloggs</lastname>

    <children>
        <child .../>
        <child .../>
        <child .../>
        <child .../>
        <child .../>
    </children>
</person>

Or without:

<person>
    <firstname>Joe</firstname>
    <lastname>Bloggs</lastname>

    <child .../>
    <child .../>
    <child .../>
    <child .../>
    <child .../>
</person>
+7  A: 

I would enclose it in an entity to distinguish it from the other elements.

Daniel A. White
Agreed for the reason listed by Jason Jackson below.
dacracot
Also, you could have <children type="step"><child .../><child .../></children> and <children type="full">....</children> so you can have lists of different types of children, if you use the enclosing entity.
Eddie
A: 

IMHO, it depends on the domain.

For the example you gave, I would use the entity to enclose the children, because the children themselves are not necessarily properties of the person, but the list of children is.

Additionally, using an enclosure will help if you ever need to serialize/deserialize.

Daniel Schaffer
+1  A: 

The first one would work pretty well for simple lists, but what if the list contained a nested list itself?! What if an element had a couple different lists? To keep things consistent I prefer an element for the list and using an <item> tag or something for child data. This will help using a generic function to parse all lists.

Mehrdad Afshari
+7  A: 

For extensibility, I would use the first solution (the one with the children node). If you ever wish to store any data about all of the children then you have a convenient node on which to place attributes.

Jason Jackson
Good point. I can think of an attribute for children... spouse... so if the child were from another marriage.
dacracot
+2  A: 

It doesn't make a great deal of difference if the names of the elements in the list are always the same, because if you're processing it using XPath or Linq-to-XML or whatever then the query will just have one more selector if there's a wrapper node, but otherwise will be identical.

On the other hand if the element names in the list may differ, then it can make processing the list easier if there is a wrapper element, because you can just use '*' as the selector below the list element rather than having to filter all elements to those with a specified set of names.

So it probably doesn't matter hugely, but I tend to prefer having a wrapper element just because it visually delineates the items in the collection from items that are not.

Greg Beech
+2  A: 

Think of it in code you'd like to write against it.:

To me...

spouse.children = person.children...

is a lot nicer semantically than...

for child in person:
    spouse.addChild(person.child)
Triptych
+1  A: 

If we need a universal XML representation of a list, we will conclude that a kind of the following representation has to be used:

<_listSomeName>
  <_listItem>...</_listItem>
  <_listItem>...</_listItem>
  <_listItem>...</_listItem>
  <_listItem>...</_listItem>
  <_listItem>...</_listItem>
</_listSomeName>

Let's analyze this:

  1. The <_listSomeName> wrapper element is needed because we may have two or more lists as children of an element and must be able to uniquely and conveniently identify each list. The "SomeName" part serves to make a list's name unique.

  2. The <_listItem> element is needed to wrap each individual list item. It cannot be omitted because a list item can have a complex structure (such as being an xml fragment itself) and it would be challenging to identify it as one whole.

Dimitre Novatchev
+1  A: 

I would use the first solution. The list has semantic relevance: it's the collection of like elements, and therefore should be identifiable as such. In the second solution the list doesn't exist as an element.

stevenvh