This proposal tightens the purpose of the link element by limiting the values of its @rel (and @rev, if adopted) attribute to links primarily intended to be traversed in response to user interaction (clicking, selecting a menu item, etc.). All other types of links must be specified using a different element. Also, the list of acceptable @rel values is to be extendable, but this proposal does not define specifically how.
Related and Conflicting Proposals
See LinkReferences for a comparison matrix of link mechanisms.
Do we want an extensible linking mechanism to enable software agents that don't understand the extension to be able to render extended links without the risk of rendering them in a manner inconsistent with their purpose?
Are there preferable methods for specifying an extensible linking mechanism? (For example, could we say that any element with an href attribute MUST be a Link Construct, with all the specified attributes for Link Constructs, which could be rendered as a user-activatable link to be loaded using GET, and which does not require understanding of any additional attributes in order to process it in an acceptable way?)
Are we satisfied with <link> as it is, with a closed list of @rel values?
Do we want a multiplicity of Link Constructs, or one <link> element whose @rel (ore @rev) attribute determines what it is?
The purpose of link element as it stands is not defined explicitly enough to give guidance for when to suggest additional values for the @rel attribute, and when to use a different element. Several of the proposals which would add legal @rel values or make the legal list extendable would result in link being used for a less well defined purpose. The was discussion on the mailing list (add a link) of how this element was being overloaded to cover too many things. This proposal sets explicit limits for the link element to prevent excessive overloading.
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.
The link element could conceivably be used for any purpose that requires pointing to an internet resource, either within the feed or outside of it. This could include feeds, feed entries, web pages, binary resources, stylesheets, XSL templates, and any number of other things. Allowing such broad usage would have a number of drawbacks. Naming just one example (assuming we allow extensions to define legal @rel values in addition to those enumerated in the spec), when a client encounters a link/@rel value that it does not understand, it would have no basis for deciding whether to ignore it, load the resource automatically, or take a guess at how to present it to the user.
By limiting the use of the link element to specifying hyperlinks intended to be activated by user interaction, we enable Atom clients to render unknown link types without the risk of having their users click through to something that just displays gobbledygook (a stylesheet, an XSL template, etc.)
If other proposals are adopted which add legal values for link/@rel (or link/@rev, if adopted) which are not intended to be activated by explicit user interaction, those @rel values will be removed, and some other element will need to be found or created for them.
Update section 3.4 of the Atom Syndication Format as follows:
'''3.4 Link Constructs''' A Link Construct specifies a hyperlink primarily intended to be traversed in response to an explicit user action such as clicking, selecting a menu item, drag and drop, etc. When retrieving the resource pointed to by the href attribute using HTTP, the GET method MUST be used. It MUST NOT have any child content. The Link Construct has the following attributes: '''3.4.1 "rel" Attribute''' The "rel" attribute indicates the type of relationship that the link represents. Link constructs MUST have a rel attribute, whose value MUST be a string, and MAY either be one of the values enumerated (either "below:", if we move the list into this specification, or "in the Atom API specification <eref>http://bitworking.org/projects/atom/draft-gregorio-09.html</eref>." otherwise) or be defined by an extension. '''Note to extension authors:''' When deciding whether to use an Atom Link Construct in your extension, or whether to use or define a different element, consider the following examples of appropriate usage. Example 1: Link Constructs are different from some uses of HTML's <link> element. If an HTML author intends for a stylesheet to be used to apply styling to an HTML page, they reference it using the HTML <link> tag. If they intend for the visitor to view the stylesheet itself, they reference it using the <a> tag. Link Constructs are to be used only for the <a> tag case. Example 2: To reference an image to be displayed within an HTML document, the <img> tag is used. To point to an image to be displayed by itself, the <a> tag is used. Again, Link Constructs are only to be used for the <a> tag case.
The exact language of the sentence first mentioning extensions should be modified if a specific method of extending the list is selected.
[AntoneRoundy] Some of the proposed @rel values which would need to use a different element include: transform.input, transform.output, icon. It might be good to create a different element for service.post (and therefore other service.* values) too.
[EricScheid] The "clickability" of the link is a tricky bit of spec writing ... other specs refer to "traversal", so maybe that word will help some.
Extension mechanism is now one of the principle issues in determining link markup. Without a corresponding extension mechanism, this Pace cannot be compared to PaceReplaceLinkElement. Once that is done, maybe PaceReplaceLinkElement won't look so "ridiculous" anymore.
This is not a place for discussion. If making a statement beyond simply listing your name, please be extremely brief. Link to a longer message in the mail list archive if needed.