From ad885c08ee214687742eff6620891e12a67f0bb3 Mon Sep 17 00:00:00 2001 From: Chris Little Date: Thu, 11 Jan 2024 12:19:43 +0000 Subject: [PATCH 01/41] Update document.adoc Editorial comments --- extensions/pubsub/standard/document.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/extensions/pubsub/standard/document.adoc b/extensions/pubsub/standard/document.adoc index 0e9cf6ace..e5106abb0 100644 --- a/extensions/pubsub/standard/document.adoc +++ b/extensions/pubsub/standard/document.adoc @@ -1,4 +1,4 @@ -= OGC API - Environmental Data Retrieval - Part 2: Publish-Subscribe workflow += OGC API - Environmental Data Retrieval - Part 2: Publish-Subscribe Workflow :doctype: standard :encoding: utf-8 :lang: en From 1471e1479721b6154316cd615994aac95728844c Mon Sep 17 00:00:00 2001 From: Chris Little Date: Thu, 11 Jan 2024 12:58:07 +0000 Subject: [PATCH 02/41] Update clause_0_front_material.adoc Editorial consistency --- .../standard/sections/clause_0_front_material.adoc | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/extensions/pubsub/standard/sections/clause_0_front_material.adoc b/extensions/pubsub/standard/sections/clause_0_front_material.adoc index b7a591ae6..3df91e956 100644 --- a/extensions/pubsub/standard/sections/clause_0_front_material.adoc +++ b/extensions/pubsub/standard/sections/clause_0_front_material.adoc @@ -2,7 +2,13 @@ [NOTE] ==== -This specification provides an overview of Publish-Subscribe patterns specific to event driven data workflows, as well as options for realizing Publish-Subscribe workflow in OGC APIs. The document builds on the OGC Publish-Subscribe White Paper (OGC document 20-081), as well as the Discussion paper for Publish-Subscribe workflow in OGC APIs (OGC document 23-013), and provides a baseline for Pub/Sub within the OGC API ecosystem. +The Environmental Data Retrieval - Part 2 Standard provides: + +1. Requirements for Publish-Subscribe patterns specific to event driven data workflows and + +2. Options for realizing Publish-Subscribe workflow in OGC APIs. + +The Standard is based on the OGC Publish-Subscribe White Paper https://portal.ogc.org/files/?artifact_id=94904&version=1[OGC 20-081], as well as the Discussion paper for Publish-Subscribe workflow in OGC APIs https://docs.ogc.org/dp/23-013.html[OGC 23-013]. The goal of this Standard is to provide a baseline for Pub/Sub within the OGC API ecosystem. ==== //// @@ -30,7 +36,7 @@ Attention is drawn to the possibility that some of the elements of this document [abstract] == Abstract -OGC APIs provide Web based capabilities which are typically based on polling for collection resource updates (new features/records items, coverages, maps, etc.). Depending on a collection’s temporal resolution or frequency of updates, an event-driven / Publish-Subscribe architecture provides a time, efficient and low latency approach for delivery of data updates. This specification provides recommendations on applying Publish-Subscribe architectural patterns to OGC APIs. +OGC APIs provide Web based capabilities which are typically based on polling for collection resource updates (new features/records items, coverages, maps, etc.). Depending on a collection’s temporal resolution or frequency of updates, an event-driven / Publish-Subscribe architecture provides a time, efficient and low latency approach for delivery of data updates. The OGC API - Environmental Data Retrieval - Part 2: Publish-Subscribe Workflow provides recommendations on applying Publish-Subscribe architectural patterns to implementations of one or more OGC APIs. == Keywords @@ -41,7 +47,7 @@ OGC APIs provide Web based capabilities which are typically based on polling for [NOTE] ==== -OGC APIs provide Web based capabilities which are typically based on polling for collection resource updates (new features/records items, coverages, maps, etc.). Depending on a collection’s temporal resolution or frequency of updates, an event-driven / Publish-Subscribe architecture provides a time, efficient and low latency approach for delivery of data updates. The following requirements and recommendations apply to Publish-Subscribe architectural patterns to OGC APIs. +Implementations of OGC API Standards provide Web based capabilities that are typically based on polling for collection resource updates (new features/records items, coverages, maps, etc.). Depending on a collection’s temporal resolution or frequency of updates, an event-driven / Publish-Subscribe architecture provides a time, efficient and low latency approach for delivery of data updates. The following requirements and recommendations apply to Publish-Subscribe architectural patterns applicable to various OGC API Standards and their implementations. Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights. From 5d2752e20be38f229d681c7966544ae7561f8f11 Mon Sep 17 00:00:00 2001 From: Chris Little Date: Thu, 11 Jan 2024 13:00:23 +0000 Subject: [PATCH 03/41] Update clause_1_scope.adoc Editorial consistency --- extensions/pubsub/standard/sections/clause_1_scope.adoc | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/extensions/pubsub/standard/sections/clause_1_scope.adoc b/extensions/pubsub/standard/sections/clause_1_scope.adoc index 67fa13aa3..6b52e7689 100644 --- a/extensions/pubsub/standard/sections/clause_1_scope.adoc +++ b/extensions/pubsub/standard/sections/clause_1_scope.adoc @@ -1,10 +1,10 @@ == Scope [NOTE] ==== -This specification 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. -This specification defines a discovery capability that contains a topic structure in support of binding to notifications for data access and retrieval. +This Standard defines a discovery capability that contains a topic structure in support of binding to notifications for data access and retrieval. -This specification defines a baseline message payload which can contain summary descriptive information in GeoJSON about a given notification for new data events (new granule, new model run, etc.). +This Standard defines a baseline message payload which can contain summary descriptive information in GeoJSON about a given notification for new data events (new granule, new model run, etc.). ==== From 52938a166e397643e2b96e20fe82034c6597aa6a Mon Sep 17 00:00:00 2001 From: Chris Little Date: Thu, 11 Jan 2024 13:04:26 +0000 Subject: [PATCH 04/41] Update clause_2_conformance.adoc Editorial consistency --- .../pubsub/standard/sections/clause_2_conformance.adoc | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/extensions/pubsub/standard/sections/clause_2_conformance.adoc b/extensions/pubsub/standard/sections/clause_2_conformance.adoc index eb7f65ef7..d2445e4d9 100644 --- a/extensions/pubsub/standard/sections/clause_2_conformance.adoc +++ b/extensions/pubsub/standard/sections/clause_2_conformance.adoc @@ -1,15 +1,15 @@ == Conformance -This standard defines Publish-Subscribe patterns specific to event driven data workflows, as well as options for realizing Publish-Subscribe workflow in OGC APIs. +This Standard defines Publish-Subscribe patterns specific to event driven data workflows, as well as options for realizing Publish-Subscribe workflows in implementations of OGC API Standards. Requirements for two standardization target types are considered: * API integration -* Pubsub channels, and +* PubSub channels, and * Message payload -Conformance with this standard shall be checked using all the relevant tests specified in Annex A (normative) of this document. The framework, concepts, and methodology for testing, and the criteria to be achieved to claim conformance are specified in the OGC Compliance Testing Policies and Procedures and the OGC Compliance Testing web site. +Conformance with this Standard shall be checked using all the relevant tests specified in Annex A (normative) of this document. The framework, concepts, and methodology for testing, and the criteria to be achieved to claim conformance are specified in the OGC Compliance Testing Policies and Procedures and the OGC Compliance Testing web site. -In order to conform to this OGC® interface standard, a software implementation shall choose to implement: +In order to conform to this Standard, a software implementation shall choose to implement: * Any one of the conformance levels specified in Annex A (normative). * Any one of the Distributed Computing Platform profiles specified in Annexes TBD through TBD (normative). From 00891aabbe6af1a969d6f2ce778766b2ad5c663a Mon Sep 17 00:00:00 2001 From: Chris Little Date: Thu, 11 Jan 2024 13:07:37 +0000 Subject: [PATCH 05/41] Update clause_4_terms_and_definitions.adoc --- .../sections/clause_4_terms_and_definitions.adoc | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/extensions/pubsub/standard/sections/clause_4_terms_and_definitions.adoc b/extensions/pubsub/standard/sections/clause_4_terms_and_definitions.adoc index fa7ed1284..a2b36e4d8 100644 --- a/extensions/pubsub/standard/sections/clause_4_terms_and_definitions.adoc +++ b/extensions/pubsub/standard/sections/clause_4_terms_and_definitions.adoc @@ -5,23 +5,27 @@ This document uses the terms defined in Sub-clause 5.3 of <>, which For the purposes of this document, the following additional terms and definitions apply. === Broker - Intermediary between Subscribers and other Publishers which have been previously registered with the Broker. The Broker is not the original producer of Messages, but acts as an intermediary, (re-)publishing messages received from other Publishers and decoupling them from their Subscribers. -=== Subscriber +=== Collection +A geospatial resource that may be available as one or more sub-resource distributions that conform to one or more OGC API standards. (OGC 20-024) + +=== Dataset +A collection of data, published or curated by a single agent, and available for access or download in one or more representations. (DCAT) + +=== Distribution +A specific representation of a dataset. A dataset might be available in multiple serializations that may differ in various ways, including natural language, media-type or format, schematic organization, temporal and spatial resolution, level of detail or profiles (which might specify any or all of the above). (DCAT) +=== Subscriber An entity that creates a subscription to a Publisher. === Message - A container within which data (such as JSON, XML, binary data, or other content) is transported. Messages may include additional information beyond data, including headers or other metadata used for routing or security purposes. === Channel - A term (string) used to filter messages from a Broker. === Abbreviated terms - AMQP:: Advanced Message Queuing Protocol AMQPS:: From e3c37146d37cb214a670d0dd8b09afe6cf8007e3 Mon Sep 17 00:00:00 2001 From: Chris Little Date: Thu, 11 Jan 2024 13:10:31 +0000 Subject: [PATCH 06/41] Update clause_6_informative_text.adoc Editorial consistency --- .../pubsub/standard/sections/clause_6_informative_text.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/extensions/pubsub/standard/sections/clause_6_informative_text.adoc b/extensions/pubsub/standard/sections/clause_6_informative_text.adoc index 98c374942..7c28a39ed 100644 --- a/extensions/pubsub/standard/sections/clause_6_informative_text.adoc +++ b/extensions/pubsub/standard/sections/clause_6_informative_text.adoc @@ -1,4 +1,4 @@ [obligation=informative] == Overview -OGC APIs provide Web based capabilities which are typically based on polling for collection resource updates (new features/records items, coverages, maps, etc.). Depending on a collection’s temporal resolution or frequency of updates, an event-driven / Publish-Subscribe architecture provides a time, efficient and low latency approach for delivery of data updates. The following requirements and recommendations apply to Publish-Subscribe architectural patterns to OGC APIs. +Implementations of OGC API Standards provide Web based capabilities which are typically based on polling for collection resource updates (new features/records items, coverages, maps, etc.). Depending on a collection’s temporal resolution or frequency of updates, an event-driven / Publish-Subscribe architecture provides a time, efficient and low latency approach for delivery of data resource updates. The following requirements and recommendations apply to Publish-Subscribe architectural patterns for use with implementations of OGC API Standards. From a02574782b031400370583f2424a04ddf14d2b6f Mon Sep 17 00:00:00 2001 From: Chris Little Date: Thu, 11 Jan 2024 16:19:56 +0000 Subject: [PATCH 07/41] Update clause_7_pubsub.adoc Editorial Consistency --- .../standard/sections/clause_7_pubsub.adoc | 33 ++++++++++--------- 1 file changed, 17 insertions(+), 16 deletions(-) diff --git a/extensions/pubsub/standard/sections/clause_7_pubsub.adoc b/extensions/pubsub/standard/sections/clause_7_pubsub.adoc index 4f75aeb34..ab1553b48 100644 --- a/extensions/pubsub/standard/sections/clause_7_pubsub.adoc +++ b/extensions/pubsub/standard/sections/clause_7_pubsub.adoc @@ -7,35 +7,34 @@ OGC APIs provide Web based capabilities which are typically based on polling for include::../requirements/requirements_class_pubsub.adoc[] -Event-driven workflows provide publish-subscribe based capabilities as part of information systems and architectures. The publish-subscribe model also provides efficiencies in providing data "as it happens", thereby alleviating potential clients from continuous polling to check on the availability of new data/resources. +Event-driven workflows provide publish-subscribe based capabilities as part of information systems and architectures. The publish-subscribe model also provides efficiencies in providing data "as it happens", thereby preventing potential clients from continuous polling to check on the availability of new data/resources. -The Open Geospatial Consortium (OGC) has conducted significant work on event-based models and architectures. The publish-subscribe model results in less network traffic and more timely responses to manage event-based models such as urgent, temporally unpredictable data (examples include, but are not limited to: weather or hazard warnings, sensor data). +The Open Geospatial Consortium (OGC) has conducted significant work on event-based models and architectures. The publish-subscribe model results in less network traffic and more timely responses to manage event-based models such as urgent, temporally unpredictable data (examples include, but are not limited to: traffic conditions, weather or hazard warnings, and real-time sensor data). -Building on the OGC Publish-Subscribe Interface Standard, as well as the recommendations put forward in the OGC Pub/Sub White Paper (OGC 20-046) produced as part of OGC Testbed 12, as well as the Discussion paper for Publish-Subscribe workflow in OGC APIs (OGC 23-013) this specification discusses approaches for integrating publish-subscribe architecture into the OGC API suite of standards. +Building on the OGC Publish-Subscribe Interface Standard https://docs.ogc.org/is/13-131r1/13-131r1.html[OGC 13-131r1], as well as the recommendations put forward in the OGC Pub/Sub White Paper [OGC 20-046] produced as part of OGC Testbed 12, as well as the Discussion paper for Publish-Subscribe workflow in OGC APIs [OGC 23-013], the EDR - Part 2: Publish-Subscribe Standard discusses approaches for integrating publish-subscribe architecture into the OGC API suite of Standards. include::../recommendations/pubsub/PER_protocols.adoc[] === OGC API Considerations -The OGC API building block approach is typically implemented for shared components of APIs in support of polling workflow. This means the client initiates and invokes requests and receives responses from the server, using HTTP. A key concept of the OGC API building blocks 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 afchitecture is the endpoint hierarchy, 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/filtering) +* 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/filtering) -The above workflow requires adherence to a hierarchy of channels, autodiscovery of channels, as well as processing of generic messages for broad interoperabilty by all components. +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. ==== Message payloads -For smaller payload workflow, OGC APIs can additionally provide a channel for notification metadata in order to receive a smaller message payload, which a user can process to determine whether to further interact with the reference data granule or resource. +For smaller payload workflow, implementations of OGC API Standards can additionally provide a channel for notification metadata in order to receive a smaller message payload, which a user can process to determine whether to further interact with the reference data granule or resource. include::../recommendations/pubsub/REC_message-payloads.adoc[] ==== AsyncAPI -Following the recommendations of the Pub/Sub White Paper, AsyncAPI provides an event-driven equivalent of what is provided by OpenAPI for OGC APIs (description of protocols, channels, parameters, models, etc.). An OGC API landing page can provide a link to an AsyncAPI document as follows: +Based on research and testing, the Pub/Sub White Paper recommended the use of AsyncAPI. AsyncAPI provides an event-driven equivalent of what is provided by OpenAPI for OGC API Standards (description of protocols, channels, parameters, models, etc.). An implementation of the OGC API landing page requirements class can provide a link to an AsyncAPI document as follows: -.OGC API landing page AsyncAPI link example [source,json] ---- { @@ -50,11 +49,13 @@ include::../requirements/pubsub/REQ_rc-api.adoc[] ==== Providing notification metadata as an OGC API endpoint -For Brokers providing notification metadata (as opposed to actual data payloads), an OGC API can, in parallel, easily provide GeoJSON-based notification messages via an OGC API - Features endpoint. Providing message payloads via an OGC API provides the additional benefit of querying for past messages over time in case of a lost connection. +For Brokers providing notification metadata (as opposed to actual data payloads), an implementation of OGC API Building Blocks can, in parallel, readily provide GeoJSON-based notification messages via an OGC API - Features endpoint. Providing message payloads via an implementation of OGC API Standard(s) provides the additional benefit of querying for past messages over time in case of a lost connection. ==== Providing Pub/Sub links to collection updates -The links array could also provide references to the Pub/Sub capabilities available on the service; a *collection* link could reference a collection update notification channel: +The links array could also provide references to the Pub/Sub capabilities available on the service. A *collection* link could reference a collection update notification channel. + +NOTE: In the OGC API Suite of Standards, a collection is a geospatial resource (such as a dataset) that may be available as one or more sub-resource distributions that conform to one or more OGC API standards. .OGC API Pub/Sub link example to new collection notifications [source,json] @@ -70,9 +71,9 @@ The links array could also provide references to the Pub/Sub capabilities availa An *items* link could reference a data payload channel: -.OGC API Pub/Sub link example to collection item notifications +.OGC API Pub/Sub link examples to collection item notifications -OGC API - Features example +An OGC API - Features example [source,json] ---- { @@ -84,7 +85,7 @@ OGC API - Features example } ---- -OGC API - EDR example +An OGC API - EDR example [source,json] ---- { From f3ca01f889caa0e3bbbca2684154536d96308faf Mon Sep 17 00:00:00 2001 From: Chris Little Date: Thu, 11 Jan 2024 16:26:16 +0000 Subject: [PATCH 08/41] Update clause_8_pubsub-channels.adoc Editorial consistency --- .../standard/sections/clause_8_pubsub-channels.adoc | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/extensions/pubsub/standard/sections/clause_8_pubsub-channels.adoc b/extensions/pubsub/standard/sections/clause_8_pubsub-channels.adoc index 063ef7af3..c0c086e34 100644 --- a/extensions/pubsub/standard/sections/clause_8_pubsub-channels.adoc +++ b/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 OGC API resources normally available in the same way. Below are examples of OGC endpoints normally available via HTTP, and how they can be re-used as topics for Pub/Sub workflow: +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: -- ``/collections``: notifies Subscribers whenever there is a change to the ``/collections`` OGC API endpoint (for example, addition of a new collection). The message payload would be collection metadata as defined by OGC API - Common, or a message referencing same -- ``/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 reference same +- ``/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 OGC API - Common Standard, or a message referencing same. +- ``/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 reference same -Using the OGC API endpoint hierarchy provides the key benefit that OGC API users do not need to learn a different, additional approach or hierarchy for Pub/Sub (same content, additional interface). +Using the OGC API endpoint hierarchy provides the key benefit that users implementing OGC API Standards do not need to learn a different, additional approach or hierarchy for Pub/Sub (same content, additional interface). include::../requirements/pubsub-channels/REQ_rc-channels.adoc[] include::../recommendations/pubsub-channels/REC_message-payloads.adoc[] From 3c03d841a8e68cd23d18917f8853948e5185517c Mon Sep 17 00:00:00 2001 From: Chris Little Date: Thu, 11 Jan 2024 16:32:35 +0000 Subject: [PATCH 09/41] Update clause_9_pubsub-message-payload.adoc Editorial Consistency --- .../clause_9_pubsub-message-payload.adoc | 19 ++++++++----------- 1 file changed, 8 insertions(+), 11 deletions(-) diff --git a/extensions/pubsub/standard/sections/clause_9_pubsub-message-payload.adoc b/extensions/pubsub/standard/sections/clause_9_pubsub-message-payload.adoc index 46f615f5f..6e32275b2 100644 --- a/extensions/pubsub/standard/sections/clause_9_pubsub-message-payload.adoc +++ b/extensions/pubsub/standard/sections/clause_9_pubsub-message-payload.adoc @@ -5,18 +5,18 @@ include::../requirements/requirements_class_pubsub_message_payload.adoc[] -A key component of Pub/Sub workflows is message payload. Once a client subscribes to one or more -channels from a given Pub/Sub server, notifications messages are sent accordingly using a given +A key component of Pub/Sub workflows is the message payload. Once a client subscribes to one or more +channels from a given Pub/Sub server, notifications messages are sent using a given representation or encoding. Notification messages can be put forth using any encoding that is deemed suitable by a given publisher. -While the Publish-Subscribe (Pub/Sub) Requirements Class recommended a machine readable message payload, -this Requirements Class provides further requirements for interoperability of message payloads as part of -an OGC API ecosystem. +While the Publish-Subscribe (Pub/Sub) Requirements Class recommends a machine-readable message payload, +the Message Payload Requirements Class provides further requirements for interoperability of message payloads as part of +an OGC API implementation ecosystem. ==== GeoJSON compliance -_GeoJSON_ provides a compact and machine readable encoding as a baseline for message notification. +_GeoJSON_ can provide a compact and machine readable encoding as a baseline for message notification. include::../requirements/pubsub-message-payload/REQ_rc-geojson.adoc[] include::../recommendations/pubsub-message-payload/REC_links.adoc[] @@ -36,9 +36,7 @@ include::../requirements/pubsub-message-payload/REQ_rc-id.adoc[] ===== pubtime -The ``pubtime`` property identifies the date/time of when the message was posted/published, in RFC3339 format, in -the UTC timezone (``Z``). The publication date/time is critical for subscribers to prevent message loss in -providing awareness of how far behind the publisher they may be). +The ``pubtime`` property identifies the date/time of when the message was posted/published. `datetime` is published as specified in RFC3339 Clause 5.6 in the UTC timezone (``Z``). The publication date/time is critical for subscribers to prevent message loss in providing awareness of how far behind the publisher they may be. .Example pubtime property [source,json] @@ -55,8 +53,7 @@ include::../requirements/pubsub-message-payload/REQ_rc-pubtime.adoc[] ===== operation The ``operation`` property indicates the stage of the lifecycle for the resource described in the notification, -and can be used to notify users that a resource has been updated or deleted. The default value if not specified -is ``create``. +and can be used to notify users that a resource has been updated or deleted. If not specified, the default value is ``create``. [source,json] ---- From efca273a9e6cbf37324c0e1614f3f1f86647e760 Mon Sep 17 00:00:00 2001 From: Chris Little Date: Thu, 11 Jan 2024 16:35:22 +0000 Subject: [PATCH 10/41] Update annex-pubsub-message-payload.adoc Editorial Consistency --- .../standard/sections/annex-pubsub-message-payload.adoc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/extensions/pubsub/standard/sections/annex-pubsub-message-payload.adoc b/extensions/pubsub/standard/sections/annex-pubsub-message-payload.adoc index adce1e706..b9e7a7a46 100644 --- a/extensions/pubsub/standard/sections/annex-pubsub-message-payload.adoc +++ b/extensions/pubsub/standard/sections/annex-pubsub-message-payload.adoc @@ -6,9 +6,9 @@ === Pub/Sub Message Payload Example -The WMO WIS2 standard notification message format ensures that the WIS2 ecosystem (data publisher, data user, and global services) is a robust, effective, and unified exchange platform for weather, climate, and water data. The message provides notification metadata about the availability of a new data granule. The message is encoded using a GeoJSON baseline, and provides detailed information on the data notification (associated datetime of the granule, publishing datetime, integrity), as well as access to the data via a link object or inline content (useful for encoding small messages). Geometry is required (given GeoJSON requirements), however can be expressed with a null value when generating the geometry in the message is not possible, practical or timely for data publishers. To support extensibility, additional properties are also valid (given the default definition in JSON Schema). +The WMO WIS2 standard notification message format ensures that the WIS2 ecosystem (data publisher, data user, and global services) is a robust, effective, and unified exchange platform for weather, climate, and water data. The message provides notification metadata about the availability of a new data granule. The message is encoded using a GeoJSON baseline, and provides detailed information on the data notification (associated datetime of the granule, publishing datetime, integrity), as well as access to the data via a link object or inline content (useful for encoding small messages). Geometry is required (given GeoJSON requirements), however geometry can be expressed with a null value when generating the geometry in the message is not possible, practical or timely for data publishers. To support extensibility, additional properties are also valid (given the default definition in JSON Schema). -Using a GeoJSON baseline as the message payload allows for broad interoperability given the large ecosystem of tooling (decoders, encoders) supporting the same approach. An example web application demonstrating the ease of integration can be found at https://kralidis.ca/tmp/wis2-data-notifications.html. +Using a GeoJSON baseline as the message payload supports broad interoperability given the large ecosystem of tooling (decoders, encoders) supporting the same approach. An example web application demonstrating the ease of integration can be found at https://kralidis.ca/tmp/wis2-data-notifications.html. An example WIS2 Notification Message can be found below, extending the OGC API - Pub/Sub Notification Message Requirements with domain specific properties as required: From 500cf9a4d64f368fdd61abdd2bd268a08aa6f9f9 Mon Sep 17 00:00:00 2001 From: Chris Little Date: Thu, 11 Jan 2024 17:53:36 +0000 Subject: [PATCH 11/41] Update clause_7_pubsub.adoc Punctuation --- extensions/pubsub/standard/sections/clause_7_pubsub.adoc | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/extensions/pubsub/standard/sections/clause_7_pubsub.adoc b/extensions/pubsub/standard/sections/clause_7_pubsub.adoc index ab1553b48..c82474b04 100644 --- a/extensions/pubsub/standard/sections/clause_7_pubsub.adoc +++ b/extensions/pubsub/standard/sections/clause_7_pubsub.adoc @@ -19,9 +19,9 @@ include::../recommendations/pubsub/PER_protocols.adoc[] 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 afchitecture is the endpoint hierarchy, 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/filtering) +* 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/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. From ba1a86331fc6881c5f95771d4cb0257a667ba8f3 Mon Sep 17 00:00:00 2001 From: Chris Little Date: Thu, 11 Jan 2024 18:12:46 +0000 Subject: [PATCH 12/41] Update clause_8_pubsub-channels.adoc --- .../pubsub/standard/sections/clause_8_pubsub-channels.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/extensions/pubsub/standard/sections/clause_8_pubsub-channels.adoc b/extensions/pubsub/standard/sections/clause_8_pubsub-channels.adoc index c0c086e34..4f8901ed6 100644 --- a/extensions/pubsub/standard/sections/clause_8_pubsub-channels.adoc +++ b/extensions/pubsub/standard/sections/clause_8_pubsub-channels.adoc @@ -12,7 +12,7 @@ The OGC API endpoint hierarchy can be used in parallel as a channel description - ``/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 OGC API - Common Standard, or a message referencing same. - ``/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 reference same -Using the OGC API endpoint hierarchy provides the key benefit that users 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 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). include::../requirements/pubsub-channels/REQ_rc-channels.adoc[] include::../recommendations/pubsub-channels/REC_message-payloads.adoc[] From 8a699e00a3f9a34b5112f9efbadb1f8d9c0ab96b Mon Sep 17 00:00:00 2001 From: Chris Little Date: Thu, 11 Jan 2024 18:16:50 +0000 Subject: [PATCH 13/41] Update annex-history.adoc Editorial consistency --- extensions/pubsub/standard/sections/annex-history.adoc | 1 + 1 file changed, 1 insertion(+) diff --git a/extensions/pubsub/standard/sections/annex-history.adoc b/extensions/pubsub/standard/sections/annex-history.adoc index 991a86b99..24fdbe97e 100644 --- a/extensions/pubsub/standard/sections/annex-history.adoc +++ b/extensions/pubsub/standard/sections/annex-history.adoc @@ -5,4 +5,5 @@ |=== |Date |Release |Editor | Primary clauses modified |Description |2023-08-28 |0.1 |T. Kralidis|all |bootstrap +|2024-01-10 |0.2 |C. Little|all |editorial consistency |=== From 67c14141633e8e93a717d8fdfd00ca042b309e85 Mon Sep 17 00:00:00 2001 From: Chris Little Date: Thu, 11 Jan 2024 18:22:52 +0000 Subject: [PATCH 14/41] Update annex-bibliography.adoc Delete guidance but leave examples. otherwise delete complete section --- .../standard/sections/annex-bibliography.adoc | 13 ------------- 1 file changed, 13 deletions(-) diff --git a/extensions/pubsub/standard/sections/annex-bibliography.adoc b/extensions/pubsub/standard/sections/annex-bibliography.adoc index 50401467d..93a7f3ebb 100644 --- a/extensions/pubsub/standard/sections/annex-bibliography.adoc +++ b/extensions/pubsub/standard/sections/annex-bibliography.adoc @@ -2,21 +2,8 @@ [[Bibliography]] == Bibliography -[NOTE] -.Example Bibliography (Delete this note). -=============================================== -The TC has approved Springer LNCS as the official document citation type. - -Springer LNCS is widely used in technical and computer science journals and other publications - -* For citations in the text please use square brackets and consecutive numbers: [1], [2], [3] - -– Actual References: - [n] Journal: Author Surname, A.: Title. Publication Title. Volume number, Issue number, Pages Used (Year Published) [n] Web: Author Surname, A.: Title, http://Website-Url -=============================================== - * [[[OGC2015,OGCTB12]]], _OGC: OGC Testbed 12 Annex B: Architecture_ (2015). From 5a8d7af3d091acc194c5581d873c7a591748e5ae Mon Sep 17 00:00:00 2001 From: Chris Little Date: Thu, 11 Jan 2024 18:27:26 +0000 Subject: [PATCH 15/41] Update clause_7_pubsub.adoc Remove duplicated overview --- extensions/pubsub/standard/sections/clause_7_pubsub.adoc | 2 -- 1 file changed, 2 deletions(-) diff --git a/extensions/pubsub/standard/sections/clause_7_pubsub.adoc b/extensions/pubsub/standard/sections/clause_7_pubsub.adoc index c82474b04..3e9aa1d7b 100644 --- a/extensions/pubsub/standard/sections/clause_7_pubsub.adoc +++ b/extensions/pubsub/standard/sections/clause_7_pubsub.adoc @@ -1,8 +1,6 @@ [[pubsub-section]] == Requirements Class Publish-Subscribe (Pub/Sub) -OGC APIs provide Web based capabilities which are typically based on polling for collection resource updates (new features/records items, coverages, maps, etc.). Depending on a collection’s temporal resolution or frequency of updates, an event-driven / Publish-Subscribe architecture provides a time, efficient and low latency approach for delivery of data updates. The following requirements and recommendations apply to Publish-Subscribe architectural patterns to OGC APIs. - === Overview include::../requirements/requirements_class_pubsub.adoc[] From 742dfdf4e6ba7e7070e4b1cc2536e61ac534cfb9 Mon Sep 17 00:00:00 2001 From: Chris Little Date: Thu, 11 Jan 2024 18:35:30 +0000 Subject: [PATCH 16/41] Update clause_7_pubsub.adoc Link to Common --- extensions/pubsub/standard/sections/clause_7_pubsub.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/extensions/pubsub/standard/sections/clause_7_pubsub.adoc b/extensions/pubsub/standard/sections/clause_7_pubsub.adoc index 3e9aa1d7b..848a1d980 100644 --- a/extensions/pubsub/standard/sections/clause_7_pubsub.adoc +++ b/extensions/pubsub/standard/sections/clause_7_pubsub.adoc @@ -31,7 +31,7 @@ include::../recommendations/pubsub/REC_message-payloads.adoc[] ==== AsyncAPI -Based on research and testing, the Pub/Sub White Paper recommended the use of AsyncAPI. AsyncAPI provides an event-driven equivalent of what is provided by OpenAPI for OGC API Standards (description of protocols, channels, parameters, models, etc.). An implementation of the OGC API landing page requirements class can provide a link to an AsyncAPI document as follows: +Based on research and testing, the Pub/Sub White Paper recommended the use of AsyncAPI. AsyncAPI provides an event-driven equivalent of what is provided by OpenAPI for OGC API Standards (description of protocols, channels, parameters, models, etc.). An implementation of the https://ogcapi.ogc.org/common/overview.html[OGC API landing page requirements class] can provide a link to an AsyncAPI document as follows: [source,json] ---- From 467979019d65428d5e5b1f3edd799431e8c49f81 Mon Sep 17 00:00:00 2001 From: Chris Little Date: Thu, 11 Jan 2024 18:48:05 +0000 Subject: [PATCH 17/41] Update clause_7_pubsub.adoc Add link to Common and Collections --- extensions/pubsub/standard/sections/clause_7_pubsub.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/extensions/pubsub/standard/sections/clause_7_pubsub.adoc b/extensions/pubsub/standard/sections/clause_7_pubsub.adoc index 848a1d980..b40bcc361 100644 --- a/extensions/pubsub/standard/sections/clause_7_pubsub.adoc +++ b/extensions/pubsub/standard/sections/clause_7_pubsub.adoc @@ -53,7 +53,7 @@ For Brokers providing notification metadata (as opposed to actual data payloads) The links array could also provide references to the Pub/Sub capabilities available on the service. A *collection* link could reference a collection update notification channel. -NOTE: In the OGC API Suite of Standards, a collection is a geospatial resource (such as a dataset) that may be available as one or more sub-resource distributions that conform to one or more OGC API standards. +NOTE: In the OGC API Suite of Standards, a collection is a geospatial https://docs.ogc.org/DRAFTS/20-024.html#resource-definition[resource] (such as a dataset) that may be available as one or more sub-resource https://docs.ogc.org/DRAFTS/20-024.html#distribution-definition[distributions] that conform to one or more OGC API standards. See https://docs.ogc.org/DRAFTS/20-024.html#rc-collections-section[OGC API-Common: Part 2] .OGC API Pub/Sub link example to new collection notifications [source,json] From 9f4982ff9c2b2d0f6941dfe3bf0aa31c31456dda Mon Sep 17 00:00:00 2001 From: Chris Little Date: Thu, 11 Jan 2024 18:53:42 +0000 Subject: [PATCH 18/41] Update clause_7_pubsub.adoc --- extensions/pubsub/standard/sections/clause_7_pubsub.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/extensions/pubsub/standard/sections/clause_7_pubsub.adoc b/extensions/pubsub/standard/sections/clause_7_pubsub.adoc index b40bcc361..125cb2b3e 100644 --- a/extensions/pubsub/standard/sections/clause_7_pubsub.adoc +++ b/extensions/pubsub/standard/sections/clause_7_pubsub.adoc @@ -53,7 +53,7 @@ For Brokers providing notification metadata (as opposed to actual data payloads) The links array could also provide references to the Pub/Sub capabilities available on the service. A *collection* link could reference a collection update notification channel. -NOTE: In the OGC API Suite of Standards, a collection is a geospatial https://docs.ogc.org/DRAFTS/20-024.html#resource-definition[resource] (such as a dataset) that may be available as one or more sub-resource https://docs.ogc.org/DRAFTS/20-024.html#distribution-definition[distributions] that conform to one or more OGC API standards. See https://docs.ogc.org/DRAFTS/20-024.html#rc-collections-section[OGC API-Common: Part 2] +NOTE: In the OGC API Suite of Standards, a https://docs.ogc.org/DRAFTS/20-024.html#collection-description[collection] is a geospatial https://docs.ogc.org/DRAFTS/20-024.html#resource-definition[resource] (such as a dataset) that may be available as one or more sub-resource https://docs.ogc.org/DRAFTS/20-024.html#distribution-definition[distributions] that conform to one or more OGC API standards. See https://docs.ogc.org/DRAFTS/20-024.html#rc-collections-section[OGC API-Common: Part 2] .OGC API Pub/Sub link example to new collection notifications [source,json] From 2c03f0d2eaae2c3d00b22ea776a2564bd548c167 Mon Sep 17 00:00:00 2001 From: Chris Little Date: Thu, 11 Jan 2024 18:57:54 +0000 Subject: [PATCH 19/41] Update clause_8_pubsub-channels.adoc link to Common --- .../pubsub/standard/sections/clause_8_pubsub-channels.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/extensions/pubsub/standard/sections/clause_8_pubsub-channels.adoc b/extensions/pubsub/standard/sections/clause_8_pubsub-channels.adoc index 4f8901ed6..b2591af28 100644 --- a/extensions/pubsub/standard/sections/clause_8_pubsub-channels.adoc +++ b/extensions/pubsub/standard/sections/clause_8_pubsub-channels.adoc @@ -9,7 +9,7 @@ include::../requirements/requirements_class_pubsub_channels.adoc[] 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: -- ``/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 OGC API - Common Standard, or a message referencing same. +- ``/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 same. - ``/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 reference same 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). From 7c37ae1cfa79dad4b17ed1858645af5178924492 Mon Sep 17 00:00:00 2001 From: Chris Little Date: Thu, 11 Jan 2024 19:00:27 +0000 Subject: [PATCH 20/41] Update clause_8_pubsub-channels.adoc expand on `same` --- .../pubsub/standard/sections/clause_8_pubsub-channels.adoc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/extensions/pubsub/standard/sections/clause_8_pubsub-channels.adoc b/extensions/pubsub/standard/sections/clause_8_pubsub-channels.adoc index b2591af28..9e60fd13f 100644 --- a/extensions/pubsub/standard/sections/clause_8_pubsub-channels.adoc +++ b/extensions/pubsub/standard/sections/clause_8_pubsub-channels.adoc @@ -9,8 +9,8 @@ include::../requirements/requirements_class_pubsub_channels.adoc[] 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: -- ``/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 same. -- ``/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 reference same +- ``/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. 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). From d6f6557435228f9e9bcc24cf00c801dc7ed2585e Mon Sep 17 00:00:00 2001 From: Chris Little Date: Thu, 11 Jan 2024 19:09:00 +0000 Subject: [PATCH 21/41] Update PER_operation.adoc editorial consistency --- .../recommendations/pubsub-message-payload/PER_operation.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/extensions/pubsub/standard/recommendations/pubsub-message-payload/PER_operation.adoc b/extensions/pubsub/standard/recommendations/pubsub-message-payload/PER_operation.adoc index df726ca4d..ca83e485b 100644 --- a/extensions/pubsub/standard/recommendations/pubsub-message-payload/PER_operation.adoc +++ b/extensions/pubsub/standard/recommendations/pubsub-message-payload/PER_operation.adoc @@ -5,6 +5,6 @@ *A:* -An OGC API Pub/Sub Notification Message MAY provide the `+properties.operation+` property to indicate if a resource has been inserted. +A Pub/Sub Notification Message MAY provide the `+properties.operation+` property to indicate if a resource has been inserted. ==== From 95948d1b1c3405b51b855a657a59a03c3f81a263 Mon Sep 17 00:00:00 2001 From: Chris Little Date: Thu, 11 Jan 2024 19:11:55 +0000 Subject: [PATCH 22/41] Update REC_crs.adoc --- .../recommendations/pubsub-message-payload/REC_crs.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/extensions/pubsub/standard/recommendations/pubsub-message-payload/REC_crs.adoc b/extensions/pubsub/standard/recommendations/pubsub-message-payload/REC_crs.adoc index df13fd1b9..9b01f8710 100644 --- a/extensions/pubsub/standard/recommendations/pubsub-message-payload/REC_crs.adoc +++ b/extensions/pubsub/standard/recommendations/pubsub-message-payload/REC_crs.adoc @@ -4,6 +4,6 @@ *A:* -An OGC API Pub/Sub notification message encoding describing data in a CRS other than WGS84 SHOULD use OGC Features and Geometries JSON. +A Pub/Sub notification message encoding describing data in a CRS other than WGS84 SHOULD use OGC Features and Geometries JSON. ==== From bd66cf4a051b10112da52a646adf452d6b532268 Mon Sep 17 00:00:00 2001 From: Chris Little Date: Thu, 11 Jan 2024 19:13:35 +0000 Subject: [PATCH 23/41] Update PER_links.adoc editorial consistency --- .../pubsub/standard/recommendations/pubsub/PER_links.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/extensions/pubsub/standard/recommendations/pubsub/PER_links.adoc b/extensions/pubsub/standard/recommendations/pubsub/PER_links.adoc index 65932dbc5..e3ab58b48 100644 --- a/extensions/pubsub/standard/recommendations/pubsub/PER_links.adoc +++ b/extensions/pubsub/standard/recommendations/pubsub/PER_links.adoc @@ -5,7 +5,7 @@ *A:* -An OGC API collection endpoint MAY provide a link reference to a Publish-Subscribe server from an OGC API endpoint when Publish-Subscribe capabilities exist related to the OGC API collection endpoint. +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. *B:* From 0bce6d6beada58806584f3d1f7ef48d50fcf6fb5 Mon Sep 17 00:00:00 2001 From: Chris Little Date: Thu, 11 Jan 2024 19:15:16 +0000 Subject: [PATCH 24/41] Update PER_protocols.adoc editorial consistency --- .../pubsub/standard/recommendations/pubsub/PER_protocols.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/extensions/pubsub/standard/recommendations/pubsub/PER_protocols.adoc b/extensions/pubsub/standard/recommendations/pubsub/PER_protocols.adoc index 4ebb532fc..f011f8067 100644 --- a/extensions/pubsub/standard/recommendations/pubsub/PER_protocols.adoc +++ b/extensions/pubsub/standard/recommendations/pubsub/PER_protocols.adoc @@ -4,7 +4,7 @@ *A:* -A Publish-Subscribe MAY use the message queueing protocol of their choice/requirements. +A Publish-Subscribe MAY use the message queueing protocol of their choice and/or based on application requirements. ==== From c07e4eb34fd8b7f6b1ec80587cff9326bf020158 Mon Sep 17 00:00:00 2001 From: Chris Little Date: Thu, 11 Jan 2024 19:18:11 +0000 Subject: [PATCH 25/41] Update REQ_rc-channels.adoc editorial consistency --- .../standard/requirements/pubsub-channels/REQ_rc-channels.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/extensions/pubsub/standard/requirements/pubsub-channels/REQ_rc-channels.adoc b/extensions/pubsub/standard/requirements/pubsub-channels/REQ_rc-channels.adoc index 7fb911df5..f5e436e36 100644 --- a/extensions/pubsub/standard/requirements/pubsub-channels/REQ_rc-channels.adoc +++ b/extensions/pubsub/standard/requirements/pubsub-channels/REQ_rc-channels.adoc @@ -5,6 +5,6 @@ *A:* -Channels (topic/destination/node depending on protocol) which have equivalent OGC API functionality SHALL be expressed within an AsyncAPI channel with an ``x-ogc-api-link`` object. +Channels (topic/destination/node depending on protocol) that have equivalent API endpoint functionality SHALL be expressed within an AsyncAPI channel with an ``x-ogc-api-link`` object. ==== From 33ab6c67d940e1db83df8e2e748726572c876d4f Mon Sep 17 00:00:00 2001 From: Chris Little Date: Thu, 11 Jan 2024 19:59:06 +0000 Subject: [PATCH 26/41] Update REQ_rc-geojson.adoc editorial consistency --- .../requirements/pubsub-message-payload/REQ_rc-geojson.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/extensions/pubsub/standard/requirements/pubsub-message-payload/REQ_rc-geojson.adoc b/extensions/pubsub/standard/requirements/pubsub-message-payload/REQ_rc-geojson.adoc index 23a4f2294..374ec4fcd 100644 --- a/extensions/pubsub/standard/requirements/pubsub-message-payload/REQ_rc-geojson.adoc +++ b/extensions/pubsub/standard/requirements/pubsub-message-payload/REQ_rc-geojson.adoc @@ -5,6 +5,6 @@ *A:* -An OGC API Pub/Sub notification message encoding SHALL be compliant to IETF RFC7946 GeoJSON. +A Pub/Sub notification message encoding SHALL be compliant to IETF RFC7946 GeoJSON. ==== From 5177338f67da0be20e0a0a220474246c09df7f84 Mon Sep 17 00:00:00 2001 From: Chris Little Date: Thu, 11 Jan 2024 19:59:51 +0000 Subject: [PATCH 27/41] Update REQ_rc-id.adoc editorial consistency --- .../standard/requirements/pubsub-message-payload/REQ_rc-id.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/extensions/pubsub/standard/requirements/pubsub-message-payload/REQ_rc-id.adoc b/extensions/pubsub/standard/requirements/pubsub-message-payload/REQ_rc-id.adoc index 086777fb2..b30bb1886 100644 --- a/extensions/pubsub/standard/requirements/pubsub-message-payload/REQ_rc-id.adoc +++ b/extensions/pubsub/standard/requirements/pubsub-message-payload/REQ_rc-id.adoc @@ -5,6 +5,6 @@ *A:* -An OGC API Pub/Sub notification message SHALL provide an `+id+` property as a GUID. +A Pub/Sub notification message SHALL provide an `+id+` property as a GUID. ==== From 62050986b6855f0946f26879e6f306a8835abf1c Mon Sep 17 00:00:00 2001 From: Chris Little Date: Thu, 11 Jan 2024 20:00:46 +0000 Subject: [PATCH 28/41] Update REQ_rc-operation.adoc editorial consistency --- .../requirements/pubsub-message-payload/REQ_rc-operation.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/extensions/pubsub/standard/requirements/pubsub-message-payload/REQ_rc-operation.adoc b/extensions/pubsub/standard/requirements/pubsub-message-payload/REQ_rc-operation.adoc index dd4b94ebb..6428d5eb5 100644 --- a/extensions/pubsub/standard/requirements/pubsub-message-payload/REQ_rc-operation.adoc +++ b/extensions/pubsub/standard/requirements/pubsub-message-payload/REQ_rc-operation.adoc @@ -5,6 +5,6 @@ *A:* -An OGC API Pub/Sub Notification Message SHALL provide the `+properties.operation+` property to indicate if a resource has been updated or deleted. +A Pub/Sub Notification Message SHALL provide the `+properties.operation+` property to indicate if a resource has been updated or deleted. ==== From 112f6447b1ab5647a9937ed329236aa52d01f84f Mon Sep 17 00:00:00 2001 From: Chris Little Date: Thu, 11 Jan 2024 20:01:40 +0000 Subject: [PATCH 29/41] Update REQ_rc-pubtime.adoc editorial consistency --- .../requirements/pubsub-message-payload/REQ_rc-pubtime.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/extensions/pubsub/standard/requirements/pubsub-message-payload/REQ_rc-pubtime.adoc b/extensions/pubsub/standard/requirements/pubsub-message-payload/REQ_rc-pubtime.adoc index e0b81ec6b..65d9189d2 100644 --- a/extensions/pubsub/standard/requirements/pubsub-message-payload/REQ_rc-pubtime.adoc +++ b/extensions/pubsub/standard/requirements/pubsub-message-payload/REQ_rc-pubtime.adoc @@ -5,6 +5,6 @@ *A:* -An OGC API Pub/Sub notification message SHALL provide a `+properties.pubtime+` property in RFC3339 format. +A Pub/Sub notification message SHALL provide a `+properties.pubtime+` property in RFC3339 format. ==== From 976ea949571b1adea67705aa4afd20f44e21d2ab Mon Sep 17 00:00:00 2001 From: Chris Little Date: Thu, 11 Jan 2024 20:05:23 +0000 Subject: [PATCH 30/41] Update REQ_rc-api.adoc editorial consistency --- .../pubsub/standard/requirements/pubsub/REQ_rc-api.adoc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/extensions/pubsub/standard/requirements/pubsub/REQ_rc-api.adoc b/extensions/pubsub/standard/requirements/pubsub/REQ_rc-api.adoc index e810981ec..27325703e 100644 --- a/extensions/pubsub/standard/requirements/pubsub/REQ_rc-api.adoc +++ b/extensions/pubsub/standard/requirements/pubsub/REQ_rc-api.adoc @@ -5,12 +5,12 @@ *A:* -An OGC API landing page SHALL provide a link reference to the description of its Publish-Subscribe capabilities using a link relation of `+service-desc+`. +A landing page SHALL provide a link reference to the description of its Publish-Subscribe capabilities using a link relation of `+service-desc+`. --- *B:* -An OGC API SHALL provide the description of its Publish-Subscribe capabilities using AsyncAPI to describe supported protocols, channels and message payload descriptions. +An API SHALL provide the description of its Publish-Subscribe capabilities using AsyncAPI to describe supported protocols, channels and message payload descriptions. ==== From 99f7ce382adcb88dd0f7077021a8dede68fb32db Mon Sep 17 00:00:00 2001 From: Chris Little Date: Thu, 11 Jan 2024 20:23:13 +0000 Subject: [PATCH 31/41] Update REQ_rc-api.adoc Punctuation --- extensions/pubsub/standard/requirements/pubsub/REQ_rc-api.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/extensions/pubsub/standard/requirements/pubsub/REQ_rc-api.adoc b/extensions/pubsub/standard/requirements/pubsub/REQ_rc-api.adoc index 27325703e..391cb90fd 100644 --- a/extensions/pubsub/standard/requirements/pubsub/REQ_rc-api.adoc +++ b/extensions/pubsub/standard/requirements/pubsub/REQ_rc-api.adoc @@ -11,6 +11,6 @@ A landing page SHALL provide a link reference to the description of its Publish- *B:* -An API SHALL provide the description of its Publish-Subscribe capabilities using AsyncAPI to describe supported protocols, channels and message payload descriptions. +An API SHALL provide the description of its Publish-Subscribe capabilities using AsyncAPI to describe supported protocols, channels, and message payload descriptions. ==== From 4faedc86ffcbc3bd236439cad0126df413723557 Mon Sep 17 00:00:00 2001 From: Chris Little Date: Thu, 11 Jan 2024 20:41:49 +0000 Subject: [PATCH 32/41] Update annex-pubsub-message-payload.adoc GeoJSON baseline to GeoJSON object --- .../standard/sections/annex-pubsub-message-payload.adoc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/extensions/pubsub/standard/sections/annex-pubsub-message-payload.adoc b/extensions/pubsub/standard/sections/annex-pubsub-message-payload.adoc index b9e7a7a46..1709c4c17 100644 --- a/extensions/pubsub/standard/sections/annex-pubsub-message-payload.adoc +++ b/extensions/pubsub/standard/sections/annex-pubsub-message-payload.adoc @@ -6,9 +6,9 @@ === Pub/Sub Message Payload Example -The WMO WIS2 standard notification message format ensures that the WIS2 ecosystem (data publisher, data user, and global services) is a robust, effective, and unified exchange platform for weather, climate, and water data. The message provides notification metadata about the availability of a new data granule. The message is encoded using a GeoJSON baseline, and provides detailed information on the data notification (associated datetime of the granule, publishing datetime, integrity), as well as access to the data via a link object or inline content (useful for encoding small messages). Geometry is required (given GeoJSON requirements), however geometry can be expressed with a null value when generating the geometry in the message is not possible, practical or timely for data publishers. To support extensibility, additional properties are also valid (given the default definition in JSON Schema). +The WMO WIS2 standard notification message format ensures that the WIS2 ecosystem (data publisher, data user, and global services) is a robust, effective, and unified exchange platform for weather, climate, and water data. The message provides notification metadata about the availability of a new data granule. The message is encoded using a GeoJSON object, and provides detailed information on the data notification (associated datetime of the granule, publishing datetime, integrity), as well as access to the data via a link object or inline content (useful for encoding small messages). Geometry is required (given GeoJSON requirements), however geometry can be expressed with a null value when generating the geometry in the message is not possible, practical or timely for data publishers. To support extensibility, additional properties are also valid (given the default definition in JSON Schema). -Using a GeoJSON baseline as the message payload supports broad interoperability given the large ecosystem of tooling (decoders, encoders) supporting the same approach. An example web application demonstrating the ease of integration can be found at https://kralidis.ca/tmp/wis2-data-notifications.html. +Using a GeoJSON object as the message payload supports broad interoperability given the large ecosystem of tooling (decoders, encoders) supporting the same approach. An example web application demonstrating the ease of integration can be found at https://kralidis.ca/tmp/wis2-data-notifications.html. An example WIS2 Notification Message can be found below, extending the OGC API - Pub/Sub Notification Message Requirements with domain specific properties as required: From ea5d84563faa3b6155b1f182cccd9ffc3f38de3e Mon Sep 17 00:00:00 2001 From: Chris Little Date: Thu, 11 Jan 2024 20:59:43 +0000 Subject: [PATCH 33/41] Update document.adoc update date --- extensions/pubsub/standard/document.adoc | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/extensions/pubsub/standard/document.adoc b/extensions/pubsub/standard/document.adoc index e5106abb0..5e8da1210 100644 --- a/extensions/pubsub/standard/document.adoc +++ b/extensions/pubsub/standard/document.adoc @@ -7,14 +7,15 @@ :draft: 1.0 :external-id: http://www.opengis.net/doc/IS/ogcapi-edr-2/1.0 :docnumber: 23-057 -:received-date: 2023-08-28 -:issued-date: 2023-08-28 -:published-date: 2023-08-28 +:received-date: 2024-01-11 +:issued-date: 2024-01-10 +:published-date: 2024-01-10 :fullname: Tom Kralidis :role: editor :fullname_2: Mark Burgoyne -:fullname_3: Steve Olson -:fullname_4: Shane Mill +:fullname_3: Chris Little +:fullname_4: Steve Olson +:fullname_5: Shane Mill :docsubtype: Interface :keywords: OGC API, Pub/Sub, Publish, Subscribe, Publish-Subscribe, Event driven architecture, Asynchronous, OGC document, OGC :submitting-organizations: Meteorological Service of Canada; UK Met Office; US National Weather Service; From a5771630e6990b761b04c3b308622e3a2c9f89db Mon Sep 17 00:00:00 2001 From: Chris Little Date: Thu, 11 Jan 2024 21:02:10 +0000 Subject: [PATCH 34/41] Update clause_0_front_material.adoc --- .../pubsub/standard/sections/clause_0_front_material.adoc | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/extensions/pubsub/standard/sections/clause_0_front_material.adoc b/extensions/pubsub/standard/sections/clause_0_front_material.adoc index 3df91e956..af9fdf90b 100644 --- a/extensions/pubsub/standard/sections/clause_0_front_material.adoc +++ b/extensions/pubsub/standard/sections/clause_0_front_material.adoc @@ -1,6 +1,5 @@ .Preface -[NOTE] ==== The Environmental Data Retrieval - Part 2 Standard provides: @@ -45,7 +44,6 @@ OGC APIs provide Web based capabilities which are typically based on polling for == Preface -[NOTE] ==== Implementations of OGC API Standards provide Web based capabilities that are typically based on polling for collection resource updates (new features/records items, coverages, maps, etc.). Depending on a collection’s temporal resolution or frequency of updates, an event-driven / Publish-Subscribe architecture provides a time, efficient and low latency approach for delivery of data updates. The following requirements and recommendations apply to Publish-Subscribe architectural patterns applicable to various OGC API Standards and their implementations. @@ -79,9 +77,9 @@ All questions regarding this submission should be directed to the editor or the |*Name* |*Affiliation* |Tom Kralidis |Meteorological Service of Canada -|Steve Olson |NOAA/NWS |Chris Little|UK Met Office |Mark Burgoyne|UK Met Office +|Steve Olson |NOAA/NWS |Shane Mill |NOAA/NWS |=== From 563df6fc356728443a59ab020db866babe046a5d Mon Sep 17 00:00:00 2001 From: Chris Little Date: Thu, 11 Jan 2024 21:02:54 +0000 Subject: [PATCH 35/41] Update clause_1_scope.adoc removed Note tag --- extensions/pubsub/standard/sections/clause_1_scope.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/extensions/pubsub/standard/sections/clause_1_scope.adoc b/extensions/pubsub/standard/sections/clause_1_scope.adoc index 6b52e7689..9c4edbd9a 100644 --- a/extensions/pubsub/standard/sections/clause_1_scope.adoc +++ b/extensions/pubsub/standard/sections/clause_1_scope.adoc @@ -1,5 +1,5 @@ == Scope -[NOTE] + ==== 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. From bce9d3726993e87316f4544cacdca08dab6a01f2 Mon Sep 17 00:00:00 2001 From: Chris Little Date: Thu, 11 Jan 2024 21:13:16 +0000 Subject: [PATCH 36/41] Update document.adoc --- extensions/pubsub/standard/document.adoc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/extensions/pubsub/standard/document.adoc b/extensions/pubsub/standard/document.adoc index 5e8da1210..c59cfd815 100644 --- a/extensions/pubsub/standard/document.adoc +++ b/extensions/pubsub/standard/document.adoc @@ -12,8 +12,8 @@ :published-date: 2024-01-10 :fullname: Tom Kralidis :role: editor -:fullname_2: Mark Burgoyne -:fullname_3: Chris Little +:fullname_2: Chris Little +:fullname_3: Mark Burgoyne :fullname_4: Steve Olson :fullname_5: Shane Mill :docsubtype: Interface From 0c27c0108a6879c6825c540b3c283ad01b1d0a1c Mon Sep 17 00:00:00 2001 From: Chris Little Date: Thu, 11 Jan 2024 21:13:43 +0000 Subject: [PATCH 37/41] Update document.adoc correct date --- extensions/pubsub/standard/document.adoc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/extensions/pubsub/standard/document.adoc b/extensions/pubsub/standard/document.adoc index c59cfd815..186980838 100644 --- a/extensions/pubsub/standard/document.adoc +++ b/extensions/pubsub/standard/document.adoc @@ -8,8 +8,8 @@ :external-id: http://www.opengis.net/doc/IS/ogcapi-edr-2/1.0 :docnumber: 23-057 :received-date: 2024-01-11 -:issued-date: 2024-01-10 -:published-date: 2024-01-10 +:issued-date: 2024-01-11 +:published-date: 2024-01-11 :fullname: Tom Kralidis :role: editor :fullname_2: Chris Little From c66f167133bdb856c20c9ad6b417874da35d22d7 Mon Sep 17 00:00:00 2001 From: Chris Little Date: Thu, 11 Jan 2024 21:16:38 +0000 Subject: [PATCH 38/41] Update clause_2_conformance.adoc editorial consistency --- extensions/pubsub/standard/sections/clause_2_conformance.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/extensions/pubsub/standard/sections/clause_2_conformance.adoc b/extensions/pubsub/standard/sections/clause_2_conformance.adoc index d2445e4d9..691ff1131 100644 --- a/extensions/pubsub/standard/sections/clause_2_conformance.adoc +++ b/extensions/pubsub/standard/sections/clause_2_conformance.adoc @@ -4,7 +4,7 @@ This Standard defines Publish-Subscribe patterns specific to event driven data w Requirements for two standardization target types are considered: * API integration -* PubSub channels, and +* Pub/Sub channels, and * Message payload Conformance with this Standard shall be checked using all the relevant tests specified in Annex A (normative) of this document. The framework, concepts, and methodology for testing, and the criteria to be achieved to claim conformance are specified in the OGC Compliance Testing Policies and Procedures and the OGC Compliance Testing web site. From 9f1e2509f1ca1c7f1aa7aa954fa4d63f6b4bb77c Mon Sep 17 00:00:00 2001 From: Chris Little Date: Thu, 11 Jan 2024 21:18:21 +0000 Subject: [PATCH 39/41] Update clause_3_references.adoc remove boiler plate text --- extensions/pubsub/standard/sections/clause_3_references.adoc | 5 ----- 1 file changed, 5 deletions(-) diff --git a/extensions/pubsub/standard/sections/clause_3_references.adoc b/extensions/pubsub/standard/sections/clause_3_references.adoc index 871f47aa4..19c7a5c05 100644 --- a/extensions/pubsub/standard/sections/clause_3_references.adoc +++ b/extensions/pubsub/standard/sections/clause_3_references.adoc @@ -3,11 +3,6 @@ The following normative documents contain provisions that, through reference in this text, constitute provisions of this document. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. For undated references, the latest edition of the normative document referred to applies. -[NOTE] -==== -Insert References here. If there are no references, leave this section empty. - -References are to follow the Springer LNCS style, with the exception that optional information may be appended to references: DOIs are added after the date and web resource references may include an access date at the end of the reference in parentheses. See examples from Springer and OGC below. ==== * [[[AMQP10,AMQP v1.0]]], _Advanced Message Queueing Protocol (AMQP) v1.0)_ https://www.oasis-open.org/standard/amqp From 176482f8797bb7fcdc67f5ca7e5e6a5c874ddba7 Mon Sep 17 00:00:00 2001 From: Chris Little Date: Thu, 11 Jan 2024 21:25:30 +0000 Subject: [PATCH 40/41] Update clause_7_pubsub.adoc editorial consistency and typos --- .../pubsub/standard/sections/clause_7_pubsub.adoc | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/extensions/pubsub/standard/sections/clause_7_pubsub.adoc b/extensions/pubsub/standard/sections/clause_7_pubsub.adoc index 125cb2b3e..beb8a0edc 100644 --- a/extensions/pubsub/standard/sections/clause_7_pubsub.adoc +++ b/extensions/pubsub/standard/sections/clause_7_pubsub.adoc @@ -5,27 +5,27 @@ include::../requirements/requirements_class_pubsub.adoc[] -Event-driven workflows provide publish-subscribe based capabilities as part of information systems and architectures. The publish-subscribe model also provides efficiencies in providing data "as it happens", thereby preventing potential clients from continuous polling to check on the availability of new data/resources. +Event-driven workflows provide Publish-Subscribe based capabilities as part of information systems and architectures. The Publish-Subscribe model also provides efficiencies in providing data "as it happens", thereby preventing potential clients from continuous polling to check on the availability of new data or resources. -The Open Geospatial Consortium (OGC) has conducted significant work on event-based models and architectures. The publish-subscribe model results in less network traffic and more timely responses to manage event-based models such as urgent, temporally unpredictable data (examples include, but are not limited to: traffic conditions, weather or hazard warnings, and real-time sensor data). +The Open Geospatial Consortium (OGC) has conducted significant work on event-based models and architectures. The Publish-Subscribe model results in less network traffic and more timely responses to manage event-based models such as urgent, temporally unpredictable data (examples include, but are not limited to: traffic conditions, weather or hazard warnings, and real-time sensor data). -Building on the OGC Publish-Subscribe Interface Standard https://docs.ogc.org/is/13-131r1/13-131r1.html[OGC 13-131r1], as well as the recommendations put forward in the OGC Pub/Sub White Paper [OGC 20-046] produced as part of OGC Testbed 12, as well as the Discussion paper for Publish-Subscribe workflow in OGC APIs [OGC 23-013], the EDR - Part 2: Publish-Subscribe Standard discusses approaches for integrating publish-subscribe architecture into the OGC API suite of Standards. +Building on the OGC Publish-Subscribe Interface Standard https://docs.ogc.org/is/13-131r1/13-131r1.html[OGC 13-131r1], as well as the recommendations put forward in the OGC Pub/Sub White Paper [OGC 20-046] produced as part of OGC Testbed 12, as well as the Discussion paper for Publish-Subscribe workflow in OGC APIs [OGC 23-013], the EDR - Part 2: Publish-Subscribe Standard discusses approaches for integrating Publish-Subscribe architecture into the OGC API suite of Standards. 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 afchitecture 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 endpoint hierarchy, 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/filtering). +* 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. ==== Message payloads -For smaller payload workflow, implementations of OGC API Standards can additionally provide a channel for notification metadata in order to receive a smaller message payload, which a user can process to determine whether to further interact with the reference data granule or resource. +For smaller payload workflow, implementations of OGC API Standards can additionally provide a channel for notification metadata in order to receive a smaller message payload, which a user can process to determine whether to further interact with the referenced data granule or resource. include::../recommendations/pubsub/REC_message-payloads.adoc[] From c7fbd9ea13d11b0659695974daa82718ada41734 Mon Sep 17 00:00:00 2001 From: Chris Little Date: Thu, 11 Jan 2024 21:26:59 +0000 Subject: [PATCH 41/41] Update clause_9_pubsub-message-payload.adoc --- .../standard/sections/clause_9_pubsub-message-payload.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/extensions/pubsub/standard/sections/clause_9_pubsub-message-payload.adoc b/extensions/pubsub/standard/sections/clause_9_pubsub-message-payload.adoc index 6e32275b2..c2776cc93 100644 --- a/extensions/pubsub/standard/sections/clause_9_pubsub-message-payload.adoc +++ b/extensions/pubsub/standard/sections/clause_9_pubsub-message-payload.adoc @@ -7,7 +7,7 @@ include::../requirements/requirements_class_pubsub_message_payload.adoc[] A key component of Pub/Sub workflows is the message payload. Once a client subscribes to one or more channels from a given Pub/Sub server, notifications messages are sent using a given -representation or encoding. Notification messages can be put forth using any encoding that is deemed +representation or encoding. Notification messages can be issued using any encoding that is deemed suitable by a given publisher. While the Publish-Subscribe (Pub/Sub) Requirements Class recommends a machine-readable message payload,