]> Application-Level Profile Semantics (ALPS)
mamund@yahoo.com http://amundsen.com
leonardr@segfault.org http://crummy.com
mwf@fosrias.com
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, Siren, etc.). This increases the reusability of profile documents across media types. Distribution of this document is unlimited. Comments should be sent to the IETF Media-Types mailing list (see ).
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, Siren. etc.). This document identifies a registry for ALPS documents, (The ALPS Profile Registry or APR). The details of this registry, its goals, and operations are covered in a separate document (TBD). This document also identifies a process for authoring, publishing, and sharing normative human-readable instructions on applying an ALPS document as a profile to responses of a given media type. For example, a document that describes how to apply the semantics of an ALPS profile to an HTML document. This document registers two media-type identifiers with the IANA: 'application/alps+xml' ('ALPS+XML') and 'application/alps+json' ('ALPS+JSON').
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 .
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.
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.
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.
Armed with a document's ALPS profile, client applications can associate the ALPS descriptor 'id' and/or 'name' attribute values with the appropriate elements 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.
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.
A contact list. A simple link/form for getting a list of contacts. Input for a search form. A link to an individual contact. ]]>
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.
Ann Arbuckle 123.456.7890
Zelda Zackney 098.765.4321
]]>
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 the TR elements in an HTML table. The subordinate descriptors 'fullname','email', and 'phone' are rendered as the TD elements of each TR. This HAL document uses the same profile to express the same application-level semantics as the HTML document.
Ann Arbuckle aa@example.org 123.456.7890 Zelda Zackney zz@example.org 987.664.3210 ]]>
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.
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.
An ALPS vocabulary is identified by a unique URL. This URL SHOULD be dereferencable. All ALPS URLs MUST be unique and all ALPS documents intended for public consumption SHOULD be registered in an ALPS Registry [TK: add text on where/how to find registries -mamund]. In order to reduce load on servers responding to ALPS document requests, it is RECOMMENDED that servers use cache control directives that instruct client apps to locally cache the results. Clients making these ALPS document requests SHOULD honor the server's caching directives.
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. provides specific details on constructing a valid ALPS document in XML and in JSON format.
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.'
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.
Indicates the root of the ALPS document. This property is REQUIRED, and it SHOULD have one or more child properties. Examples: <alps>...</alps> { "alps" : ... }
Contains a valid IRI (see ) value that idenfities the source definition of the descriptor. This is a property of the element and it is OPTIONAL. It MAY or MAY NOT be dereferencable. Examples: <descriptor id="title" def="http://schema.org/title" /> { "descriptor" : [ {"id" : "title", "def":"http://schema.org/title" } ]}
A 'descriptor' element defines the semantics of specific data elements or state transitions that MAY exist in an associated representation. One or more 'descriptor' elements SHOULD appear as children of . It may also appear as a child of itself; that is, the 'descriptor' property may be nested. The 'descriptor' element MAY be represented as a single element or it MAY be represented as an array of single elements. The 'descriptor' property SHOULD have either an or attribute. It MAY have both. Additionally, the 'descriptor' MAY have any of the following attributes: If present, the 'def' property SHOULD be a valid IRI (see ) which MAY or MAY NOT be dereferenceable. 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. If 'descriptor' is declared at the top level of an ALPS document, then a client SHOULD assume that 'descriptor' can appear anywhere in a runtime message. If 'descriptor' is nested, i.e. declared as a child of another descriptor, then: A client SHOULD assume them to appear in any sibling 'descriptor' element and recursively in their child descriptors. A client SHOULD NOT assume that it can appear anywhere outside of parent descriptor, unless it was explicitly referenced by another descriptor in 'href' attribute. In that case the same rules are applied to 'descriptor' containing 'href' attribute.
When a representation is generated that includes state transitions, valid values for link relation types are: A registered IANA link relation type (e.g. rel="edit", a short string). An extension link relation type as defined by whose value is the fully-qualified URI of an associated document describing the relation type. This includes URI fragment identifiers of ALPS descriptors (e.g. rel="http://alps.io/profiles/item#purchased-by", a URI) per the conventions of . The 'id' property of a state transition descriptor of an associated ALPS document (e.g. rel="purchased-by", a short string) per the conventions of section and if the representation includes an ALPS profile.
A text field that contains free-form, usually human-readable, text. The 'doc' element MAY be represented as a single element or it MAY be represented as an array of single elements. The 'doc' element MAY have two properties: and . 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: 'text', 'html', 'asciidoc', or 'markdown'. 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.

Date of Birth

...

]]> A 'doc' element SHOULD appear as a child of . When present, it describes the meaning and use of the related 'descriptor'. ... ]]> The 'doc' element MAY appear as a child of . When present, it describes the purpose of the ALPS document as a whole. ... ... ]]>
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 MAY be represented as a single element or it MAY be represented as an array of single elements. The 'ext' element has the following properties. The property is REQUIRED. The is RECOMMENDED and it SHOULD point to documentation that explains the use and meaning of this element. The property is OPTIONAL. The content is undetermined; its meaning and use SHOULD be explained by the document found by de-referencing the property. Examples: <ext id="directions" href="http://alps.io/ext/directions" value="north south east west" > { "ext" : { "id" : "directions", "href" : "http://alps.io/ext/directions", value="north south east west" } } The 'ext' element MAY appear as a child of the following elements: Since the 'ext' element has no specific meaning within this specification, it MUST be ignored by any application that does not understand its meaning.
Indicates how the text content should be parsed and/or rendered. This specification identifies a range of possible values for 'format': 'text', for plain text, MUST be supported. 'html', for HTML, SHOULD be supported. 'asciidoc', for AsciiDoc, MAY be supported. 'markdown', per The text/markdown Media Type, MAY be supported. Any other values 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 element.
Contains a resolvable URL. When it appears as an attribute of a , 'href' points to another 'descriptor' either within the existing ALPS document as a fragment or in another ALPS document as an absolute URL. The URL MUST contain a fragment per referencing the related 'descriptor'. When it appears as an attribute of , 'href' points to an external document which provides the definition of the extension. When it appears as an attribute of , 'href' points to an external document whose relationship to the current document or 'descriptor' is described by the associated property. When it appears as an attribute of , 'href' points to a document that contains human-readable text that describes the associated 'descriptor' or ALPS document.
A document-wide unique identifier for the related element. This SHOULD appear as an attribute of a . It SHOULD be an opaque string that does not contain any URL unsafe characters per . The value of this attribute MAY be used as an identifier in the related runtime hypermedia representation. In the example below the ALPS descriptor with an 'id' of 'q' is used to identify an HTML input element: ]]> ]]> It should be noted that the exact mapping from ALPS elements (e.g. 'id') to elements within a particular media type (HTML, Collection+JSON, etc.) is covered in separate documents (to be specified).
In some cases, media types support non-unique identifiers (e.g. HTML's 'name' property) or will allow the same identifier value for multiple elements in the same representation (e.g. <div id="search" ... /> and <input type="submit" class="search" .../> and <input name="search" ... />). In those cases, translating that representation into ALPS documents could result in multiple 'id' properties with the same value. To avoid this, ALPS document designers can add the property to a 'descriptor' to hold the common value ('search') while still using the property to hold a document-wide unique value. For example:
]]>
]]>
When applied to an ALPS document, a URI fragment identifier points to the 'descriptor' whose 'id' is the value of the fragment. 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'. If the contains URL unsafe characters per , the fragment referencing the 'id' MUST be URL escaped. A relative URL with a fragment identifier within an ALPS document (e.g. href="#customer") refers to a local 'descriptor' within the document containing the reference. The complete URI to an ALPS 'descriptor' (including the fragment) 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 relation type 'type'.
Since a state transition 'descriptor' may define a relation type value, it is important to avoid creating conflicts with existing IANA-registered values. If the resulting link relation type is the same as a registered relation type, the descriptor MUST not change the meaning of the IANA relation type. Further, since the 'id' of a 'descriptor' may define a link relation value per , if a conflict exists in defining such a descriptor's document-wide unique 'id' with another 'descriptor', the conflicting 'descriptor' MUST define a unique 'id' and MAY specify a 'name' property to resolve the conflict. If it is unclear whether a registered link relation type 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.
An element that identifies a link between the current ALPS element and some other (possibly external) resource. MAY be a child element of the and the elements. The 'link' element MAY be represented as a single element or it MAY be represented as an array of single elements. The 'link' element MUST define the two attributes and . The 'link' element MAY have a attribute.
Indicates the name of the 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 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 cannot 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.
Contains a approved value: either an extension relation type (a URI) or a registered relation type (a short string). Appears as a property of and .
Indicates the kind of resource that will be returned when executing the specified network request. The 'rt' attribute SHOULD appear only on a with a value of 'safe', 'unsafe', or 'idempotent.' The 'rt' attribute is OPTIONAL and, when it appears, it MUST point to the of an existing using one of two methods: A fragment identifier (e.g. rt="#friend") which points to the of an existing in the current ALPS document. A resolvable URL with a fragment identifier (e.g. rt="http://example.org/profiles/people#friend") which points to the of an existing in any valid ALPS document.
The 'title' can appear as a root element (as a child of ) or as a property of or . The value of `title` contains a single human-readable text string.
Search Profile ... ]]>
Indicates the type of hypermedia control to which the element is applied within the resulting representation. This SHOULD appear for each element. The four valid values are: A state element (e.g. HTML.SPAN, HTML.INPUT, etc.). A hypermedia control that triggers a safe, idempotent state transition (e.g. HTTP.GET or HTTP.HEAD). A hypermedia control that triggers an unsafe, idempotent state transition (e.g. HTTP.PUT or HTTP.DELETE). 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 'type="semantic"' is implied.
Contains a string value. It MAY appear as an attribute of the and the elements.
Indicates the version of the ALPS specification used in the document. This SHOULD appear as a property of the element. Currently the only valid value is '1.0'. If no value appears, then '1.0' is implied.
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.
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.
]]>
In the XML version of an ALPS document, the following ALPS properties always appear as XML elements: , , , and . All other ALPS properties appear as XML attributes.
Below is an example of an application/alps+xml representation.
A search form with two inputs. input for search results format ]]>
When representing ALPS documents in JSON format, the and properties are always expressed as arrays of anonymous objects - even when there is only one member in the array.
For example:
The property is always expressed as a named object.
For example:
Below is a example of the application/alps+json representation of an ALPS document.
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. 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 at (http://alps.io/docs/mapping). [TK : this page does not yet exist. -mamund] 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.
To indicate that an ALPS profile describes the semantics of some representation document, the representation document SHOULD be linked to the ALPS document. The 'profile' link relation MUST be used when creating this link. 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' 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.
This specification establishes two media types: 'application/alps+xml' and 'application/alps+json'
application alps+xml None This parameter has identical semantics to the charset parameter of the 'application/xml' media type as specified in. 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. Same as encoding considerations of application/xml as specified in. 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. 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. Fragment identifiers used with application/alps+xml resources are simple, opaque strings that do not contain any URL unsafe characters per which match the in an existing in the document. For example, the fragment identifier "#user" refers to a descriptor in the document with an id value set to "user." This Document Various none .xml TEXT none Mike Amundsen mca@amundsen.com Common Mike Amundsen
application alps+json None 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. binary This media type shares security issues common to all JSON content types. See 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. None Fragment identifiers used with application/alps+json resources are simple, opaque strings that do not contain any URL unsafe characters per which match the in an existing in the document. For example, the fragment identifier "#user" refers to a descriptor in the document with an id value set to "user." This Document Various none .json TEXT none Mike Amundsen mca@amundsen.com Common Mike Amundsen
[TK] insert text (consider rfc 5987)
The authors gratefully acknowledge the following people who made contributions to this specification: Glenn Block, Christopher Harrison, Steve Klabnik, Filip Kolarik, Akihito Koriyama, Graham Klyne, Dmitry Pavlov, Rémon (Ray) Sinnema.
&rfc1738; &rfc2119; &rfc3023; &rfc3987; &rfc4627; &rfc5988; &rfc6906; &rfc7320;
ALPS is meant to describe a service in a universal way. The same ALPS description document can be used by many ALPS-compliant servers. Since each service implementation is in charge of their own URL space, ALPS descriptions do not include URLs. See URI Design and Ownership for more on this principle. When implementing ALPS-compliant servers, implementors are free to use any URL design they wish. All that is required is that implementors use the same ALPS profile descriptor 'id' and 'name' properties in the representations. When implementing ALPS-compliant client applications, the URLs will be supplied at runtime by the server representations. Client apps only need to recognize the descriptor 'id' and 'name' values from the referenced ALPS profile document.
ALPS is not designed to describe workflows or execution paths for a service. Instead, ALPS is designed to describe a shared set of data and actions elements that server MAY implement in order to create a service. Each action descriptor (where the descriptor's type property is set to 'safe', 'unsafe', or 'idemponent') SHOULD describe a state transition that a ALPS-compliant client application can invoke when it is available. Servers are free to implement the transitions they find useful and to arrange them in any order they wish. ALPS-compliant client applications SHOULD be able to recognize these descriptors when they appear and are free to act upon them directly, render them for humans to invoke, or ignore/hide them completely.
For most all service implementations, there are cases where it would be helpful to document a range of possible values for a semantic element. For example, when implementing the descriptor {"id":"size", ...}, one service might want to indicate the list of supported values such as: 'small', 'meduim', 'large', etc. However, another service might have a very different list of possible values such as 'standard', 'oversized', 'undersized', etc. And there may be a service that only supports a single value here and will always supply it ('onesize'). Since ALPS is meant to provide a single description that can be used by multiple services, establishing ranges within the ALPS description is considered over-constraining service implementations. Services are free to supply this information within representations at run time. But including them in the global ALPS profile is discouraged.