Are there hidden advantages to deep XML representations versus shallow representations with intra-document references?

Question

I'm engaged in a debate over XML representations of groups of objects. Given an object hierarchy of entities like Artist, Album and Track, with a high amount of connectivity between the object, what are the pros and cons of formatting the XML representation of a given object graph with deep XML versus using object references.

I'm firmly in the object reference camp, while others content that this model is somehow less 'RESTful' and that it should only be pursued if there's a compelling reason not to use the deep objects version.

I consider the following to be fundamental flaws on the part of deep objects

• Circular references mean there will may be multiple versions of the same object in the graph. Some objects will necessarily be incomplete.
• If you choose to avoid circular references by only having one canonical version of a given object in the graph, you place a burden of implementing the logic to determine which instance in the graph should be treated as canonical. Further, if you're creating a service you place this burden on both clients and servers. Further, this logic has to resolve tons of ambiguities. Which instance of an object should be canonical? The first encountered in pre-order traversal? The closest to the root (breadth first traversal)? A particular parent child relationship?
• There is no canonical representation of a given object, essentially gutting caching opportunities on both the client and the server.
• All logic to get a deep property has to be able to fall back on fetching the containing deep object as a top level item because you never know if the deep property is going to be there
• The schema becomes useless because every connection between objects necessarily has to be set to occur a minimum of 0 times to avoid infinite regression from circular references.

My question is essentially, are there any significant arguments for shallow representation that I've missed, and what are the counter-arguments

Here is a small example of a deep object

<artist id="1234">            <!-- This object is of type Artist in the Schema-->
  <name>Lady GaGa</name>
  <sampleTrack id="1235">     <!-- This object is of type Track in the Schema-->
    <name>Poker Face</name>
    <album id="1236">        <!-- This object is of type Album in the Schema-->
      <name>The Fame Monster</name>
      ...
    </album>
  </sampleTrack> 
  <album id="1236">
    ....
    <track id="1235">
    </track>
  </album>
</artist>

Here is a similar example of using object references

Lady GaGa

<track id="1235">           <!-- This object is of type Track in the Schema-->
  <name>Poker Face</name>
  <album id="1236"/>        <!-- This object is of type Reference in the Schema-->
</track>

<album id="1236">
  <name>The Fame Monster</name>
  <track id="1235">
</album>

Answer 1

In terms of REST where resources can be looked up by URI, I side with you with references. What I've seen people do is use links:

If the following URI can be used to look up an album: - http://www.example.com/albums/1236

Then the XML representation for http://www.example.com/tracks/1235 may look like:

<track id="1235">
  <name>Poker Face</name> 
  <album link="http://www.example.com/albums/1236"/&gt; 
</track> 

Following the album link you would get:

<album id="1236"> 
  <name>The Fame Monster</name> 
  <track link="http://www.example.com/tracks/1235"&gt; 
</album> 

Answer 2

A lot of the xml that I've created is designed to be processed by XSLT stylesheets. Where that is the case, you have an advantage for deep representation, because XSL can much more concisely (and efficiently?) deal with depth relationships than referenced relationships.

That consideration may or may not matter to you. I guess it depends on whether the xml will be parsed as a document tree or not.