change all uses of shall to must, and stylize all non-linked conformance classes

CHANGELOG.md

@@ -18,7 +18,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 - Query Extension is no longer deprecated.
 - Children conformance class now requires the /children endpoint includes all child catalogs or collections
   referenced via `child` link relations from the Landing Page
-
+- Specifications now use the term "must" instead of "shall". The semantics of these words are identical.
 ### Deprecated
 
 ### Removed

browseable/README.md

@@ -13,15 +13,15 @@
 - **[Maturity Classification](../README.md#maturity-classification):** Proposal
 - **Dependencies**: [STAC API - Core](../core)
 
-A STAC API conforming to the `STAC API - Browseable` conformance class must be structured such that all 
+A STAC API conforming to the *STAC API - Browseable* conformance class must be structured such that all 
 all Items in the catalog can be accessed by following `child` and `item` link relations. This is a more significant
 constraint than a STAC API without this conformance class or a STAC Catalog that is available over HTTP but does not
 implement STAC API, neither of which have any guarantee regarding the reachability of Items. This conformance 
 class is used to signal to users that they can fully navigate to all available Items using a UI (like [STAC Browser](https://github.com/radiantearth/stac-browser), 
 and also makes it clear to crawlers that they can reach everything by following catalog links. 
 
 Recommendations for structuring Catalogs hierarchically can be found in
-[Structuring Catalog Hierarchies](../core/README.md#structuring-catalog-hierarchies) from the `STAC API - Core` specification.
+[Structuring Catalog Hierarchies](../core/README.md#structuring-catalog-hierarchies) from the *STAC API - Core* specification.
 
 ## Link Relations
 
@@ -36,7 +36,7 @@ every Item in the Catalog can be accessed by traversing these relations.
 | `item`  | various  | STAC Core | The child STAC Items.                  |
 
 Note that there is a different link relation `items` (plural)
-used by the `STAC API - Features` conformance class that links from a collection resource
+used by the *STAC API - Features* conformance class that links from a collection resource
 (at the `/collections/{collectionId}` endpoint) to the items in
 that collection (at the `/collections/{collectionId}/items` endpoint). Both of these endpoints are 
 [derived from OGC API - Features](https://docs.opengeospatial.org/is/17-069r3/17-069r3.html#_items_).
@@ -49,7 +49,7 @@ This conformance class adds no additional endpoints.
 
 ## Example Landing Page for STAC API - Browseable
 
-This JSON is what would be expected from an API that implements `STAC API - Browseable`. Note that the
+This JSON is what would be expected from an API that implements *STAC API - Browseable*. Note that the
 `conformsTo` array contains `https://api.stacspec.org/v1.0.0-beta.5/browseable` and the `links` array 
 contains `child` link relations.  The semantics of this conformance class imply that the the catalogs
 linked to by these `child` link relations then have further `child` or `item` link relations that

children/README.md

@@ -14,7 +14,7 @@
 - **Dependencies**: [STAC API - Core](../core)
 
 A STAC API Landing Page (a Catalog) can return information about the Catalog and Collection child objects
-it contains using the link relation `children` to an endpoint `/children`. The `/children` endpoint shall
+it contains using the link relation `children` to an endpoint `/children`. The `/children` endpoint must
 return the all the Catalog and Collection objects referenced by these `child` link relations.
 
 The purpose of this endpoint is to present a single resource from which clients can retrieve
@@ -29,13 +29,13 @@ but the objects must still be valid Catalogs and Collections.
 
 This conformance class also requires implementation of the link relations in the [STAC API - Core](../core) conformance class.
 
-The following Link relations shall exist in the Landing Page (root).
+The following Link relations must exist in the Landing Page (root).
 
 | **rel**    | **href**    | **From**            | **Description**                  |
 | ---------- | ----------- | ------------------- | -------------------------------- |
 | `children` | `/children` | STAC API - Children | List of children of this catalog |
 
-The following Link relations shall exist in the `/children` endpoint response.
+The following Link relations must exist in the `/children` endpoint response.
 
 | **rel** | **href**    | **From**            | **Description** |
 | ------- | ----------- | ------------------- | --------------- |
@@ -50,7 +50,7 @@ This conformance class also requires for the endpoints in the [STAC API - Core](
 | ----------- | ------- | ---------------------------------------------------- |
 | `/children` | JSON    | Object with a list of child Catalogs and Collections |
 
-STAC APIs implementing the `STAC API - Children` conformance class must support HTTP GET operation at
+STAC APIs implementing the *STAC API - Children* conformance class must support HTTP GET operation at
 `/children`, with the return JSON document consisting of an array of all child Catalogs and Collections in a field `children` and an 
 array of Links in a field `links`.
 

collections/README.md

@@ -28,7 +28,7 @@ aim to align with it. But it still seems to be in flux.*
 
 This conformance class also requires implementation of the link relations in the [STAC API - Core](../core) conformance class.
 
-The following Link relations shall exist in the Landing Page (root).
+The following Link relations must exist in the Landing Page (root).
 
 | **rel** | **href**       | **From** | **Description**     |
 | ------- | -------------- | -------- | ------------------- |
@@ -40,14 +40,14 @@ Additionally, `child` relations may exist to child Catalogs and Collections.
 | ------- | -------- | --------- | -------------------------------------------------------------------------------------------------------- |
 | `child` | various  | STAC Core | The child STAC Catalogs & Collections. Provides curated paths to get to STAC Collection and Item objects |
 
-The following Link relations shall exist in the `/collections` endpoint response.
+The following Link relations must exist in the `/collections` endpoint response.
 
 | **rel** | **href**       | **From**  | **Description** |
 | ------- | -------------- | --------- | --------------- |
 | `root`  | `/`            | STAC Core | The root URI    |
 | `self`  | `/collections` | OAFeat    | Self reference  |
 
-The following Link relations shall exist in the Collection object returned from the `/collections/{collectionId}` endpoint.
+The following Link relations must exist in the Collection object returned from the `/collections/{collectionId}` endpoint.
 
 | **rel**  | **href**                      | **From**  | **Description**                            |
 | -------- | ----------------------------- | --------- | ------------------------------------------ |

core/README.md

@@ -14,7 +14,7 @@
 - **Dependencies**: None
   and [commons.yaml](commons.yaml) is the OpenAPI version of the core [STAC spec](../stac-spec) JSON Schemas.
 
-All STAC API implementations must support the `STAC API - Core` conformance class. The only requirement of this class
+All STAC API implementations must support the *STAC API - Core* conformance class. The only requirement of this class
 is to provide a valid [STAC Catalog](../stac-spec/catalog-spec/catalog-spec.md) that also includes a `conformsTo`
 attribute with a string array value. Any API implementing this is considered a valid STAC API.
 
@@ -23,7 +23,7 @@ makes it into a defacto hypermedia-driven web API. Even if none of the
 STAC API conformance classes are implemented, the catalog can be traversed from the root via `child` and `item` link relations (though it is not
 required that all Items are reachable). Support for 
 this "browse" mode of interaction is complementary to the dynamic search capabilities defined in the
-`STAC API - Features` and `STAC API - Item Search` conformance classes.
+*STAC API - Features* and *STAC API - Item Search* conformance classes.
 Conversely, STAC API implementations may not support browse, even though the root is a Catalog object, if they do not
 have the appropriate `child` and `item` link relations to traverse over the objects in the catalog. STAC API
 implementations may provide an even greater guarantee of Item reachability with the
@@ -62,18 +62,18 @@ Note the `conformsTo` array follows the same structure of the OGC API - Features
 classes](http://docs.opengeospatial.org/is/17-069r3/17-069r3.html#_declaration_of_conformance_classes), except it is part of the
 landing page instead of in the JSON response from the `/conformance` endpoint. This is different from how the OGC API advertises 
 conformance, as STAC feels it is important for clients
-to understand conformance from a single request to the landing page. Implementers who implement the `OGC API - Features` and/or 
-`STAC API - Features` conformance classes must also implement the `/conformance` endpoint.
+to understand conformance from a single request to the landing page. Implementers who implement the *OGC API - Features* and/or 
+*STAC API - Features* conformance classes must also implement the `/conformance` endpoint.
 
 The scope of the conformance classes declared in the `conformsTo` field and the `/conformance` endpoint are limited
 to the STAC API Catalog that declares them. A STAC API Catalog may link to sub-catalogs within it via `child` links
 that declare different conformance classes. This is useful when an entire catalog cannot be searched against to
-support the `STAC API - Item Search` conformance class, perhaps because it uses multiple databases to store items,
+support the *STAC API - Item Search* conformance class, perhaps because it uses multiple databases to store items,
 but sub-catalogs whose items are all in one database can support search. 
 
 ## Link Relations
 
-The following Link relations shall exist in the Landing Page (root).
+The following Link relations must exist in the Landing Page (root).
 
 | **rel**        | **href** | **From**  | **Description**                                      |
 | -------------- | -------- | --------- | ---------------------------------------------------- |
@@ -114,7 +114,7 @@ search over only a sub-catalog. This is useful for very large or federated catal
 over the entire catalog, but can support searching over individual sub-catalogs within it.
 
 Note that there is a different link relation `items` (plural)
-used by the `STAC API - Features` conformance class that links from a collection resource
+used by the *STAC API - Features* conformance class that links from a collection resource
 (at the `/collections/{collectionId}` endpoint) to the items in
 that collection (at the `/collections/{collectionId}/items` endpoint). Both of these endpoints are 
 [derived from OGC API - Features](https://docs.opengeospatial.org/is/17-069r3/17-069r3.html#_items_).
@@ -149,7 +149,7 @@ with other endpoints from the root.
 
 ## Example Landing Page for STAC API - Core
 
-This JSON is what would be expected from an API that only implements `STAC API - Core`. It is a valid STAC Catalog
+This JSON is what would be expected from an API that only implements *STAC API - Core*. It is a valid STAC Catalog
 with additional Links and a `conformsTo` attribute. In practice, 
 most APIs will also implement other conformance classes, and those will be reflected in the `links` and 
 `conformsTo` attribute.  A more typical Landing Page example is in 
@@ -214,7 +214,7 @@ None.
 A STAC API is more useful when it presents a complete `Catalog` representation of all the data contained in the
 API, such that all `Item` objects can be reached by transitively traversing `child` and `item` link relations from
 the root. This property of being able to reach all Items in this way is formalized in the
-[`STAC API - Browseable` conformance class](../browseable/README.md), but any Catalog can be structured for hierarchical traversal. 
+[*STAC API - Browseable* conformance class](../browseable/README.md), but any Catalog can be structured for hierarchical traversal. 
 Implementers who have search as their primary use case should consider also implementing this
 alternate view over the data by presenting it as a directed graph of catalogs, where the `child` link relations typically
 form a tree, and where each catalog can be retrieved with a single request (e.g., each Catalog JSON is small enough that

item-search/README.md

@@ -49,13 +49,13 @@ Implementing `GET /search` is **required**, `POST /search` is optional, but reco
 
 This conformance class also requires implementation of the link relations in the [STAC API - Core](../core) conformance class.
 
-The following Link relations shall exist in the Landing Page (root).
+The following Link relations must exist in the Landing Page (root).
 
 | **rel**  | **href**  | **From**               | **Description**             |
 | -------- | --------- | ---------------------- | --------------------------- |
 | `search` | `/search` | STAC API - Item Search | URI for the Search endpoint |
 
-This `search` link relation shall have a `type` of `application/geo+json`. If no `method` attribute is
+This `search` link relation must have a `type` of `application/geo+json`. If no `method` attribute is
 specified, it is assumed to represent a GET request. If the server supports both GET and POST requests, two links should be included, one with a `method` of `GET` one with a `method` of `POST`.
 
 Other links with relation `search` may be included that advertise other content types the server may respond
@@ -113,7 +113,7 @@ a suggestion to the server as to the maximum number of Item objects the
 client would prefer in the response. The OpenAPI specification defines the default and maximum values
 for this parameter. The base specifications define these with a default of 10 and a maximum of 10000, but implementers
 may choose other values to advertise through their `service-desc` endpoint.  If the limit parameter value is greater
-than the advertised maximum limit, the server shall return the maximum possible number of items (ideally, the number 
+than the advertised maximum limit, the server must return the maximum possible number of items (ideally, the number 
 as the advertised maximum limit), rather than responding with an error.
 
 Only one of either **intersects** or **bbox** may be specified.  If both are specified, a 400 Bad Request response 
@@ -239,7 +239,7 @@ does implement them, for STAC and OAFeat implementations that want to enable wri
 
 ## Example Landing Page for STAC API - Item Search
 
-This JSON is what would be expected from an api that only implements STAC API - Item Search. In practice, 
+This JSON is what would be expected from an api that only implements *STAC API - Item Search*. In practice, 
 most APIs will also implement other conformance classes, and those will be reflected in the `links` and 
 `conformsTo` fields.  A more typical Landing Page example is in 
 the [overview](../overview.md#example-landing-page) document.

item-search/openapi.yaml

@@ -191,9 +191,9 @@ components:
       in: query
       description: |-
         The optional limit parameter recommends the number of items that should be present in the response document.
-        
+
         Only items are counted that are on the first level of the collection in the response document.
-        Nested objects contained within the explicitly requested items shall not be counted.
+        Nested objects contained within the explicitly requested items must not be counted.
 
         Minimum = 1. Maximum = 10000. Default = 10.
       required: false
@@ -235,11 +235,11 @@ components:
       description: |-
         The optional limit parameter limits the number of items that are presented in the response document.
 
-        If the limit parameter value is greater than advertised limit maximum, the server shall return the
+        If the limit parameter value is greater than advertised limit maximum, the server must return the
         maximum possible number of items, rather than responding with an error.
 
         Only items are counted that are on the first level of the collection in the response document.
-        Nested objects contained within the explicitly requested items shall not be counted.
+        Nested objects contained within the explicitly requested items must not be counted.
 
         Minimum = 1. Maximum = 10000. Default = 10.
     bboxFilter:

ogcapi-features/README.md

@@ -49,7 +49,7 @@ with OAFeat clients. But specialized STAC clients will likely display results be
 
 This conformance class also requires implementation of the link relations in the [STAC API - Core](../core) conformance class.
 
-The following Link relations shall exist in the Landing Page (root).
+The following Link relations must exist in the Landing Page (root).
 
 | **rel**       | **href**       | **From** | **Description**     |
 | ------------- | -------------- | -------- | ------------------- |
@@ -231,7 +231,7 @@ GET /collections/mycollection/items?datetime=2019-01-01T00:00:00Z/2019-03-31T23:
 
 ## Example Landing Page for STAC API - Features
 
-This JSON is what would be expected from an api that only implements STAC API - Features. In practice, 
+This JSON is what would be expected from an api that only implements *STAC API - Features*. In practice, 
 most APIs will also implement other conformance classes, and those will be reflected in the `links` and 
 `conformsTo` fields.  A more typical Landing Page example is in 
 the [overview](../overview.md#example-landing-page) document.
@@ -326,7 +326,7 @@ as is typical with a static STAC Collection, there are no links here with rel va
 
 ## Extensions
 
-These extensions provide additional functionality that enhances `STAC API - Features`. 
+These extensions provide additional functionality that enhances *STAC API - Features*. 
 All are specified as [fragments](../fragments), as they are re-used by extensions to other STAC APIs.
 STAC APIs that offer the following capabilities must include the relevant **conformance URI** in the 
 `conformsTo` response at the root (`/`) landing page, to indicate to clients that they will respond properly 

ogcapi-features/extensions/transaction/openapi.yaml

@@ -92,7 +92,7 @@ paths:
       parameters:
         - $ref: '#/components/parameters/IfMatch'
       requestBody:
-        description: The request body shall contain a representation of the replacement item.
+        description: The request body must contain a representation of the replacement item.
         content:
           application/json:
             schema:

ogcapi-features/openapi.yaml

@@ -248,11 +248,11 @@ components:
       description: |-
         The optional limit parameter recommends the number of items that should be present in the response document.
 
-        If the limit parameter value is greater than advertised limit maximum, the server shall return the
+        If the limit parameter value is greater than advertised limit maximum, the server must return the
         maximum possible number of items, rather than responding with an error.
 
         Only items are counted that are on the first level of the collection in the response document.
-        Nested objects contained within the explicitly requested items shall not be counted.
+        Nested objects contained within the explicitly requested items must not be counted.
 
         Minimum = 1. Maximum = 10000. Default = 10.
       required: false
@@ -309,7 +309,7 @@ components:
         A server may omit this information in a response, if the information
         about the number of features is not known or difficult to compute.
 
-        If the value is provided, the value shall be identical to the number
+        If the value is provided, the value must be identical to the number
         of items in the "features" array.
       type: integer
       minimum: 0