Introduction

This document defines a new hypertext media type application/lynx+json (a Lynx document), and a related metadata media type application/lynx-spec+json (a Lynx specification), designed to represent and describe documents and the connections among them, with enough semantic detail to allow the development of client applications without imposing strict display constraints or unnecessary coupling between clients and servers. By reducing display constraints and coupling, developers have more freedom to create client applications that take better advantage of the unique characteristics of each platform and device.

Authors

Acknowledgements

We would like to thank the following people for their contributions to this document.

  • Dale Sande
  • Arun Batchu
  • Joe McRae
  • Mark Brose

Conventions Used in This Document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Terminology

JSON

Refers to the media type JSON as defined in RFC 4627.

URI

Refers to a URI as defined in RFC 3986.

URL

Refers to a URL as defined in RFC 3986.

URN

Refers to a URN as defined in RFC 3986.

Media Type Name

Refers to a media type name as defined in RFC 6838.

Base Hint

Refers to one of the following hints: container, link, form, submit, content, and text.

Display

The conveyance of a value to a user in a manner appropriate for the user agent and the user.

Resource

See Section 5.2.1.1 "Resources and Resource Identifiers" in the Fielding Dissertation.

Representation

See Section 5.2.1.2 "Representations" in the Fielding Dissertation.

Compliance

An implementation is "non-compliant" if it fails to satisfy one or more of the MUST or REQUIRED level requirements. An implementation that satisfies all of the MUST or REQUIRED and all of the SHOULD level requirements is said to be "unconditionally compliant"; an implementation that satisfies all of the MUST level requirements but not all of the SHOULD level requirements is said to be "conditionally compliant."

Parameters for application/lynx+json

base

Example

HTTP/1.1 200 OK
Content-Type: application/lynx+json;base="http://example.com/greetings/hello-world"

{
  "value": "Hello, World!",
  "spec": "http://example.com/specs/greeting"
}

realm

  • The parameter is OPTIONAL.
  • If present, its value MUST comply with the rules defined for Realm URI.

Example

HTTP/1.1 200 OK
Content-Type: application/lynx+json;realm="http://example.com/entrance/greeter"

{
  "value": "Hello, World!",
  "spec": "http://example.com/specs/greeting"
}

Parameters for application/lynx-spec+json

None

Interpretation of URI Fragments for application/lynx+json

TODO: provide documentation for how the user agent interprets fragments. This may be here or it may be here or it may be in the "process for displaying content" or another section.

Interpretation of URI Fragments for application/lynx-spec+json

URI fragments MUST be ignored.

Registration Status

The registration status of this media type is as follows:

  • application/lynx+json (unregistered)
  • application/lynx-spec+json (unregistered)

File Extensions

  • .lnx => application/lynx+json
  • .lnxs => application/lynx-spec+json

Documents

While a JSON document may begin with an object or an array, a Lynx document MUST begin with a value/spec pair.

results matching ""

    No results matching ""