Merge pull request #499 from opengeospatial/chris-little-editorial-pa…

…tch-2

Chris little editorial patch 2

extensions/pubsub/standard/recommendations/pubsub/PER_links.adoc

@@ -5,7 +5,7 @@
 
 *A:*
 
-A collection endpoint MAY provide a link reference to a Publish-Subscribe server from an OGC API implementation endpoint when Publish-Subscribe capabilities exist related to the collection endpoint.
+A `collection` resource MAY provide a link reference to a Publish-Subscribe server from an OGC API implementation endpoint when Publish-Subscribe capabilities exist related to the `collection` service endpoint.
 
 *B:*
 

extensions/pubsub/standard/sections/clause_1_scope.adoc

@@ -1,7 +1,7 @@
 == Scope
 
 ====
-The OGC API - Environmental Data Retrieval - Part 2: Publish-Subscribe Workflows Standard defines building blocks that can be assembled to implement Publish-Subscribe workflows (discovery, topic structure, encoding) as part of OGC API - Environmental Data Retrieval - Part 1: Core.
+The OGC API - Environmental Data Retrieval - Part 2: Publish-Subscribe Workflows Standard defines building blocks that can be assembled to implement Publish-Subscribe workflows (discovery, topic structure, encoding) as part of OGC API - Environmental Data Retrieval - Part 1: Core. A topic structure is the structured information that a publisher makes available to allow subscribers to choose information of interest to them. 
 
 This Standard defines a discovery capability that contains a topic structure in support of binding to notifications for data access and retrieval.
 

extensions/pubsub/standard/sections/clause_7_pubsub.adoc

@@ -15,13 +15,13 @@ include::../recommendations/pubsub/PER_protocols.adoc[]
 
 === OGC API Considerations
 
-The OGC API building block approach would typically be used for shared components in API implementations in support of a polling workflow. Using HTTP, this means that the client initiates and invokes requests and receives responses from the server.  A key concept of the OGC API building blocks architecture is the endpoint hierarchy, which can be applied for Pub/Sub workflow as follows:
+The OGC API building block approach would typically be used for shared components in API implementations in support of a polling workflow. Using HTTP, this means that the client initiates and invokes requests and receives responses from the server.  A key concept of the OGC API building blocks architecture is the service endpoint of the URL path specifying a resource and any similar sub-resources, which can be applied for Pub/Sub workflow as follows:
 
 * Data producers: Messages are published to a broker, applied to a given channel (example: ``collections/mycollection``).
 * Broker provisioning: Published messages are sent to subscribers.
 * Subscribers and data consumers: Messages are received by users subscribed to one or more channels (explicitly or using wildcards or filtering).
 
-The above workflow requires adherence to a hierarchy of channels, auto-discovery of channels, as well as processing of generic messages for broad interoperability by all components.
+The above workflow requires adherence to a structure of information channels, auto-discovery of those channels, as well as processing of generic messages for broad interoperability by all components.
 
 ==== AsyncAPI
 

extensions/pubsub/standard/sections/clause_8_pubsub-channels.adoc

@@ -7,12 +7,12 @@ include::../requirements/requirements_class_pubsub_channels.adoc[]
 
 ==== Channels
 
-The OGC API endpoint hierarchy can be used in parallel as a channel description when the data publisher wishes to provide Pub/Sub capability for resources normally available via an OGC API implementations instance in the same way. Below are examples of endpoints normally available via HTTP, and how they can be re-used as topics for Pub/Sub workflow:
+The OGC API service endpoint specified by a URL path of resources and sub-resources can be used in parallel as a channel description when the data publisher wishes to provide Pub/Sub capability for resources normally available via an OGC API implementations instance in the same way. Below are examples of service endpoints or resources normally available via HTTP, and how they can be re-used as topics for Pub/Sub workflow:
 
-- ``/collections``: Notifies Subscribers whenever there is a change to the ``/collections`` endpoint (for example, addition of a new collection). The message payload would be collection metadata as defined in the https://docs.ogc.org/DRAFTS/20-024.html#collection-description[OGC API - Common Standard], or a message referencing the collection metadata.
-- ``/collections/{collectionId}``: Notifies Subscribers whenever there is an update to a single collection (for example, spatial or temporal extents, new items, etc.). The message payload would be defined by the resource model of the given collection (items, etc.), or a message referencing the resource model of the collection.
+- ``/collections``: Notifies Subscribers whenever there is a change to the ``/collections`` resource (for example, addition of a new collection). The message payload would be collection metadata as defined in the https://docs.ogc.org/DRAFTS/20-024.html#collection-description[OGC API - Common Standard], or a message referencing the collection metadata.
+- ``/collections/{collectionId}``: Notifies Subscribers whenever there is an update to a single `collection` resource (for example, spatial or temporal extents, new items, etc.). The message payload would be defined by the resource model of the given collection (items, etc.), or a message referencing the resource model of the collection.
 
-Using the OGC API endpoint hierarchy provides the key benefit that developers implementing OGC API Standards do not need to learn a different, additional approach or hierarchy for Pub/Sub (same content, additional interface).
+Using the OGC API service endpoints of the URL path of resource and sub-resources provides the key benefit that developers implementing OGC API Standards do not need to learn a different, additional approach or resource path for Pub/Sub (same content, additional interface).
 
 include::../requirements/pubsub-channels/REQ_rc-channels.adoc[]
 include::../recommendations/pubsub-channels/REC_message-payloads.adoc[]