radiantearth · cholmes · Mar 30, 2021 · Mar 26, 2021 · Mar 30, 2021 · Mar 30, 2021
diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS
diff --git a/README.md b/README.md
@@ -92,8 +92,8 @@ It includes things like the spatial and temporal extent of the data, the license
 It enables discovery at a higher level than individual Item objects, providing a simple way to describe sets of data.
 * **[Examples](examples/):** The *[examples/](examples/)* folder contains examples for all three specifications, linked together to form two 
 complete examples. Each spec and extension links in to highlight particular files that demonstrate key concepts.
-* **[Extensions](extensions/):** The *[extensions/](extensions/)* folder is where extensions live. Extensions can extend the 
-functionality of the core spec or add fields for specific domains. Each extension has at least one *owner*. You can find extension owners in each extension's README or in the [`CODEOWNERS`](.github/CODEOWNERS) file.
+* **[Extensions](extensions/README.md)** describe how STAC can use extensions that extend the functionality of the core spec or 
+add fields for specific domains. Extensions can be published anywhere, although the preferred location for public extensions is in the [GitHub `stac-extensions` organization](https://github.com/stac-extensions).
 * **Additional documents:** The supporting documents include a complementary [best practices](best-practices.md) 
 document, and information on contributing (links in the next section). We also maintain a [changelog](CHANGELOG.md) of
 what was modified in each version. 

diff --git a/best-practices.md b/best-practices.md
@@ -247,12 +247,12 @@ providing them at at the Asset level can prove to be very useful for using the d
 - `datetime`: Provide individual timestamp on an Item, in case the Item has a `start_datetime` and `end_datetime`, but an Asset is for one specific time.
 - `gsd` ([Common Metadata](item-spec/common-metadata.md#instrument)): Specify some assets with different spatial resolution 
 than the overall best resolution.
-- `eo:bands` ([EO extension](extensions/eo/)): Provide spectral band information, and order of bands, within an individual asset.
-- `proj:epsg`/`proj:wkt2`/`proj:projjson` ([projection extension](extensions/projection/)): Specify different projection for some assets. If the projection is different
+- `eo:bands` ([EO extension](https://github.com/stac-extensions/eo/)): Provide spectral band information, and order of bands, within an individual asset.
+- `proj:epsg`/`proj:wkt2`/`proj:projjson` ([projection extension](https://github.com/stac-extensions/projection/)): Specify different projection for some assets. If the projection is different
  for all assets it should probably not be provided as an Item property. If most assets are one projection, and there is 
  a single reprojected version (such as a Web Mercator preview image), it is sensible to specify the main projection in the 
  Item and the alternate projection for the affected asset(s).
-- `proj:shape`/`proj:transform` ([projection extension](extensions/projection/)): If assets have different spatial resolutions and slightly different exact bounding boxes, specify these per asset to indicate the size of the asset in pixels and its exact GeoTransform in the native projection.
+- `proj:shape`/`proj:transform` ([projection extension](https://github.com/stac-extensions/projection/)): If assets have different spatial resolutions and slightly different exact bounding boxes, specify these per asset to indicate the size of the asset in pixels and its exact GeoTransform in the native projection.
 - `sar:polarizations` ([sar extension](https://github.com/stac-extensions/sar)): Provide the polarization content and ordering of a specific asset, similar to `eo:bands`.
 - `sar:product_type` ([sar extension](https://github.com/stac-extensions/sar)): If mixing multiple product types within a single Item, this can be used to specify the product_type for each asset.
 
@@ -338,9 +338,9 @@ actual role requirements.
 | land-water | Best Practice | Points to a file that indicates whether a pixel is assessed as being land or water. |
 | water-mask | Best Practice | Points to a file that indicates whether a pixel is assessed as being water (e.g. flooding map). | iso-19139 | Best Practice | Points to an [ISO 19139](https://www.iso.org/standard/67253.html) metadata xml file |
 | iso-19115 | Best Practice | Points to an [ISO 19115](https://www.iso.org/standard/53798.html) metadata file |
-| reflectance, temperature, saturation, cloud, cloud-shadow | [EO Extension](extensions/eo/README.md#best-practices) | See the [table](extensions/eo/README.md#best-practices) in EO for more information, and the definitive list of roles related to EO. |
-| incidence-angle, azimuth, sun-azimuth, sun-elevation, terrain-shadow, terrain-occlusion, terrain-illumination | [View Extension](extensions/view/README.md#best-practices) | See the [table](extensions/view/README.md#best-practices) in View for more information, and the definitive list of roles related to viewing angles. |
-| local-incidence-angle, noise-power, amplitude, magnitude, sigma0, beta0, gamma0, date-offset, covmat, prd | [SAR Extension](https://github.com/stac-extensions/sar/README.md#best-practices) | See the [table](https://github.com/stac-extensions/sar/README.md#best-practices) in SAR for more information. , and the definitive list of roles related to SAR. |
+| reflectance, temperature, saturation, cloud, cloud-shadow | [EO Extension](https://github.com/stac-extensions/eo/blob/main/README.md#best-practices) | See the [table](https://github.com/stac-extensions/eo/blob/main/README.md#best-practices) in EO for more information, and the definitive list of roles related to EO. |
+| incidence-angle, azimuth, sun-azimuth, sun-elevation, terrain-shadow, terrain-occlusion, terrain-illumination | [View Extension](https://github.com/stac-extensions/view/blob/main/README.md#best-practices) | See the [table](https://github.com/stac-extensions/view/blob/main/README.md#best-practices) in View for more information, and the definitive list of roles related to viewing angles. |
+| local-incidence-angle, noise-power, amplitude, magnitude, sigma0, beta0, gamma0, date-offset, covmat, prd | [SAR Extension](https://github.com/stac-extensions/sar/blob/main/README.md#best-practices) | See the [table](https://github.com/stac-extensions/sar/blob/main/README.md#best-practices) in SAR for more information. , and the definitive list of roles related to SAR. |
 
 Some of the particular asset roles also have some best practices:
 
@@ -489,7 +489,7 @@ Some general thinking on what to summarize is as follows:
 
 * Any field that is a range of data (like numbers or dates) is a great candidate to summarize, to give people a sense what values
 the data might be. For example in overhead imagery, a 
-[`view:off_nadir`](extensions/view/README.md#item-properties-and-item-asset-fields) with a range of 0 to 3 would tell people this 
+[`view:off_nadir`](https://github.com/stac-extensions/view/blob/main/README.md#item-properties-and-item-asset-fields) with a range of 0 to 3 would tell people this 
 imagery is all pretty much straight down, while a value of 15 to 40 would tell them that it's oblique imagery, or 0 to 60 that it's 
 a Collection with lots of different look angles. 
 
@@ -506,12 +506,12 @@ to include all the different location string values in a summary.
 
 * Fields that consist of arrays are more of a judgement call. For example [`instruments`](item-spec/common-metadata.md#instrument)
 is straightforward and recommended, as the elements of the array are a discrete set of options. On the other hand 
-[`proj:transform`](extensions/projection/README.md#projtransform) makes no sense to summarize, as the union of all the values
+[`proj:transform`](https://github.com/stac-extensions/projection/blob/main/README.md#projtransform) makes no sense to summarize, as the union of all the values
 in the array are meaningless, as each Item is describing its transform, so combining them would just be a bunch of random numbers.
 So if the values contained in the array are independently meaningful (not interconnected) and there aren't hundreds of potential
 values then it is likely a good candidate to summarize.
 
-We do highly recommend including an [`eo:bands`](extensions/eo/README.md#eobands) summary if your Items implement `eo:bands`, 
+We do highly recommend including an [`eo:bands`](https://github.com/stac-extensions/eo/blob/main/README.md#eobands) summary if your Items implement `eo:bands`, 
 especially if it represents just one satellite or constellation. This should be a union of all the potential bands that you 
 have in assets. It is ok to only add the summary at the Collection level without putting an explicit `eo:bands` summary at the 
 `properties` level of an Item, since that is optional. This gives users of the Collection a sense of the sensor capabilities without 
@@ -540,7 +540,7 @@ cases should utilize a catalog that follows the listed principles:
 * **Only relative href's in structural `links`**: The full catalog structure of links down to sub-catalogs and Items, and their 
 links back to their parents and roots, should be done with relative URL's. The structural rel types include `root`, `parent`, 
 `child`, `item`, and `collection`. Other links can be absolute, especially if they describe a resource that makes less sense in
-the catalog, like [sci:doi](extensions/scientific/README.md#item-and-collection-fields), 
+the catalog, like [sci:doi](https://github.com/stac-extensions/scientific/blob/main/README.md#item-and-collection-fields), 
 `derived_from` or even `license` (it can be nice to include the license in the catalog, but some licenses live at a canonical 
 online location which makes more sense to refer to directly). This enables the full catalog to be downloaded or
 copied to another location and to still be valid. This also implies no `self` link, as that link must be absolute.
@@ -623,10 +623,10 @@ catalogs to preserve previous versions of the documents and link them together.
 
 In order to achieve this, the static catalog must make sure that for every record created, a copy of the record is also 
 created in a separate location and it is named with the version id adopted by the catalog. See 
-[here](https://github.com/stac-extensions/version/README.md#version-id) for recommendations on versioning schema.
+[here](https://github.com/stac-extensions/version/blob/main/README.md#version-id) for recommendations on versioning schema.
 
 The main record should also provide a link to the versioned record following the linking patterns described 
-[here](https://github.com/stac-extensions/version/README.md#relation-types). For every update to the record, the same 
+[here](https://github.com/stac-extensions/version/blob/main/README.md#relation-types). For every update to the record, the same 
 cycle is repeated:
 
 1. Add link from the updated record to the previous version

diff --git a/catalog-spec/catalog-spec.md b/catalog-spec/catalog-spec.md
@@ -1,7 +1,8 @@
-# STAC Catalog Specification
+# STAC Catalog Specification <!-- omit in toc --> 
 
 - [Catalog fields](#catalog-fields)
   - [Additional Field Information](#additional-field-information)
+    - [stac_version](#stac_version)
     - [stac_extensions](#stac_extensions)
   - [Link Object](#link-object)
     - [Relation types](#relation-types)
@@ -39,8 +40,8 @@ also a valid STAC Catalog.
 
 | Element         | Type          | Description                                                  |
 | --------------- | ------------- | ------------------------------------------------------------ |
-| stac_version    | string        | **REQUIRED.** The STAC version the Catalog implements. STAC versions can be mixed, but please keep the [recommended best practices](../best-practices.md#mixing-stac-versions) in mind. |
 | type            | string        | **REQUIRED.** Set to `Catalog` if this Catalog only implements the Catalog spec. |
+| stac_version    | string        | **REQUIRED.** The STAC version the Catalog implements. |
 | stac_extensions | \[string]     | A list of extension identifiers the Catalog implements.                 |
 | id              | string        | **REQUIRED.** Identifier for the Catalog.                    |
 | title           | string        | A short descriptive one-line title for the Catalog.          |
@@ -50,10 +51,16 @@ also a valid STAC Catalog.
 
 ### Additional Field Information
 
+#### stac_version
+
+In general, STAC versions can be mixed, but please keep the [recommended best practices](../best-practices.md#mixing-stac-versions) in mind.
+
 #### stac_extensions
 
-A list of extensions the Catalog implements. This does NOT declare the extensions of children or Items. The list contains URLs to the JSON Schema files it can be validated against. For [core extensions](../extensions/README.md#core-stac-extensions), a "shortcut" can be used. This means you can specify the folder name of the extension, for example `view` for the View extension. If the versions of the extension and the Catalog diverge, you can specify the URL of the JSON schema file.
-This list must only contain extensions that extend the Catalog itself, see the the 'Scope' column in the list of extensions.
+A list of extensions the Catalog implements.
+This list must only contain extensions that extend the Catalog itself, see the the 'Scope' column in the list of
+extensions. This does NOT declare the extensions of child Catalog, Collection, or Item
+objects. The list contains URLs to the JSON Schema files it can be validated against.
 
 ### Link Object
 
@@ -109,7 +116,7 @@ The following table lists the Media Types to use for STAC structures.
 | Media Type                     | Description                                                  |
 | ------------------------------ | ------------------------------------------------------------ |
 | `application/geo+json`	     | A STAC [Item](../item-spec/item-spec.md)                        |
-| `application/json`             | A STAC [Catalog](#stac-catalog-specification)                |
+| `application/json`             | A STAC [Catalog](#)                |
 | `application/json`             | A STAC [Collection](../collection-spec/collection-spec.md)            |
 
 ## Extensions

diff --git a/collection-spec/collection-spec.md b/collection-spec/collection-spec.md
@@ -1,4 +1,26 @@
-# STAC Collection Specification
+# STAC Collection Specification <!-- omit in toc --> 
+
+- [Overview](#overview)
+- [Collection fields](#collection-fields)
+  - [Additional Field Information](#additional-field-information)
+    - [stac_version](#stac_version)
+    - [stac_extensions](#stac_extensions)
+    - [id](#id)
+    - [license](#license)
+    - [summaries](#summaries)
+    - [assets](#assets)
+  - [Extent Object](#extent-object)
+    - [Spatial Extent Object](#spatial-extent-object)
+    - [Temporal Extent Object](#temporal-extent-object)
+  - [Provider Object](#provider-object)
+  - [Link Object](#link-object)
+    - [Relation types](#relation-types)
+  - [Asset Object](#asset-object)
+  - [Stats Object](#stats-object)
+- [Media Type for STAC Collections](#media-type-for-stac-collections)
+- [Standalone Collections](#standalone-collections)
+
+## Overview
 
 The STAC Collection Specification defines a set of common fields to describe a group of Items that share properties and metadata. The 
 Collection Specification shares all fields with the STAC [Catalog Specification](../catalog-spec/catalog-spec.md) (with different allowed 
@@ -21,8 +43,8 @@ specified in [*OGC API - Features*](https://ogcapi.ogc.org/features/), but they
 
 | Element         | Type                                             | Description                                                  |
 | --------------- | ------------------------------------------------ | ------------------------------------------------------------ |
-| stac_version    | string                                           | **REQUIRED.** The STAC version the Collection implements. STAC versions can be mixed, but please keep the [recommended best practices](../best-practices.md#mixing-stac-versions) in mind. |
 | type            | string                                           | **REQUIRED.** Must be set to `Collection` to be a valid Collection. |
+| stac_version    | string                                           | **REQUIRED.** The STAC version the Collection implements. |
 | stac_extensions | \[string]                                        | A list of extension identifiers the Collection implements.   |
 | id              | string                                           | **REQUIRED.** Identifier for the Collection that is unique across the provider. |
 | title           | string                                           | A short descriptive one-line title for the Collection.       |
@@ -37,24 +59,28 @@ specified in [*OGC API - Features*](https://ogcapi.ogc.org/features/), but they
 
 ### Additional Field Information
 
-#### id
+#### stac_version
 
-It is important that Collection identifiers are unique across the provider. And providers should strive as much as possible to make
-their Collection ids 'globally' unique, prefixing any common information with a unique string. This could be the provider's name if
-it is a fairly unique name, or their name combined with the domain they operate in.
+In general, STAC versions can be mixed, but please keep the [recommended best practices](../best-practices.md#mixing-stac-versions) in mind.
 
 #### stac_extensions
 
-A list of extensions the Collection implements. This does NOT declare the extensions of child Catalogs or Items. The list 
-contains URLs to the JSON Schema files it can be validated against. For official 
-[extensions](../extensions/README.md#core-stac-extensions), a "shortcut" can be used. This means you can specify the folder 
-name of the extension, for example `view` for the View extension. If the versions of the extension and 
-the Collection diverge, you can specify the URL of the JSON schema file. This list must only contain extensions that extend 
-the Collection itself, see the the 'Scope' column in the list of extensions. If an extension has influence on multiple parts 
+A list of extensions the Collection implements.  
+This list must only contain extensions that extend the Collection itself, see the the 'Scope' column in the list of 
+extensions. This does NOT declare the extensions of child Collection or Item 
+objects. The list contains URLs to the JSON Schema files it can be validated against.
+
+If an extension has influence on multiple parts 
 of the whole STAC structure, it must be listed in all affected parts (e.g. Collection and Item for the `datacube` extension). 
-If a structure such as the summaries extension provide fields in their JSON structure, these extensions must not be listed 
+If a structure, such as the summaries extension, provides fields in their JSON structure, these extensions must not be listed 
 here as they don't extend the Collection itself. For example, if a Collection includes the field `sat:platform` in the 
-summaries, the Collection still does not list the `sat` extension in the `stac_extensions` field.
+summaries, the Collection should not list the `sat` extension in the `stac_extensions` field.
+
+#### id
+
+It is important that Collection identifiers are unique across the provider. And providers should strive as much as possible to make
+their Collection ids 'globally' unique, prefixing any common information with a unique string. This could be the provider's name if
+it is a fairly unique name, or their name combined with the domain they operate in.
 
 #### license