Atom: Multiple links with same rel value

The Atom syntax RFC stays away from specifying too many restrictions on the atom:link element, which is quite useful in a number of scenarios. Here are two that are of immediate value:

1. Atom neither prohibits content inside the link element nor ascribes any particular meaning to it. The hierarchy-ID uses this behavior to allow servers to inline the content of a particular kind of link, with rel=detail, inside the link element. This example has been updated to be valid by the RNG Atom schema. For example:

   <entry xmlns="..." xmlns:h=".../">
<title>A master entry</title>
<id>...</id>
<updated>...</updated>
<author><name>John Doe</name></author>
<content>Some text.</content>
<link rel="self" href="/collection/master1"/>
<link rel="edit" href="/collection/master1"/>

<link rel="detail"
href="/collection/master1/collection">
<h:inline count="0">
<feed xmlns:app="...">
<id>...</id>
<app:collection
href="/collection/master1/collection">
<title>Detail collection</title>
<app:accept h:role="detail">
application/atom+xml;type=entry
</app:accept>
</app:collection>
<link rel="self"
href=""/collection/master1/collection"/>
</feed>
</h:inline>
</link>

</entry>

   The highlighted portion shows an empty detail feed inlined in the master entry. This saves a round-trip and invents minimal new markup.
2. Another use arises when a certain link is repeated a number of times. For example, CMIS shows a good number of such examples where a single folder entry can have children of four different kinds - policies, relationships, documents, and descendants. In another example, this time using Netflix REST API, a Netflix title entry can have children of 7 different kinds - awards, directors, cast, screen formats, episodes, seasons, languages. Each different kind leads to its own feed/collection. So instead of creating dozens of new application specific relation registrations that have no use in any applications besides the one that create them, just provide for a new attribute on atom:link elements to distinguish the kind of content in that link. Heck we could even use the atom's category term attribute for this. Here's an example demonstrating my point.

   <entry xmlns="..." xmlns:h=".../">
<title>A folder entry</title>
<id>...</id>
<updated>...</updated>
<author><name>John Doe</name></author>
<content src="..."/>
<link rel="self" href="/folder;metadata"/>
<link rel="edit" href="/folder;metadata"/>

<link rel="detail" type="application/atom+xml;type=feed"
title="Folder children collection"
href="/folder;contents/" h:kind="contents">
<h:inline count="0"/>
</link>
<link rel="detail" type="application/atom+xml;type=feed"
title="Folder relationships collection"
href="/folder;relationships/" h:kind="relationships">
<h:inline count="0"/>
</link>
<link rel="related" type="application/atom+xml;type=feed"
title="Folder descendants feed"
href="/folder;descendants/" h:kind="descendants">
<h:inline count="0"/>
</link>
<link rel="detail" type="application/atom+xml;type=feed"
title="Folder policy collection"
href="/folder;policies/" h:kind="policies">
<h:inline count="0"/>
</link>
</entry>

   This approach does away with creating new IANA registrations and allows the API developer to control the semantics of the term associated with rel=detail links. Google already uses repeating links with the same rel value in their Google Documents API. They use rel="http://schemas.google.com/docs/2007#parent", but the point is that there is an alternative to inventing new rel values, especially when no new Atom data model semantics are involved.

UPDATE: Julian corrected me in the comments below. So the second example uses h:kind instead of Atom's term attribute.

UPDATE 2: Albert corrected me in the comments below. So the examples above are corrected and do not introduce Atom markup directly under atom:link elements.