Network Working Group M. Amundsen
Internet-Draft Layer 7 Technologies
Expires: July 15, 2014 L. Richardson
January 20, 2014

Application-Level Profile Semantics (ALPS)
draft-amundsen-richardson-alps-00.C

Abstract

This document describes ALPS, a data format for defining simple descriptions of application-level semantics, similar in complexity to HTML microformats. An ALPS document can be used as a profile to explain the application semantics of a document with an application-agnostic media type (such as HTML, HAL, Collection+JSON, or Siren). This increases the reusability of profile documents across media types.

Editorial Note (To be removed by RFC Editor)

Distribution of this document is unlimited. Comments should be sent to the IETF Media-Types mailing list (see https://www.ietf.org/mailman/listinfo/media-types).

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 http://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 July 15, 2014.

Copyright Notice

Copyright (c) 2014 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 (http://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

This document describes ALPS, a media type for defining simple descriptions of application-level semantics, similar in complexity to HTML microformats. These descriptions contain both human-readable and machine-readable explanations of the semantics.

An ALPS document can be used as a profile to explain the application semantics of a document with an application-agnostic media type (such as HTML, HAL, Collection+JSON, or Siren).

This document identifies a registry for ALPS documents, and sets a standard for creating and registering ALPS document identifiers with that registry.

This document also identifies a registry for normative human-readable instructions on applying an ALPS document as a profile to a document with a given media type. It sets a standard for registering media types with that registry. It gives some non-normative examples in which a single ALPS document is applied as a profile to documents with different media types.

This document registers two media-type identifiers with the IANA: 'application/alps+xml' ("ALPS+XML") and 'application/alps+json' ("ALPS+JSON").

1.1. Notational Conventions

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 [RFC2119].

1.2. Motivation

When implementing a hypermedia client/server application using a general media type (HTML, Atom, Collection+JSON, etc.), client and server instances need to share an understanding of domain-specific information such as data element names, link relation values, and state transfer parameters. This information is directly related to the application being implemented (e.g. accounting, contact management, etc.) rather than the media type used in the representations.

1.2.1. Describing Domain-Specific Semantics

Instead of creating and registering an entirely new media type (i.e. 'application/accounting'), representation authors can create an ALPS document that describes a "profile" of the target domain; one that explains the vital domain-specific semantic descriptors and state transitions. This profile can then be consistently applied to a wide range of media types by server implementors and successfully consumed by client applications. The focus on defining application-level semantics, independent of transfer protocol or media type, makes it possible to serve application-specific representations using an application-agnostic media type.

1.2.2. ALPS-based Server Implementations

Server implementors can use ALPS documents as a basis for building domain-specific solutions without having to create their own custom media type or re-invent the vocabulary and transition set for a common domain (e.g. accounting, microblogging, etc.). Using a preexisting ALPS profile as a guide, servers can map internal data to commonly-understood semantic descriptors and state transitions, increasing the likelihood that existing client applications (those who share the same understanding of the ALPS document) will be able to successfully interact with that server.

1.2.3. ALPS-based Client Implementations

Armed with a document's ALPS profile, client applications can identify the link relations and semantic descriptors within the document. Client applications can "code for the profile" and better adjust to detailed changes to the response layout, or even the wholesale replacement of one media type with another.

1.3. A Simple ALPS Example

Below is an ALPS document that describes elements of a simple request/response interaction in a contact management application. The profile defines a semantic descriptor called "contact", and three subordinate descriptors ("fullName", "email", and "phone").

The ALPS document also defines a single, safe state transition, to be represented by a hypermedia control (e.g. HTML.GET form) with the 'id' value of "collection." This hypermedia control has one input value ("nameSearch"). When executed, the response will contain one or more "contact" type items.

 <alps version="1.0">
    <doc format="text">
        A list of contacts
    </doc>

    <!-- a hypermedia control for returning contacts -->
    <descriptor id="collection"
        type="safe"
        rt="contact">
        <doc>
            simple link/form for getting a list of contacts
        </doc>
        <descriptor id="nameSearch"
            type="semantic"
            <doc>
                input for search form
            </doc>
        </descriptor>
    </descriptor>

    <!--  a contact: one or more of these may be returned -->
    <descriptor id="contact" 
        type="semantic">
        <descriptor id="item"
            type="safe">
            <doc>
                link to individual contact
            </doc>
        </descriptor>
        <descriptor id="fullName" 
            type="semantic"" />
        <descriptor id="email"
            type="semantic" />
        <descriptor id="phone"
            type="semantic"/>
    </descriptor>

</alps>
               

Implementing the ALPS profile above requires implementing the descriptors defined by the ALPS document. In this case, there are two "top level" descriptors: the safe state transition ("collection") and the semantic descriptor "contact". Below is a single HTML document that shows both these elements in a representation.

<html>
    <head>
        <link rel="profile" href="http://alsp.io/profiles/contact" />
        <link rel="type" href="http://alps.io/profiles/contact#contact" />
    </head>
    <body>
        <form class="collection"
            method="get" 
            action="http://example.org/contacts/">
            <label>Name:</label>
            <input name="nameSearch" value="" />
            <input type="submit" value="Search" />
        </form>

        <table class="contact">
            <tr>
                <td>
                    <a href="http://example.org/contacts/1" rel="item">
                        <span class="fullName">Ann Arbuckle</span>
                    </a>
                </td>
                <td>
                    <span class="email">aa@example.org</span>
                </td>
                <td>
                    <span class="phone">123.456.7890</span>
                </td>
            </tr>
            
            <tr>
                <td>
                    <a href="http://example.org/contacts/100" rel="item">
                        <span class="fullName">Zelda Zackney</span>
                    </a>
                </td>
                <td>
                    <span class="email">zz@example.org</span>
                </td>
                <td>
                    <span class="phone">098.765.4321</span>
                </td>
            </tr>
        </table>
    </body>
</html>
              

HTML representations implement most ALPS elements using HTML's "class" attribute. The "collection" ID has become the CSS class of an HTML form's submit button. The "contact" ID has become the CSS class of an HTML table. The subordinate descriptors "fullname","email", and "phone"

This HAL document uses the same profile to express the same application-level semantics as the HTML document.

<resource href="http://example.org/contacts/">
    <link rel="type" href="http://alps.io/profiles/contacts#contact" />
    <link rel="collection" 
        href="http://example.org/contacts/{?nameSearch}"
        templated="true" />
    <resource rel="item" href="http://example.org/contacts/1">
        <link rel="type" href="http://alps.io/profiles/contacts#contact" />
        <fullName>Ann Arbuckle</fullName>
        <email>aa@example.org</email>
        <phone>123.456.7890</phone>
    </resource>
    <resource rel="item" href="http://example.org/contacts/100">
        <link rel="type" href="http://alps.io/profiles/contacts#contact" />
        <fullName>Zelda Zackney</fullName>
        <email>zz@example.org</email>
        <phone>987.664.3210</phone>
    </resource>
</resource>
                    

In a HAL representation, all state transitions ("collection" and "item", in this case) are represented as link relations. All data descriptors ("fullName", "email", and "phone") are represented as XML tags named after the descriptors.

This Collection+JSON document uses the ALPS profile to express the same application-level semantics as the HTML and HAL documents.

{
    "collection" : {
        "version" : "1.0",
        "href" : "http://example.org/contacts/",

        "links" : [
            {
                "rel" : "profile", 
                "href" : "http://alps.io/profiles/contacts"
            },
            {
                "rel" : "type", 
                "href" : "http://alps.io/profiles/contacts#contact"
            }
        ],

        "queries" : [
            {
                "rel" : "collection", 
                "rt" : "contact", 
                "href" : "http://example.org/contacts/",
                "data" : [
                    {
                        "name" : "nameSearch", 
                        "value" : "", 
                        "prompt" :  "Search Name"
                    }
                ]
            }
        ],

        "items" : [
            {
                "href" : "http://example.org/contacts/1",
                "rel" : "item",
                "rt" : "contact",
                "data" : [
                    {"name" : "fullName", "value" : "Ann Arbuckle" },
                    {"name" : "email", "value" : "aa@example.org" },
                    {"name" : "phone", "value" : "123.456.7890" }
                ],
                "links" : [
                    {
                        "rel" : "type", 
                        "href" : "http://alps.io/profiles/contacts#contact"
                    }
                ]
            },
            {
                "href" : "http://example.org/contacts/100",
                "rel" : "item",
                "rt" : "contact",
                "data" : [
                    {"name" : "fullName", "value" : "Zelda Zackney" },
                    {"name" : "email", "value" : "zz@example.org" },
                    {"name" : "phone", "value" : "987.654.3210" }
                ],
                 "links" : [
                    {
                        "rel" : "type", 
                        "href" : "http://alps.io/profiles/contacts#contact"
                    }
                ]
            }
        ]
    }
}
                
               

The descriptor "collection" has become the link relation associated with a Collection+JSON query. The descriptors "fullName", "email", and "phone" have become the names of key-value pairs in the items in a Collection+JSON collection.

1.4. Identifying an ALPS Document

An ALPS vocabulary is identified by a unique URL. The URL MUST resolve to a valid ALPS document. The server MAY use HTTP content negotiation to serve a human-readable description of the ALPS vocabulary to clients that request an HTML representation.

A client SHOULD NOT automatically resolve an ALPS vocabulary URL, to avoid overburdening its server.

All ALPS URLs MUST be unique and all ALPS documents intended for public consumption SHOULD be registered with the ALPS Registry located at (to be specified).

2. ALPS Documents

An ALPS document contains a machine-readable collection of identifying strings and their human-readable explanations. An ALPS document can be represented in either XML or JSON format. This section identifies the general elements and properties of an ALPS document, their meaning, and their use, independent of how the document is represented. [representations] provides specific details on constructing a valid ALPS document in XML and in JSON format.

2.1. Compliance

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

2.2. ALPS Document Properties

The ALPS media type defines a small set of properties. These properties appear in both the XML and JSON formats. Below is a list of the properties that can appear in an ALPS document.

2.2.1. 'alps'

Indicates the root of the ALPS document. This property is REQUIRED, and it SHOULD have one or more 'descriptor' [prop-descriptor] child properties.

Examples:

XML:
<alps>...</alps>
JSON:
{"alps" : ... }

2.2.2. 'doc'

A text field that contains free-form, usually human-readable, text. The 'doc' element MAY have two properties: 'href' [prop-href] and 'format' [prop-format]. If the 'href' property appears it SHOULD contain a dereferencable URL that points to human-readable text. If the 'format' property appears it SHOULD contain one of the following values:

  1. "text"
  2. "html"
  3. "asciidoc"

Any program processing "doc" elements SHOULD honor the "format" directive and parse/render the content appropriately. If the value in the "format" property is not recognized and/or supported, the processing program MUST treat the content as plain text. If no 'format' property is present, the content SHOULD be treated as plain text.

XML:
<doc format="html"> <h1>Date of Birth</h1> <p>...</p> </doc>
JSON:
{"doc" : {"format" : "text" : "value" : "Date of Birth ..."} }

A 'doc' element SHOULD appear as a child of 'descriptor' [prop-descriptor]. When present, it describes the meaning and use of the related 'descriptor'.

XML:
<descriptor ... > <doc>...</doc> </descriptor>
JSON:
{"descriptor" : {...} {"doc" : {"value" : "..."} }

The 'doc' element MAY appear as a child of 'alps' [prop-alps]. When present, it describes the purpose of the ALPS document as a whole.

XML:
<alps> <doc>...</doc> ... </apls>
JSON:
{"alps : "doc" : { "value" : "..."}, ... }

2.2.3. 'descriptor'

One or more 'descriptor' elements SHOULD appear as children of 'alps' [prop-alps]. It may also appear as a child of itself; that is, the 'descriptor' property may be nested.

The 'descriptor' property MAY have either an 'id' [prop-id] or 'href' [prop-href] attribute. It MAY have both. Additionally, the 'descriptor' MAY have any of the following attributes:

  1. 'doc' [prop-doc]
  2. 'ext' [prop-ext]
  3. 'name' [prop-name]
  4. 'type' [prop-type]

If present, the 'href' property MUST be a dereferenceable URL, that points to another 'descriptor' either within the current ALPS document or in another ALPS document.

If 'descriptor' has an 'href' attribute, then 'descriptor' is inheriting all the attributes and sub-properties of the descriptor pointed to by 'href'. When 'descriptor' has a property defined locally, that property value takes precedence over any inherited property value. Since there is no limit to the nesting of elements -- even ones linked remotely -- it is important to process 'all descriptor' chains starting from the bottom to make sure you have collected all the available properties and have established the correct value for each of them.

2.2.4. 'ext'

The 'ext' element can be used to extend the ALPS document with author-specific information. It provides a way to customize ALPS documents with additional properties not covered in this specification. This is an OPTIONAL element.

The 'ext' element has two properties. The 'href' [prop-href] property MUST appear for the 'ext' element. Its value MUST be a URI and the URI SHOULD be resolveable. The 'value' [prop-value] property MAY appear for the 'ext' element. The meaning and use of the value property is described in the document found by dereferencing the 'href' property of the 'ext' element.

Examples:

XML:
<ext href="http://alps.io/ext/directions" value="north south east west" >
JSON:
{"ext" : {"href" : "http://alps.io/ext/directions", value="north south east west"}}

The 'ext' element MAY appear as a child of the following elements:

  1. 'alps' [prop-alps]
  2. 'descriptor' [prop-descriptor]

Since the 'ext' element has no specific meaning within this specification, it MUST be ignored by any application that does not understand its meaning.

Authors who define 'ext' elements SHOULD register these extensions with the ALPS Registry (see [alps-registry]) and use the URI provided by the registry in the 'name' property of their extension.

2.2.5. 'format'

Indicates how the text content should be parsed and/or rendered. This version of the spec identifies three possible values for "format": "text", "html", and "asciidoc." Any other calues for this attribute are undefined and SHOULD be treated as plain text. If the program does not recognize the value of the "format" property and/or the "format" property is missing, the content SHOULD be treated as plain text. This property MAY appear as an attribute of the 'doc' [prop-doc] element.

2.2.6. 'href'

Contains a resolvable URL.

When it appears as an attribute of 'descriptor' [prop-descriptor], 'href' points to another 'descriptor' either within the existing ALPS document or in another ALPS document.

When it appears as an attribute of 'ext' [prop-ext], 'href' points to an external document which provides the defintion of the extension.

When it appears as an attribute of 'link' [prop-link] 'href' points to an external document whose relationship to the current document or 'descriptor' is described by the associated 'rel' [prop-rel] property.

When it appears as an attribute of 'doc' [prop-doc], 'href' points to a document that contains human-readable text that describes the associated 'descriptor' or ALPS document.

2.2.7. 'id'

A document-wide unique identifier for the related element. This MAY appear as an attribute of an 'descriptor' [prop-descriptor].

The value of this attribute will appear within generic representations as the name of a semantic descriptor or hypermedia control (see [instructions] for details). The exception is when a 'descriptor' defines 'name' [prop-name] as well as 'id' [prop-id]. In that case, the value of 'name' contains the name of the semantic descriptor or hypermedia control, and the value of 'id' is just a unique identifier internal to the ALPS document.

When applied to an ALPS document, a URI fragment identifier points to the 'descriptor' with the appropriate 'id'. For example, the fragment identifier "customer" in the URI http://example.com/my-alps-document#customer refers to an ALPS 'descriptor' with 'id' set to "customer".

A relative URL with a fragment identifier (e.g. "#customer") refers to a 'descriptor' within the ALPS document containing the reference.

The complete URI to an ALPS 'descriptor' (including the fragement) forms an "abstract semantic type" identifier. This is a resolvable URI (URL) that can be used to indicate the type of a resource; for instance, it can be used as the value of the IANA-registered link relation "type".

A 'descriptor' that defines a state transition establishes an extension link relation whose name is the unqualified URI of the descriptor. (e.g. rel="http://example.com/#purchased-by") However, within representations that include the defining ALPS document as a profile, the descriptor's 'id' may be used on its own as a registered link relation. (e.g. rel="purchased-by")

For this reason, when selecting 'id' values and defining 'descriptor' semantics, it is important to avoid creating conflicts with existing IANA-registered values. If it is unclear whether a registered link relation in a representation document refers to a relation registered with IANA or a relation registered in an ALPS profile, the semantics of that link are undefined.

2.2.8. 'link'

Identifies a link between the current ALPS element and some other (possibly external) resource. Can be applied to the 'alps' [prop-alps] and the 'descriptor' [prop-descriptor] elements.

The 'link' property MUST define the two attributes 'href' [prop-href] and 'rel' [prop-rel].

2.2.9. 'name'

Indicates the name of the 'descriptor' [prop-descriptor] as found in generic representations. It MAY appear as a property of 'descriptor'.

This is used when the name of the 'descriptor' is used as an 'id' [prop-id] value elsewhere in the ALPS document. For instance, if a single ALPS document defines a semantic descriptor (data element) called "customer" and a safe descriptor (transition element) also called "customer", they can't both have 'id="customer"' in the ALPS document. One of them needs to have some other 'id', and to set 'name="customer"'.

The use of the 'name' property usually indicates an ambiguity in the application semantics. Thus, it SHOULD only be used when creating an ALPS profile that describes an existing design.

2.2.10. 'rel'

Contains a [RFC5988] approved value: either an extension link relation (a URI) or a registered link relation (a short string).

Appears as a property of link [prop-link].

A link relation defined within an ALPS document MAY NOT be used as a registered link relation within the same ALPS document.

2.2.11. 'rt'

(to be spcified)

2.2.12. 'type'

Indicates the type of representation control to which the element is applied. This MUST appear for each element. Four valid values are defined:

"semantic"
A state element (e.g. HTML.SPAN, HTML.INPUT, etc.) or a hypermedia control that triggers a safe, idempotent transition (e.g. HTTP.GET or HTTP.HEAD).
"safe"
A hypermedia control that triggers a safe, idempotent state transition (e.g. HTTP.GET or HTTP.HEAD).
"idempotent"
A hypermedia control that triggers an unsafe, idempotent state transition (e.g. HTTP.PUT or HTTP.DELETE).
"unsafe"
A hypermedia control that triggers an unsafe, non-idempotent state transition (e.g. HTTP.POST).

If no 'type' attribute is associated with the element then the 'type="semantic"' is implied.

2.2.13. 'value'

Contains a string value. It MAY appear as an attribute of the 'doc' [prop-doc] and the 'ext' [prop-ext] elements.

2.2.14. 'version'

Indicates the version of the ALPS specification used in the document. This SHOULD appear as a property of the 'alps' [prop-alps] property. Currently the only valid value is "1.0". If no value appears, then 'version="1.0"' is implied.

2.3. ALPS Representations

An ALPS document may be represented in either XML or JSON format. This section contains notes on how the ALPS elements and attributes appear in each format, along with examples to guide ALPS document authors.

2.3.1. Sample HTML

<!-- sample HTML document -->                    
<html>
    <head>
        <link rel="profile" href="http://alps.io/documents/search" />
    </head>
    <body>
        <form class="search" action="..." method="get">
            <input type="text" name="search" value="..." />
            <select name="resultType">
                <option value="summary" />
                <option value="detailed" />
            </select>
            <input type="submit" />
        </form>
    </body>
</html>                           
                        

Below is a simple HTML document that contains a handful of semantic descriptors and transition instructions. This document was generated from the XML and JSON ALPS documents that follow. Use this HTML document as a guide when evaluating the XML and JSON examples.

2.3.2. XML Representation

2.3.2.1. XML Representation Notes

In the XML version of an ALPS document, the following ALPS properties always appear as XML elements: 'alps' [prop-alps], 'doc' [prop-doc], 'descriptor' [prop-descriptor], and 'ext' [prop-ext]. All other ALPS properties appear as XML attributes.

2.3.2.2. Complete XML Representation

<?xml version="1.0"?>
<alps version="1.0">
    <doc href="http://example.org/samples/full/doc.html" />

    <descriptor id="search" 
        type="safe">
        <doc format="text">
            A search form with two inputs.
        </doc>
        <descriptor href="#resultType" />
        <descriptor id="value"
            name="search" 
            type="semantic">
            <doc>input for search</doc>
        </descriptor>
    </descriptor>

    <descriptor id="resultType"
        type="semantic">
        <doc>results format</doc>
        <ext 
            href="http://alps.io/ext/range" 
            value="summary,detail" />
    </descriptor>
</alps>
                            

Below is an example of an applcation/alps+xml representation.

2.3.3. JSON Representation

2.3.3.1. JSON Representation Notes

When representing ALPS documents in JSON format, the 'descriptor' [prop-descriptor] and 'ext' [prop-ext] properties are always expressed as arrays of anonymous objects - even when there is only one member in the array.

For example:

"descriptor" : [
    {
        "id" : "search",
        "type" : "safe"
        "descriptor" : [
            {"href" : "#value"},
            {
                "id" : "resultType",
                "type" : "semantic",
                "ext" : [
                    {
                        "href" : "http://alps.io/ext/range",
                        "value" : "summary,detail"
                    }
                ]
            }
        ]
    },
    {
        "id" : "#value",
        "type" : "semantic"
    }
]
                  

The 'doc' [prop-doc] property is always expressed as a named object.

For example:

{
    "doc" : {
        "format" : "text", 
        "value" : "Rules are imporant"
    }
}
                  

2.3.3.2. Complete Representation

// http://alps.io/documents/search
{ 
    "alps" : {
        "version" : "1.0",
        "doc" : {
            "href" : "http://example.org/samples/full/doc.html"
        },
        "descriptor" : [
            {
                "id" : "search", 
                "type" : "safe",
                "doc" : {"value" : 
                    "A search form with a two inputs"
                },
                "descriptor" : [
                    {
                        "id" : "value",
                        "name" : "search",
                        "type" : "descriptor",
                        "doc" : {"value" : "input for search"}
                    },
                    {"href" : "#resultType"}
                ]
            },
           {
                "id" : "resultType",
                "type" : "descriptor",
                "description" : {"value" : "results format"},
                "ext" : [
                    {
                        "href" : "http://alps.io/ext/range", 
                        "value" : "summary,detail"
                    }
                ]
            }
        ]  
    }
}
                            

Below is a example of the application/alps+json representation of an ALPS document.

3. Applying ALPS documents to Existing Media Types

An ALPS document can be applied to many existing media types as long as there exists an agreed mapping between ALPS and the target media type. [example] gave some informative examples of this. Normative, up-to-date guidance on applying ALPS documents to existing media types are available at the official ALPS Web site (http://alps.io). [I implied earlier there would be a formal registry. -leonardr]

Not all media types can faithfully represent all ALPS descriptors. For instance, the 'application/json' media type has no standard way of representing hyperlinks. The [details?] of how to apply ALPS to such a media type will necesarily be incomplete, and it will not be possible to represent some aspects of an ALPS profile in documents in that media type.

3.1. Linking to ALPS Documents

To indicate that an ALPS profile describes the semantics of some representation document, the representation document SHOULD be linked to the ALPS document using the "profile" link relation (found in the IANA registry of link relations). If the media type of the representation document has no native ability to link to other resources, or no ability to express link relations, the HTTP header 'Link' [RFC5988] MAY be used to connect the representation document and the ALPS profile. If the media type of the representation document defines a parameter for linking the document to a profile, that parameter MAY be used to connect the representation document and the ALPS profile.

A single representation document may be described by more than one ALPS profile. If two ALPS profiles give conflicting semantics for the same element, the document linked to earlier in the representation SHOULD take precedence. A profile linked to using the 'Link' header takes precedence over a profile linked to within the representation document itself. A profile linked to using a media type parameter takes precedence over a profile linked to using the 'Link' header and a profile linked to within the representation document itself.

4. The ALPS Registry

4.1. What is the ALPS Registry

[TK]

4.2. Searching the Registry

[TK]

4.3. Contributing to the Registry

[TK]

5. IANA Considerations

This specification establishes two media types: 'application/alps+xml' and 'application/alps+json'

5.1. application/alps+xml

Type name:
application
Subtype name:
alps+xml
Required parameters:
None
Optional parameters:
charset
This parameter has identical semantics to the charset parameter of the 'application/xml' media type as specified in [RFC3023].
profile
A whitespace-separated list of IRIs identifying specific constraints or conventions that apply to an ALPS 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 IRIs are dereferenceable and provide useful documentation at that IRI.

Encoding considerations:
binary
Same as encoding considerations of application/xml as specified in [RFC3023].

Security considerations:
This format shares security issues common to all XML content types. It does not provide executable content. Information contained in ALPS documents do not require privacy or integrity services.
Interoperability considerations:
ALPS is not described by a DTD and applies only the well-formedness rules of XML. It should only be parsed by a non-validating parser.
Published specification:
This Document
Applications that use this media type:
Various
Additional information:
magic number(s):
none
file extensions:
.xml
macintosh type file code:
TEXT
object idenfiers:
none

person to contact for further information:
Name:
Mike Amundsen
Email:
mca@amundsen.com

Intended usage:
Common
Author/change controller:
Mike Amundsen

5.2. application/alps+json

Type name:
application
Subtype name:
alps+json
Required parameters:
None
Optional parameters:
profile
A whitespace-separated list of IRIs identifying specific constraints or conventions that apply to an ALPS 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 IRIs are dereferenceable and provide useful documentation at that IRI.

Encoding considerations:
binary
Security considerations:
This media type shares security issues common to all JSON content types. See [RFC4627] Section #6 for additional information. ALPS+JSON does not provide executable content. Information contained in ALPS+JSON documents do not require privacy or integrity services.
Interoperability considerations:
None
Published specification:
This Document
Applications that use this media type:
Various
Additional information:
magic number(s):
none
file extensions:
.json
macintosh type file code:
TEXT
object idenfiers:
none

person to contact for further information:
Name:
Mike Amundsen
Email:
mca@amundsen.com

Intended usage:
Common
Author/change controller:
Mike Amundsen

6. Internationalization Considerations

[TK]

7. Acknowledgements

The following people made contributions to this specification: Mark Foster.

8. References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3023] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[RFC4627] Crockford, D., "The application/json Media Type for JavaScript Object Notation (JSON)", RFC 4627, July 2006.
[RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010.

Index

Authors' Addresses

Mike Amundsen Layer 7 Technologies EMail: mca@amundsen.com URI: http://amundsen.com
Leonard Richardson EMail: leonardr@segfault.org URI: http://crummy.com