<link> (deprecated)

<link> (new version)

Expresses a relationship between an Atom entity and another resource.


<!ATTLIST link
    href (#PCDATA) #REQUIRED
    type (#PCDATA)
    title CDATA>

(eg <link rel="alternate" href="" [type="text/html"] [title="This entry's webpage"']>)



The LinkElement is used to express a relationship between a resource identified in an Atom feed and another "external" resource. The Atom resource is normally that associated with the parent of the link element (the link element may also be used to associate a schema name with a namespace, see below). The other resource is identified in the href attribute of the link element. The rel attribute defines the relationship between the two resources.

Relationship Values

The meaning of the rel attribute is determined in one of two ways. For terms defined in the Atom specification, the term may be used directly in the attribute, e.g.

   <link rel="inResponseTo"       type="application/x.atom+xml"       href="" />

The core terms are described at LinkTagMeaning For terms defined outside Atom, additional namespace-based qualification must be used.

Explicit Namespace

This method of defining the relationship uses a technique derived from that described in RFC 2731 (Encoding Dublin Core Metadata in HTML) . First an external schema is identified and its namespace identified with a schema name. This only needs to be done once per feed:



Subsequently the schema may be referred to in individual link entries:



(The # suffixed to the image.jpg url prevents this wiki from automagically displaying the image inline)

Implicit Namespace (Atom Core)

Much of the time the relationship schema used will be that defined in the Atom specification. To simplify the use of this a shorthand can be used. If there is no schema explicitly associated with the content of a rel attribute (using the method described above) then the value of the rel attribute is taken to refer to a term in the Atom namespace.

So this:

<feed> ...



is equivalent to, and will be used in preference to:




The core terms are described at LinkTagMeaning







permalinks or unique identifiers?

Permalinks: When you see a weblog entry, you often want to reference it or respond to it. To do this, you need its permalink. Since we're expecting all weblog entries to be on the Web, a permalink isn't a very onerous requirement. And the permalink is free to refer to a page that's gone 404, not on the public Internet, or on your local machine. The downside is that some innovative feeds (like stock tickers) would have some trouble generating permalinks. If we require one, they'll just make something up, and that can cause problems. And what happens when you have multiple formats (say, HTML, MP3, and Flash)? Which one do you give out as the permalink?

Unique identifiers: A unique identifier lets you figure out when two items are the same, which is quite useful. Database-backed weblog tools like Blogger and Movable Type use numbers (like 2345), not permalinks, to identify posts. They can put those numbers in the unique identifier slot, and get them back in later operations (like when the client wants say what entry it's editing. Plus it allows the permalink to move and change without breaking things, since the unique identifier can stay the same. The unique identifier should be a UniversalResourceIdentifier (URI), so that it has a consistent syntax and is should be globally unique (that way you can see if two items in different feeds are really the same).

For example, imagine you're subscribed to News.tld's tech and politics feeds. They publish a story that runs in both (it's about how the government is moving to OpenBSD). In one feed, the permalink is http://news.tld/tech/1420 and in the other it's http://news.tld/politics/1420 but they both have the same unique identifier.

TimBray is nailing down exactly what a unique identifier is in PostIdSpec.

See EntryIdentifier for an approach that gives a concrete definition of an Echo identifier, that can also support additional attributes for 'publisher-id' (post-id), 'also-at' for categories, and 'mirror' for other locations.


This is a new poll. If you voted in the old poll please vote here for the new, clarified options. Please, votes only, discusion should continue below. Please do not edit or move other people's votes.



[TimBray] I'm trying to focus the post-id debate, will have something [PostIdSpec here] soon.

[KenMacLeod] I hit upon the same idea around the same time too, see EntryIdentifier.

[MichaelBernstein, RefactorOk] Summarizing the discussion, I'd like to propose that entries have a guid required attribute in the form of a URI, that the permalink attribute be dropped, and that if the guid is in the form of a URL, that it be considered a permalink (thus making permalinks optional).

[JoeMadia, RefactorOk] In an attempt to quantify the choices (with data element names changed to protect the innocent):

A) A single required data element called Moe (of type URI) would be defined that acts as both a unique identifier for the item AND as a permalink for the item. This effectively means that Moe must be either http: or https: for the forseeable future and that all items would be assumed to have permanently hosted web pages that contain their content.

B ) A required data element called Larry (of type URI) would be defined that uniquely identifies the item but does not resolve in any meaningful way (as in XML namespaces). An optional data element called Curly (of type URI) would act as the permalink for the item. If Curly was missing then tools would assume that there is no permalink for the item. In the near term, Larry and Curly would be identical in almost all cases.

C) A single required data element called Shemp (of type URI) would be defined that acts as a unique identifier for the item. If it is also a URL then it is also considered a permalink for the item.

D) An optional data element called Abbott would be defined that, when present, acts as the unique identifier for the item. A required data element called Costello would be defined that acts as a permalink for the item. When Abbott is missing then Costello is also assumed to be BOTH the permalink and the unique identifier.

E) A required data element called Pea would be defined that acts as the unique identifier for the item. Another required data element called Carrot would be defined that acts as a permalink for the item.

F) No identifiers mandatory (except of course for the source URI of the feed). Seems to me that a feed without any permalinks at all could have value. Does every verse of a streaming audio song have a URI?


See Glossary.

permanent URL element

a URL that resolves to the resource

unique URI identifier

an identifier of the resource in the form of a URI

Blog entry IDs: Permalinks or other URIs?

This is the old poll, after much discussion more than the simple options presented below were represented, so the new poll had been formulated.

What do you think should be used to identify entries?:

[AaronSw] Someone changed the name of the thing people voted for but its scrolled off the info page. I've tried to correct it to the best of my memory, but please correct it if you see a mistake.

[MichaelBernstein] Consider removing your own vote from the poll above as you vote in the new one. The old poll can be removed once no more votes are recorded there. Please do not edit or move other people's votes.

External Discussion


[ShelleyPowers] Consider the following scenario -- a log entry is also a comment. A log entry is also an entry in an RSS file. A log entry is also a trackback item. When one looks at all the various aspects of 'log entry', then a URL to a blog entry starts to become overly limiting.

[MarkCidade] I think we should make a distinction between PermaLinks (that point to something) and UniqueIdentifiers (that are strictly for identity and don't necessarily point to any location)

[TimBray] I [WWW]went on at tiresome length about this today. An entry is identified by a URI (#fragments OK), because it's part of the web. If they want it to be retrievable via web protocols they'd better use that kind of URI. I think that separately a version stamp is required.

[Skware] I think a clarification needs to be made here about PermaLinks etc. PermaLinks as used by RSS / RDF indicate an AlternativeRepresentation of the entry. It is my proposal that an AlternativeRepresentation tag be used for the purpose of showing a html representation of the Entry on the web. The PermaLink should be a link to a verbatim copy of the Entry as it would appear in any syndicated feed / channel / container / collection / buzzword of the month. A user agent should be able to resolve this and download only the entry indicated. It should be possible for an entry to be associated with multiple PermaLinks, hence a unique entry ID should must be attached to the entry. This may be standardised to be site/yyyy/mm/dd/title, or some such. The only problem is what happens when another weblog uses the same unique ID to fool the user agent into replacing someone else's entry. This is a potential security risk.

[JeremyGray] Voted. Has voting stalled out on this issue? Is it perhaps time for a TrueConsensus call regarding the current leader Peas and Carrots so that we can move forward and focus on issues like PostIdSpec and the retrievability expectations for PermaLinks as illustrated by Skware immediately above this comment?

CategoryModel, CategoryRss