RFC 2731 Encoding Dublin Core Metadata in HTML -- an approach for relation names in attribute values that is like XML Namespaces but not using XML Namespaces
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.
A link that is intended primarily for presentation to a human user. (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 (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 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