UserPreferences

LinkReferences


The scope of links currently under discussion are "resource relationships", particularly between an atom:feed or atom:entry and some other resource; the scope is not links embedded in content, although some of those links may be "raised" to appear in an atom:entry, for example.

Terminology

hyperlink

A link that is intended primarily for presentation to a human user. ([WWW]source) Contrast to an <img> link, where the link itself is not presented to the user, but the resource at the link is presented to the user.

URI reference, link

An explicit relationship between resources or portions of resources ([WWW]source). Note: in Atom conversation, some people refer to a "link" in the sense of a hyperlink.

linking element

An XML element that asserts the existence of a link (Atom localized from [WWW]source)

relation name

The name that distinguishes one relationship from another, such as "service.feed", "alternate", "parent". The relation name can be encoded as a value of a "rel" attribute or as an element name. The relation may be from a fixed set of values (enumeration), or extensible through a variety of means. Relation name is equivalent to the "arcrole" (and "role"?) attribute in XLink and property names in RDF.

relation type

The kind or behavior of a link, such as "hyperlink", "service link", "embed". The relation type in format-00 is undefined. XLink and SkunkLink make relation types explicit. PaceServiceElement proposes different elements for relation type, while using the "rel" attribute (or its equivalent) for relation name. Relation type includes the "type", "show", and "actuate" attributes of XLink.

Link proposal matrix

From [ atom-syntax Antone Roundy 19 Jul 2004 ]

Facet \ Proposal PaceLinkAttrDefaults PaceLinkPurpose PaceReplaceLinkElement PaceExtensionNamespace
1. How new links are defined add new @rel value to the core specification (currently enumerated in the API spec) New @rel values are added to the core, or by some not-yet-specified extension method. Whether in the core or a new namespace, new Link Constructs get a new element name. Whether in the core or a new namespace, new Link Constructs get a new element name.
2. Name collision Because extensions can't create new @rel values, there's no problem with name collision. Unknown (see #1). Because extensions have to use their own namespace, there's no problem with name collision. Because extensions have to use their own namespace, there's no problem with name collision.
3. Default Link Construct processing for unknown types None (unless other proposals like PaceLinkPurpose and PaceServiceElement are adopted). Unknown link relations can be rendered as user-activatable links. None (unless a typing attribute is proposed). Unknown link relations with a atomex:href link type can be rendered as user-activatable links.
4. Unknown Link Construct recognizability The link element is the only Link Construct, so it's immediately recognizable, but that may or may not be useful depending on what happens with #3. The link element is the only Link Construct, so it's immediately recognizable. Unknown, but not useful anyway because of the answer to #3. Link Constructs are recognized by the existence of an atomex:href attribute.

Link wiki pages

PaceServiceElement
ExtensibilityFramework