Network Working Group M. Amundsen Internet-Draft Intended status: Informational L. Richardson Expires: April 24, 2021 M. Foster October 21, 2020 Application-Level Profile Semantics (ALPS) draft-amundsen-richardson-foster-alps-04 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, Siren, etc.). 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 ). 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 April 24, 2021. Amundsen, et al. Expires April 24, 2021 [Page 1] Internet-Draft Application-Level Profile Semantics October 2020 Copyright Notice Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4 1.2.1. Describing Domain-Specific Semantics . . . . . . . . 4 1.2.2. ALPS-based Server Implementations . . . . . . . . . . 4 1.2.3. ALPS-based Client Implementations . . . . . . . . . . 4 1.3. A Simple ALPS Example . . . . . . . . . . . . . . . . . . 5 1.4. Identifying an ALPS Document . . . . . . . . . . . . . . 9 2. ALPS Documents . . . . . . . . . . . . . . . . . . . . . . . 10 2.1. Compliance . . . . . . . . . . . . . . . . . . . . . . . 10 2.2. ALPS Document Properties . . . . . . . . . . . . . . . . 10 2.2.1. 'alps' . . . . . . . . . . . . . . . . . . . . . . . 10 2.2.2. 'doc' . . . . . . . . . . . . . . . . . . . . . . . . 10 2.2.3. 'descriptor' . . . . . . . . . . . . . . . . . . . . 11 2.2.4. 'ext' . . . . . . . . . . . . . . . . . . . . . . . . 13 2.2.5. 'format' . . . . . . . . . . . . . . . . . . . . . . 13 2.2.6. 'href' . . . . . . . . . . . . . . . . . . . . . . . 14 2.2.7. 'id' . . . . . . . . . . . . . . . . . . . . . . . . 14 2.2.8. 'link' . . . . . . . . . . . . . . . . . . . . . . . 16 2.2.9. 'name' . . . . . . . . . . . . . . . . . . . . . . . 16 2.2.10. 'rel' . . . . . . . . . . . . . . . . . . . . . . . . 17 2.2.11. 'rt' . . . . . . . . . . . . . . . . . . . . . . . . 17 2.2.12. 'title' . . . . . . . . . . . . . . . . . . . . . . . 17 2.2.13. 'type' . . . . . . . . . . . . . . . . . . . . . . . 18 2.2.14. 'value' . . . . . . . . . . . . . . . . . . . . . . . 18 2.2.15. 'version' . . . . . . . . . . . . . . . . . . . . . . 18 2.3. ALPS Representations . . . . . . . . . . . . . . . . . . 19 2.3.1. Sample HTML . . . . . . . . . . . . . . . . . . . . . 19 2.3.2. XML Representation Example . . . . . . . . . . . . . 19 2.3.3. JSON Representation Example . . . . . . . . . . . . . 20 3. Applying ALPS documents to Existing Media Types . . . . . . . 22 Amundsen, et al. Expires April 24, 2021 [Page 2] Internet-Draft Application-Level Profile Semantics October 2020 3.1. Linking to ALPS Documents . . . . . . . . . . . . . . . . 23 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 4.1. application/alps+xml . . . . . . . . . . . . . . . . . . 23 4.2. application/alps+json . . . . . . . . . . . . . . . . . . 25 5. Internationalization Considerations . . . . . . . . . . . . . 26 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 7.1. Normative References . . . . . . . . . . . . . . . . . . 26 7.2. Informative References . . . . . . . . . . . . . . . . . 27 Appendix A. Frequently Asked Questions . . . . . . . . . . . . . 28 A.1. Why are there no URLs in ALPS? . . . . . . . . . . . . . 28 A.2. Why is there no workflow component in the ALPS specification? . . . . . . . . . . . . . . . . . . . . . 28 A.3. Why is there no way to indicate ranges for semantic descriptors? . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 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, 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'). 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]. Amundsen, et al. Expires April 24, 2021 [Page 3] Internet-Draft Application-Level Profile Semantics October 2020 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 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. Amundsen, et al. Expires April 24, 2021 [Page 4] Internet-Draft Application-Level Profile Semantics October 2020 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. A contact list. A simple link/form for getting a list of contacts. Input for a search form. A link to an individual contact. ALPS Contact Profile document 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. Amundsen, et al. Expires April 24, 2021 [Page 5] Internet-Draft Application-Level Profile Semantics October 2020
Ann Arbuckle 123.456.7890
Zelda Zackney 098.765.4321
Amundsen, et al. Expires April 24, 2021 [Page 6] Internet-Draft Application-Level Profile Semantics October 2020 HTML ALPS Contact Representation 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 HAL XML Contacts Representation 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. Amundsen, et al. Expires April 24, 2021 [Page 7] Internet-Draft Application-Level Profile Semantics October 2020 { "collection" : { "version" : "1.0", "href" : "http://example.org/contacts/", "links" : [ { "rel" : "profile", "href" : "http://alps.io/profiles/contacts" }, { "rel" : "help", "href" : "http://example.org/help/contacts.html" }, { "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", Amundsen, et al. Expires April 24, 2021 [Page 8] Internet-Draft Application-Level Profile Semantics October 2020 "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" } ] } ] } } Collection+JSON Contacts Representation 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. 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]. Amundsen, et al. Expires April 24, 2021 [Page 9] Internet-Draft Application-Level Profile Semantics October 2020 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. 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. Section 2.3 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' child properties. Examples: XML: ... 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' and 'format'. If the 'href' property appears it SHOULD contain a dereferencable URL that points to human-readable text. If the 'format' property appears Amundsen, et al. Expires April 24, 2021 [Page 10] Internet-Draft Application-Level Profile Semantics October 2020 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. XML:

Date of Birth

...

JSON: { "doc" : { "format" : "text" , "value" : "Date of Birth ..." } } A 'doc' element SHOULD appear as a child of 'descriptor'. When present, it describes the meaning and use of the related 'descriptor'. XML: ... JSON: { "descriptor" : [ { "doc" : { "value" : "..." } ... ] } The 'doc' element MAY appear as a child of 'alps'. When present, it describes the purpose of the ALPS document as a whole. XML: ... ... JSON: { "alps : { "doc" : { "value" : "..." } } ... } 2.2.3. 'descriptor' 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 'alps'. It may also appear as a child of itself; that is, the 'descriptor' property may be nested. The 'descriptor' property SHOULD have either an 'id' or 'href' attribute. It MAY have both. Additionally, the 'descriptor' MAY have any of the following attributes: 1. 'doc' 2. 'name' 3. 'type' Amundsen, et al. Expires April 24, 2021 [Page 11] Internet-Draft Application-Level Profile Semantics October 2020 4. 'rel' 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: 1. A client SHOULD assume them to appear in any sibling 'descriptor' element and recursively in their child descriptors. 2. 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. 2.2.3.1. 'Descriptors and Link Relation Types' When a representation is generated that includes state transitions, valid values for link relation types are: 1. A registered IANA link relation type (e.g. rel="edit", a short string). 2. An extension link relation type as defined by [RFC5988] 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 Section 2.2.7.2. 3. The 'id' property of a state transition descriptor of an associated ALPS document (e.g. rel="purchased-by", a short Amundsen, et al. Expires April 24, 2021 [Page 12] Internet-Draft Application-Level Profile Semantics October 2020 string) per the conventions of section Section 2.2.7.1 and Section 2.2.7.3 if the representation includes an ALPS profile. 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 the following properties. 1. 'id' 2. 'href' 3. 'value' The 'id' property is REQUIRED. The 'href' is RECOMMENDED and it SHOULD point to documentation that explains the use and meaning of this 'ext' element. The 'value' property is OPTIONAL. The content is undetermined; its meaning and use SHOULD be explained by the document found by de-referencing the 'href' property. Examples: XML: JSON: { "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: 1. 'alps' 2. '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. 2.2.5. 'format' Indicates how the text content should be parsed and/or rendered. This specification identifies a range of possible values for 'format': Amundsen, et al. Expires April 24, 2021 [Page 13] Internet-Draft Application-Level Profile Semantics October 2020 o 'text', for plain text, MUST be supported. o 'html', for HTML, SHOULD be supported. o 'asciidoc', for AsciiDoc, MAY be supported. o 'markdown', per The text/markdown Media Type [I-D.ietf-appsawg-text-markdown], 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 'doc' element. 2.2.6. 'href' Contains a resolvable URL. When it appears as an attribute of a 'descriptor', '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 Section 2.2.7.2 referencing the related 'descriptor'. When it appears as an attribute of 'ext', 'href' points to an external document which provides the definition of the extension. When it appears as an attribute of 'link', 'href' points to an external document whose relationship to the current document or 'descriptor' is described by the associated 'rel' property. When it appears as an attribute of '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 SHOULD appear as an attribute of a 'descriptor'. It SHOULD be an opaque string that does not contain any URL unsafe characters per [RFC1738]. 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: Amundsen, et al. Expires April 24, 2021 [Page 14] Internet-Draft Application-Level Profile Semantics October 2020 'id' in ALPS... ...becomes the 'class' in HTML 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). 2.2.7.1. ALPS 'id' and 'name' Properties 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.