UserPreferences

LinkingStyles


Atom does [will] define links as "link constructs", and then specify a variety of link relationships that are also extensible. Below are some of the linking styles under discussion.

Atom format-00

Current Atom format-00 style for the <link> element derived from [WWW]HTML 4 document relation links. Atom format-00 also uses <id> and <url> which contain URIs.

<entry>
  <id>tag:example.org,2004:00001</id>
  <link rel="service.edit" type="application/atom+xml" href="http://example.org/001.atom"/>
  <link rel="alternate" type="text/html" href="http://example.org/00001.html"/>
  <author>
    <name>Jane</name>
    <url>http://example.org/~jane</url>
</entry>

PaceReplaceLinkElement

In PaceReplaceLinkElement, "element type" name is the "relation" name. The "rel" attribute of format-00 is moved to the element name, all the other links and Link construct attributes remain as-is.

<entry>
  <id>tag:example.org,2004:001</id>
  <service-edit type="application/atom+xml" href="http://example.org/001.atom"/>
  <alternate type="text/html" href="http://example.org/001.html"/>
  <author>
    <name>Jane</name>
    <url>http://example.org/~jane</url>
</entry>

PaceServiceElement

In PaceServiceElement, the <link> element is reserved for hyperlinks, to be displayed to the user in some manner, and a new element is introduced for "service" link types. Presumes that other elements will be created for other link types.

Replaces "rel" attribute with a "name" attributed. Media type of linked resource is restricted to application/atom+xml (though it's not clearly specified as such).

<entry>
  <id>tag:example.org,2004:001</id>
  <service name="edit" href="http://example.org/001.atom"/>
  <link rel="alternate" type="text/html" href="http://example.org/001.html"/>
  <author>
    <name>Jane</name>
    <url>http://example.org/~jane</url>
</entry>

Extensibility suggestions with @rel

Note that the "relation type" (hyperlink, Atom protocol, embedded) is not part of the @rel "relation name". Some of the Paces are suggesting using a small few new element names to indicate "relation type" (<link>, <service>), while still using an @rel (or equivalent) for the relation name.

Using property names as relation names, attribute names as relation types

The following was posted to atom-syntax by KenMacLeod.

The element name tells you the specific link relation name, but alone doesn't tell you its link class. Is it a human clickable link or an Atom service link.

  <feed atom:id="tag:example.com,2004:main-feed"
        atom:location="http://example.com/main-feed.atom">
    <site atom:id="tag:example.com,2004:site"
          atom:location="http://example.com/site.atom">
      <title>Example Site</title>
      <alternate atom:clickable="http://example.com/"
                 type="text/html"/>
    </site>
    <entry atom:id="tag:example.com,2004:002"
           atom:location="http://example.com/002.atom">
      <author>
        <name>John Q Public</name>
        <link atom:clickable="generic:link"/>
        <ex:homepage atom:clickable="..."/>
        <ex:weblog atom:clickable="..."/>
        <feed atom:service="..."/>
      </author>
      <responds-to atom:uri="tag:example.com,2004:001"
                   atom:location="http://example.com/001.atom"/>
      <origin atom:ref="tag:example.com,2004:site"
              atom:location="http://example.com/site.atom"/>
      <alternate atom:clickable="http://example.com/002.html"
                 type="text/html"/>
      <edit atom:service="http://example.com/002.atom"/>
      <post atom:service="http://example.com/002.atom"/>

"Link classes" ("relation types" in LinkReferences) aren't an "end-all" solution, as certain link classes are *not* suitable for generic processing. Some are however, like clickable links for humans.

Link classes used here:

This is patterned after SkunkLink. atom:clickable appears to have the exact same meaning as SkunkLink's xml:href, if that's useful, but I chose to only mention that here.

This is still thought-experiment territory. There are issues with links that the above addresses, but at the same time it makes them more complex. There are also other potential solutions, such as clustering similar class links under one element, or providing an "introspection" element to indicate specifically what links clients should consider "clickable" (the primary class that can be used in a generic fashion).