I could have sworn I'd written about this before. The question has arisen on the AtomPub WG mailing list of whether the <link> element should be dumped and replaced by a number of different elements based on <link>'s @rel values. Ah, and so I have written about it before, on the wiki. Here's a relevant excerpt:

At the most extreme end, an XML format could conceivably have only a single element, the meaning of which would be determined by its attributes, which would be numerous. For example:

<element name="link" rel="start" href="http://..." title="Spongebob" type="text/html" />

On the other end of the spectrum, a format could have a different element for every conceivable purpose. For example:

<startlink href="http://..." title="Start of this feed" />
<nextlink href="http://..." title="Next 20 entries" />
<htmllink href="http://...html" title="Some webpage" />
<pdflink href="http://...pdf" title="A PDF document" />

Either extreme is, of course, ridiculous. The question is how to find the optimal balance between the two.

Rather than addressing the issue at hand in the abstract, I'll illustrate by continuing with the discussion of <link>.

The link element is, to be sure, a festering breeding ground for abuse of attributes to differentiate between different things. The world wide web is, as the name says, a world wide web of interconnected documents. There are a lot of different types of things to link to out there, and a lot of different reasons to be linking to them. Shoving all of those links into a single element would naturally get pretty messy.

One solution, the one I proposed, was to reign in the meaning of the link element by specifying that it be used to point to things that might logically be rendered as clickable links. You don't usually want a user to click on a link to your stylesheet--you want their browser to load that behind the scenes--so you'd point to that with some other element. But you might want the use to click on a link to the webpage that your blog entry refers to, so link would be appropriate for that.

The question then is whether limiting <link> to things you want people to be able to click through to is enough. Even with that limitation, the list could get pretty long: alternate (another representation of the same material); start, prev and next (the first, previous and next portions of the current feed), related (anything related to the current entry), origin (where this entry came from), reply (a place to go to reply to the current entry), and the list goes on.

Personally, I don't have a problem with this list. Some others, whose job is to index all of this, apparently do. I can see their point. But do we really want a gazillion different elements for pointing to each kind of thing? Do we want to throw <link> out completely, or keep it's use limited, considering whether to add a new @rel value for new uses on a case-by-case basis? Do we want extensions to be able to define their own @rel values for <link>? We'll see what happens.