Extended Link Relationships
draft-montoya-xrel-00

Abstract

This document defines XREL, a data format for describing extended hypermedia relationships identified by Uniform Resource Locators.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on August 30, 2019.

Copyright Notice

Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 1.1. Definitions and Terminology
• 1.1.1. Terminology and Conformance Language
• 1.1.2. General
• 1.1.3. Documents description
• 1.2. Motivation
• 2. XREL Documents
• 2.1. Format
• 2.2. Relationship Object
• 2.2.1. Properties
• 2.3. XREL Document
• 2.3.1. Document Example
• 2.4. XREL Collection Document
• 2.4.1. Document Example
• 2.5. Identifying XREL Documents
• 2.6. Fragment identifiers
• 2.7. Identifying XREL Relationships
• 3. IANA Considerations
• 3.1. application/xrel
• 4. Appendix A. Acknowledgments
• 5. Appendix B. Frequently Asked Questions
• 5.1. How can I submit comments or feedback to the editors?
• 5.2. Why not include target attributes as defined by RFC8288 ‘Web Linking’?
• 6. References
• 6.1. Normative References
• 6.2. Informative References
• Author's Address

1. Introduction

This document defines XREL, a data format for describing extended hypermedia relationships identified by Uniform Resource Locators.

This document registers a media-type identifier with the IANA: application/xrel. This registration is for community review and will be submitted to the IESG for review, approval, and registration with IANA.

1.1. Definitions and Terminology

1.1.1. Terminology and Conformance Language

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

1.1.2. General

Representational State Transfer, or REST, is an architectural style for distributed hypermedia systems. Introduced and first defined in 2000 in Chapter 5, REST, of the doctoral dissertation “Architectural Styles and the Design of Network-based Software Architecture” by Roy Fielding.

Hypermedia, or hypertext, is defined by the presence of application control information embedded within, or as a layer above, the presentation of information. Hypermedia allows for a virtually unbound network of resources while also guiding users through an application as they navigate said relationships.

A hypermedia relationship, also known as a link relation, describes the semantics behind a virtual uni-directional association between two resources.

A hypermedia relationship name is an identifier for a hypermedia relationship.

A resource is the intended conceptual target of a hypertext reference.

Representational state indicates the current state of the requested resource, the desired state for the requested resource, or the value of some other resource, such as a representation of the input data within a client’s query form, or a representation of some error condition for a response.

Application state is the state of the user’s application of computing to a given task, controlled and stored by the user agent and can be composed of representations from multiple servers.

This document and the specification documented in it are heavily influenced by the RAML 1.0 Spec.

1.1.3. Documents description

A trailing question mark, for example description?, indicates an optional property.

Throughout this specification, markdown means GitHub-Flavored Markdown. Tooling MAY choose to ignore some Markdown features to address security concerns.

1.2. Motivation

The Uniform Interface constraint of the REST architectural style dictates that hypermedia be the engine of application state. This means that the state of the application and its potential transitions are dictated by the presence of hypermedia relationships in-band and by the navigation of those relationships by an user (human or automated). In order for users to evaluate and select the appropriate relationships to navigate they must rely on an out-band understanding of relationships by their names.

While humans can derive meaning from relationship names in natural language, automated agents have relied on a central repository of standard names maintained by the Internet Assigned Numbers Authority (IANA). Instead of creating and registering entirely new link relations (i.e. patient, appointment, schedulingService, etc.) with a central repository, authors can choose to create an XREL document; one that explains the vital, perhaps domain-specific, semantics of the relationship and which is identified by an URL controlled by the author.

This decentralization allows for a much lower entry barrier, which is not inconsistent with the general concept of the web, and enables different use cases. For example, a private organization is fully capable of defining their own repository of XREL definitions outside of the open Internet, after all standards are a byproduct of authority. Conversely, public XREL definitions would allow for serendipitous reuse, where useful relationships backed by stable URLs might be discovered and possibly become de facto standard.

2. XREL Documents

2.1. Format

Following RAML conventions, XREL documents are YAML documents. The file extension .yaml SHALL be used to designate files containing XREL documents.

This specification uses YAML 1.2 as its underlying format. YAML is a human-readable data format that aligns well with the design goals of this specification. As in YAML, all nodes such as keys, values, and tags, are case-sensitive.

To facilitate the automated processing of XREL documents, XREL imposes the following restrictions and requirements in addition to the core YAML 1.2 specification:

• The first line of a XREL file consists of a YAML comment that specifies the XREL version and document type. Therefore, XREL processors cannot completely ignore all YAML comments.

2.2. Relationship Object

Explains the semantics of a hypermedia relationship.

2.2.1. Properties

2.3. XREL Document

Defines a single Relationship Object.

The first line of a XREL document MUST begin with the text #%XREL 1.0 followed by nothing but the end of the line.

2.3.1. Document Example

#%XREL 1.0

description: Refers to an event scheduling service resource related to the context resource.

2.4. XREL Collection Document

Defines a map where the keys are the document scoped relationship names and the values are Relationship Objects. XREL Collections can be used to combine any collection of Relationship Objects.

The first line of a collection document MUST begin with the text #%XREL 1.0 Collection followed by nothing but the end of the line.

2.4.1. Document Example

#%XREL 1.0 Collection

schedulingService:
  description: Refers to an event scheduling service resource related to the context resource.
patient:
  description: Refers to a patient resource related to the context resource.

2.5. Identifying XREL Documents

XREL documents are identified by unique URLs, this URL SHOULD be dereferenceable.

In order to reduce load on servers responding to XREL document requests, it is RECOMMENDED that servers use cache control directives that instruct client apps to locally cache the results. Clients making these XREL document requests SHOULD honor the server’s caching directives.

2.6. Fragment identifiers

When applied to an XREL document, a URI fragment identifier MUST be a JSON Pointer and be computed as such.

2.7. Identifying XREL Relationships

In the case of XREL Documents as specified in Section 2.3, the URL that identifies that document also identifies the hypermedia relationship described in that document. For example, if the document example in Section 2.3.1 is served at http://docs.example.org/xrels/shedulingService then this URL is the identifier for the relationship described in that document.

In the case of XREL Collection Documents as specified in Section 2.4, fragment identifiers MUST be used for the relationships objects described in that document. For example, if the document example in Section 2.4.1 is served at http://docs.example.org/xrels/clinical then http://docs.example.org/xrels/clinical#/shedulingService and http://docs.example.org/xrels/clinical#/patient identify the first and second Relationship Object, respectively.

3. IANA Considerations

This specification establishes the media type application/xrel for community review and will be submitted to the IESG for review, approval, and registration with IANA.

3.1. application/xrel

Type name: application

Subtype name: xrel

Required parameters: none

Optional parameters:

• profile:: A whitespace-separated list of URIs identifying specific constraints or conventions that apply to an XREL document. A profile must not change the semantics of the resource representation when processed without profile knowledge, so that clients both with and without knowledge of a profiled resource can safely use the same representation. The profile parameter may also be used by clients to express their preferences in the content negotiation process. It is recommended that profile URIs are dereferenceable and provide useful documentation at that URI.

Encoding considerations:

• binary: Because of YAML’s relation to JSON the same encoding considerations of application/json as specified in JavaScript Object Notation apply.

Security considerations:

• Because of YAML’s relation to JSON this format shares security issues common to all JSON content types. The security issues of JavaScript Object Notation, section 6, should be considered.

Interoperability considerations: none

Fragment identifier considerations:

• Fragment identifiers are to be computed as defined by the JSON Pointer specification.

Published specification: This Document

Applications that use this media type: Various

Additional information:

• magic number(s): none

• file extensions: .yaml

• macintosh type file code: TEXT

• object idenfiers: none

Person to contact for further information:

• Name: Jose Montoya

• Email: jmontoya@ms3-inc.com

Intended usage: Common

Author/change controller: Jose Montoya

4. Appendix A. Acknowledgments

Many thanks to Mike Amundsen, Jeff Michaud, Stu Charlton, Eric Wilde and Darrel Miller for their contributions in this space, even if not directly related to XREL documents.

5. Appendix B. Frequently Asked Questions

5.1. How can I submit comments or feedback to the editors?

The issues list for this draft can be found at https://github.com/phtal-org/internet-draft-xrel/issues. For additional information, see https://phtal-org.github.io/internet-draft-xrel/.

To provide feedback, use this issue tracker, the communication methods listed on the homepage, or email the document editors.

5.2. Why not include target attributes as defined by RFC8288 ‘Web Linking’?

Link relations are universal, they describe an association to a conceptual target and not the targets themselves nor their representations. It is the responsibility of the application authors to communicate to their clients what data types are necessary to navigate a relationship and/or the data types that might be expected as a result.

This level of abstraction has value because it’s easier to standardize representations (HTML Microformats, RAML data types, etc.) and link relations than it is to standardize objects and object-specific interfaces. Application servers are free to combine representations and link relations in any way they wish and to provide them in any order, all while remaining understandable to the client.

6. References

6.1. Normative References

6.2. Informative References

Author's Address