This document describes the ALPS[0] Registry Guidelines. These guidelines are used to set up and manage the ALPS Public Registry (APR). The APR holds a set of publicly available ALPS profiles along with other related material including registered ALPS Extensions. These guidelines may also be used to establish other ALPS registries.


The goal of ALPS profiles is to provide a "shared understanding" of service descriptions for the Web. To this end, ALPS profile documents describe hypermedia interfaces (data elements and state transitions) that are helpful when implementing a services and when implement client applications that will access services.

The goal of ALPS registries is to act as a repository of available ALPS profile descriptions and ALPS extension definitions. When services implement an ALPS profile, they can advertise thier support using the appropriate protocol-level mechanisms (Link headers[2], inline links[3], media type parameters[4], etc.). Client implementations can be programmed to ‘recognize’ and process one or more ALPS profiles. By placing ALPS documents in an available registry, these profiles can be more widely circulated and used as a basis for enabling "serendipitous reuse"[5].

Promoting Reuse

One role of ALPS registries is to make it easy to locate and refer to shared ALPS profiles. A robust ecosystem of registries is important to increasing the re-use of ALPS profiles. By creating common locations where ALPS documents can be found and referenced makes it more likely those profiles and extensions will be re-used.

Single Profile, Mutliple-Use

An ALPS profile is most useful when is describes a service in a way that supports multiple use. In other words, a description that more than one server can implment without making any changes to the ALPS profile. The more often a single ALPS profile is used in an implementation on the Web, the more valuable that singlie profile becomes.

Distributed Descriptions

While profile re-use is important, the ALPS registry model is not meant to enforce a single source for all shared ALPS profiles. These guidelines exist to help anyone who wishes to establish and maintain their own ALPS reigstry for whatever reason (See Guidelines for Establishing an ALPS Registry below).

There are a number of possible reasons for establishing an ALPS registry:

Internal Use

It is possible that some organizations will want to establish their own local ALPS registry for internal use. This is especially valuable during the early design and testing phase of profile documents.

Specific Topics

It is also possible that, over time, ALPS registries will be created to support a specific topic or area of study (e.g. astronomy, commerce, social networking, etc.).


There may be cases where it makes sense to maintain and ALPS registry in order to reduce network latency or improve performace of the runtime applications.


It should be noted that the resolvable URL of an ALPS profile or extension (which includes the registry in which is it located) is the unqiue identifier for that particular document. Copying ALPS documents from one registry to another is actually creating a new ALPS document; essentially ‘forking’ the existing document. For this reason, copying ALPS documents into multiple registries is discouraged.

For whatever the reason, individuals or organizations are free to establish and maintain there own ALPS registries and are strongly encouraged follow the guidelines spelled out in this document.


All ALPS Profile Registries should be maintained in a manner that is consistent with the contents of this document. Each hosted APR should be occasionally reviewed and, as needed, modified in order to stay within the guidelines set out in this document.

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

Compliance Criteria

An ALPS registry 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." All ALPS Registries SHOULD strive to be "unconditionally compliant" implementations (See Compliance Review below).

General Guidelines

There are not many constraints on the creation and maintenance of ALPS Profile Registries (APRs). There are, however, some general guidelines (covered below) that should be followed by those who wish to host APRs. They are:

Open to All

APRs should be open to all. Maintainers should not be ‘gatekeepers’ but should instead be enablers for anyone wishing to contribute


It is important that APRs are stable and reliable services. Application developers will grow to rely on the APRs and they deserve the best possible experience.

Primary Registry

This document charters the creation of at least one ‘primary’ APR and a link to that APR SHOULD appear on the ALPS website.

Additional Registries

This document can also be used as a guide for creating additional APRs. There are not restrictions on who can create or host an APR.

Open to All

The aim of ALPS Profile Registries (APRs) is to provide a collaborative repository for sharing profile and extension documents. Since a key goal for the ALPS specification[0] is to increase "shared understanding" between client and service implementors, an open place where ALPS documents can be shared and referenced is important.

It is also important that the spirit of APRs is one of mutual support. APRs should not become barriers to those who wish to contribute profiles. Those who lead and maintain APR communities should not act as ‘gatekeepers’ or as blocking factors for those who want to contribute profiles. To quote David Clark[6]:

We reject: kings, presidents and voting.

We believe in: rough consensus and running code.[7]

Proceedings of the Twenty-Fourth Internet Engineering Task Force - 1992
— David D. Clark

It is also important to remember that registering profiles and extensions in APRs is RECOMMENDED, but NOT REQUIRED. There may base cases where profiles will be used, but not shared. While this is not within the spirit of ALPS in general, that’s OK.


It is also important that APRs are stable, reliable. Those hosting and maintaining profiles and extensions take on the responsibilty to maintain a service that is both available and responsive. APR maintainers should take all necessary steps to keep their service up and running.

They should also work to reduce the chance of "breakage" for existing profiles and extensions. That means APRs should make it ‘hard’ for authors to modify registered profiles and extensions in ways that will introduce backware incompatibilities. It is RECOMMENDED that maintainers institute review processes that reduce breakage and encourage profile and extension authors to keep this uppermost in mind when creating and updating their ALPS documents.

Primary Registry

This document is a a charter to create at least one ‘primary’ APR to hold as many avaialble profile and extension documents as possible. A link to this primary registry SHOULD appear on the ALPS website ( The role of this primary registry is to act as a place where the spirit of ALPS and the guidelines listed here are promoted and protected. It can also act as a place where those interested in learning more about ALPS and find helpful material and an opportunity to participate in the maintenance of the APR.

Additional Registries

This document is also meant to be a guide to those who with to start their own ALPS Profile Repositories. There is not limit to the number of APRs that may exist. There are no special qualifications needed for those willing to host a repository and there are not permissions needed in order to do so.

However, once an APR is created, those hosting it have a responsbility to continue to maintain it in a responsible and reliable manner. Since it is possible that developers will rely in the APR to serve up ALPS documents in order to keep their applications running properly, APR maintainers have a duty to continue to respond to ALPS document requests well into the future. See Guidelines for Establishing An ALPS Registry for details on the proper creation and maintenance of APRs.

The ALPS Profile Registry

[TK intro what a profile is and how it should be handled here.]

Adding ALPS Documents

[TK describe typical process for adding including data to collect, data to reflect, and support for both XML and JSON representations]

Adding Profile Documents

[TK describe typical process for adding including data to collect, data to reflect, and support for both XML and JSON representations]

Adding Extension Documents

[TK describe typical process for adding including data to collect, data to reflect, and support for both XML and JSON representations]

Tagging ALPS Documents

[TK encourage use of tagging to categorize profiles. not hierarchy, folksonomies references here.]

Searching ALPS Documents

[TK describe ways to search for profiles (tags, titles, doc contents, etc.]

Crawling for ALPS Documents

[TK describe possible support for crawlers that might be created to gather ALPS info and publish it in a searchable form. (does this really go here?)]

Guidelines for Establishing An ALPS Registry

[TK intro into the notion of creating and maintaining an APR.]


[TK announce on the primary list:!forum/alps-io]

Compliance Review

[TK describe process of requesting review on the primary list, what the review should entail, that reviews are *optional*]

Contacts and Support

[TK the primary newgroup and the website are sources of general contact and support. Each registry SHOULD also create their own modes of support and post on the registry web site.]


Appendix A : Frequently Asked Queestions

[TK collect stuff here that deserves response, but doesn't rise to a section in the doc]

Appendix B : Existing Registries

[TK should we start with this or keep this a live page?]