Restore the extensions page to its original form.

json-api · gabesullice · Feb 12, 2020 · Jan 15, 2020 · Jan 23, 2020 · Jan 23, 2020
commit e267af94865ad72a3388de5956eeeee77dd74265
diff --git a/extensions/index.md b/extensions/index.md
@@ -46,127 +46,10 @@ consider asking the profile's author if they would be willing to modify it as
 needed. Contact them through the information in their profile's registration
 and give them some time to reply.
 
-## <a href="#profile-template" id="profile-template" class="headerlink"></a> Profile Template
+### <a href="#profile-creation" id="profile-creation" class="headerlink"></a> Authoring Your Profile
 
-[Download and fill out the profile template](/profile_template.md).
+To author your profile, [download and fill out the template](/profile_template.md).
 
-## <a href="#profile-creation" id="profile-creation" class="headerlink"></a> Authoring Your Profile
-
-Profiles are a mechanism that can be used by the sender of a document to make promises about its content, without adding to or altering the basic semantics of the JSON:API specification. For example, a profile may indicate that all resource objects will have a `timestamps` attribute field and that the members of the `timestamps` object will be formatted using the ISO 8601 date time format.
-
-A profile is an independent specification of those promises. The following example illustrates how the aforementioned profile might be authored:
-
-<a id="profiles-timestamp-profile"></a>
-```text
-# Timestamps profile
-
-## Introduction
-
-This page specifies a profile for the `application/vnd.api+json` media type,
-as described in the [JSON:API specification](http://jsonapi.org/format/).
-
-This profile allows every resource in a JSON:API document to represent
-significant timestamps in a consistent way.
-
-## Document Structure
-
-Every resource object **MUST** include a `timestamps` member in its associated
-`attributes` object. If this member is present, its value **MUST** be an object that
-**MAY** contain at least one of the following members:
-
-* `created`
-* `updated`
-
-The value of each member **MUST** comply with the variant of ISO 8601 used by
-JavaScript's `JSON.stringify` method to format Javascript `Date` objects.
-```
-
-A profile **MAY** assign meaning to elements of the document structure whose use
-is left up to each implementation, such as resource fields or members of
-`attributes` or `meta` objects. A profile **MUST NOT** define/assign a meaning
-to document members in areas of the document reserved for future use by the
-JSON:API specification.
-
-For example, it would be illegal for a profile to define a new key in a
-document's [top-level][top level] object, or in a [links object][links], as
-JSON API implementations are not allowed to add custom keys in those areas.
-
-The scope of a profile **MUST** be clearly delineated. The elements specified
-by a profile, and their meanings, **MUST NOT** change over time or else the
-profile **MUST** be considered a new profile with a new URI.
-
-> Note: When a profile changes its URI, a huge amount of interoperability is lost.
-> Users that reference the new URI will not have their messages understood by
-> implementations still aware only of the old URI, and vice-versa. Accordingly,
-> it's important to design your profile so that it can evolve without its URI
-> needing to change. See ["Revising a Profile"](#profiles-updating) for details.
-
-Finally, a profile **MUST NOT**:
-
-1. assume that, if it is supported, then other specific profiles will be
-supported as well.
-
-2. define fixed endpoints, HTTP headers, or header values.
-
-3. alter the JSON structure of any concept defined in this specification,
-including to allow a superset of JSON structures.
-
-> If you create your own profile, you are **strongly encouraged to [register](/extensions/#profile-creation)
-> it** with the JSON API [profile registry](/extensions/), so that others can
-> find and reuse it.
-
-#### <a href="#profiles-updating" id="profiles-updating" class="headerlink"></a> Revising a Profile
-
-Profiles **MAY** be revised over time, e.g., to add new capabilities. However,
-any such changes **MUST** be [backwards and forwards compatible](http://www.w3.org/2001/tag/doc/versioning-compatibility-strategies#terminology)
-("compatible evolution"), in order to not break existing users of the profile.
-
-For example, the hypothetical [timestamps profile] *could not* introduce a new,
-required `deleted` member within the `timestamps` object, as that would be
-incompatible with existing deployments of the profile, which would not include
-this new member.
-
-The timestamps profile also *could not* evolve to define a new element as a
-sibling of the `timestamps` key, as that would be incompatible with the rule
-that "The elements... specified by a profile... **MUST NOT** change over time."
-
-> The practical issue with adding a sibling element is that another profile
-> in use on the document might already define a sibling element of the same
-> name.
-
-However, the timestamps profile could evolve to allow other optional members,
-such as `deleted`, in the `timestamps` object. This is possible because the
-`timestamps` object is already a reserved element of the profile, and the profile
-is subject to the default rule that new (previously unrecognized) keys will
-simply be ignored by existing applications.
-
-##### <a href="#profiles-design-for-evolution" id="profiles-design-for-evolution" class="headerlink"></a> Designing Profiles to Evolve Over Time
-
-Fundamentally, for a profile to be able to change in a compatible way over time,
-it must define -- from the beginning -- a rule describing how an application
-that is only familiar with the original version of the profile should process
-documents/requests that use features from an updated version of the profile.
-
-One major approach is to simply have applications ignore (at least some types of)
-unrecognized data. This allows the profile to define new, optional features;
-old applications will continue to work, but simply won't process/"see" these new
-capabilities.
-
-This is essentially the strategy that JSON:API itself uses when it says that:
-
-> Client and server implementations **MUST** ignore members not recognized by
-> this specification.
-
-Other protocols use analogous strategies. E.g., in HTTP, unknown headers are
-simply ignored; they don't crash the processing of the request/response.
-
-As a profile author, you may define your own rules for how applications should
-process uses of the profile that contain unrecognized data, or you may simply
-allow the default rules described in the ["Processing Profiled Documents/Requests"](#profiles-processing)
-to take effect.
-
-If you choose to use the default rules, you **SHOULD** reserve an object-valued
-element anywhere you expect to potentially add new features over time.
 ### <a href="#profile-register" id="profile-register" class="headerlink"></a> Register & Use Your Profile
 
 Once you've authored your profile, submit it to the JSON:API profile registry.