SP edits for pub: API - Part 2

ogcscotts · ogcscotts · commit 7b2f00ed8b57 · 2025-06-04T09:24:36.000-06:00
diff --git a/api/part2/openapi/examples/controlstreams/controlstream-ptz-create.json b/api/part2/openapi/examples/controlstreams/controlstream-ptz-create.json
@@ -12,7 +12,7 @@
           "type": "Quantity",
           "definition": "http://sensorml.com/ont/swe/property/PanAngle",
           "label": "Pan Angle",
-          "description": "Rotation of the camera around its vertical axis (i.e. causing the image to translate along its horizontal axis)",
+          "description": "Rotation of the camera around its vertical axis (i.e., causing the image to translate along its horizontal axis)",
           "uom": {
             "code": "deg"
           }
@@ -22,7 +22,7 @@
           "type": "Quantity",
           "definition": "http://sensorml.com/ont/swe/property/PanAngle",
           "label": "Pan Angle",
-          "description": "Rotation of the camera around its horizontal axis (i.e. causing the image to translate along its vertical axis)",
+          "description": "Rotation of the camera around its horizontal axis (i.e., causing the image to translate along its vertical axis)",
           "uom": {
             "code": "deg"
           }
diff --git a/api/part2/openapi/examples/schemas/commandSchema-ptz-json.json b/api/part2/openapi/examples/schemas/commandSchema-ptz-json.json
@@ -8,7 +8,7 @@
         "type": "Quantity",
         "definition": "http://sensorml.com/ont/swe/property/PanAngle",
         "label": "Pan Angle",
-        "description": "Rotation of the camera around its vertical axis (i.e. causing the image to translate along its horizontal axis)",
+        "description": "Rotation of the camera around its vertical axis (i.e., causing the image to translate along its horizontal axis)",
         "uom": {
           "code": "deg"
         }
@@ -18,7 +18,7 @@
         "type": "Quantity",
         "definition": "http://sensorml.com/ont/swe/property/PanAngle",
         "label": "Pan Angle",
-        "description": "Rotation of the camera around its horizontal axis (i.e. causing the image to translate along its vertical axis)",
+        "description": "Rotation of the camera around its horizontal axis (i.e., causing the image to translate along its vertical axis)",
         "uom": {
           "code": "deg"
         }
diff --git a/api/part2/openapi/examples/schemas/commandSchema-ptz-jsonschema-byref.json b/api/part2/openapi/examples/schemas/commandSchema-ptz-jsonschema-byref.json
@@ -10,14 +10,14 @@
             "pan": {
               "type": "number",
               "title": "Pan Angle",
-              "description": "Rotation of the camera around its vertical axis (i.e. causing the image to translate along its horizontal axis)",
+              "description": "Rotation of the camera around its vertical axis (i.e., causing the image to translate along its horizontal axis)",
               "@swe.definition": "http://sensorml.com/ont/swe/property/PanAngle",
               "@swe.uomCode": "deg"
             },
             "tilt": {
               "type": "number",
               "title": "Tilt Angle",
-              "description": "Rotation of the camera around its horizontal axis (i.e. causing the image to translate along its vertical axis)",
+              "description": "Rotation of the camera around its horizontal axis (i.e., causing the image to translate along its vertical axis)",
               "@swe.definition": "http://sensorml.com/ont/swe/property/TiltAngle",
               "@swe.uomCode": "Cel"
             },
diff --git a/api/part2/openapi/examples/schemas/commandSchema-ptz-swecsv.json b/api/part2/openapi/examples/schemas/commandSchema-ptz-swecsv.json
@@ -18,7 +18,7 @@
         "type": "Quantity",
         "definition": "http://sensorml.com/ont/swe/property/PanAngle",
         "label": "Pan Angle",
-        "description": "Rotation of the camera around its vertical axis (i.e. causing the image to translate along its horizontal axis)",
+        "description": "Rotation of the camera around its vertical axis (i.e., causing the image to translate along its horizontal axis)",
         "uom": {
           "code": "deg"
         }
@@ -28,7 +28,7 @@
         "type": "Quantity",
         "definition": "http://sensorml.com/ont/swe/property/TiltAngle",
         "label": "Pan Angle",
-        "description": "Rotation of the camera around its horizontal axis (i.e. causing the image to translate along its vertical axis)",
+        "description": "Rotation of the camera around its horizontal axis (i.e., causing the image to translate along its vertical axis)",
         "uom": {
           "code": "deg"
         }
diff --git a/api/part2/openapi/examples/schemas/commandSchema-ptz-swejson.json b/api/part2/openapi/examples/schemas/commandSchema-ptz-swejson.json
@@ -18,7 +18,7 @@
         "type": "Quantity",
         "definition": "http://sensorml.com/ont/swe/property/PanAngle",
         "label": "Pan Angle",
-        "description": "Rotation of the camera around its vertical axis (i.e. causing the image to translate along its horizontal axis)",
+        "description": "Rotation of the camera around its vertical axis (i.e., causing the image to translate along its horizontal axis)",
         "uom": {
           "code": "deg"
         }
@@ -28,7 +28,7 @@
         "type": "Quantity",
         "definition": "http://sensorml.com/ont/swe/property/PanAngle",
         "label": "Tilt Angle",
-        "description": "Rotation of the camera around its horizontal axis (i.e. causing the image to translate along its vertical axis)",
+        "description": "Rotation of the camera around its horizontal axis (i.e., causing the image to translate along its vertical axis)",
         "uom": {
           "code": "deg"
         }
diff --git a/api/part2/openapi/paths/controlStreamSchemas.yaml b/api/part2/openapi/paths/controlStreamSchemas.yaml
@@ -29,7 +29,7 @@ put:
   summary: Update the command schema
   description: |-
     After a control stream has been created and commands have been issued through it, the server may
-    reject certain updates to the schema (e.g. adding or removing parameters, changing UoM, etc.).
+    reject certain updates to the schema (e.g., adding or removing parameters, changing UoM, etc.).
     In this case, the `409` response code is used.
   tags:
     - Control Streams
diff --git a/api/part2/openapi/paths/dataStreamSchemas.yaml b/api/part2/openapi/paths/dataStreamSchemas.yaml
@@ -29,7 +29,7 @@ put:
   summary: Update the observation schema
   description: |-
     After a datastream has been created and observations have been associated to it, the server may
-    reject certain updates to the schema (e.g. adding or removing result fields, changing UoM, etc.).
+    reject certain updates to the schema (e.g., adding or removing result fields, changing UoM, etc.).
     In this case, the `409` response code is used.
   tags:
     - Data Streams
diff --git a/api/part2/openapi/schemas/json/commandStatusCode.json b/api/part2/openapi/schemas/json/commandStatusCode.json
@@ -8,7 +8,7 @@
     { "const": "SCHEDULED", "description": "The command was validated and effectively scheduled by the receiving system. When this status code is used, the scheduled execution time must be provided using the `executionTime` property. Note that systems are not required to notify the planned execution time before execution." },
     { "const": "UPDATED", "description": "An update to the command was received and accepted. This code must be used if the system supports task updates. See the `ACCEPTED` status code for other details." },
     { "const": "CANCELED", "description": "The command was canceled by an authorized user. This code must be used if the system supports user driven task cancellations. The `REJECTED` and `FAILED` status codes are used instead if the command was canceled by the receiving system. This is a final state. No further status updates will be sent." },
-    { "const": "EXECUTING", "description": "The command is currently being executed by the receiving system. The status message can provide more information about the current progress using the `percentCompletion` and `message` properties. A system can send several status updates with this code but different time stamps to report progress incrementally (e.g. for multi-stage executions). In particular, the progress percentage and the end of the (estimated) execution time period can be refined at each update." },
+    { "const": "EXECUTING", "description": "The command is currently being executed by the receiving system. The status message can provide more information about the current progress using the `percentCompletion` and `message` properties. A system can send several status updates with this code but different time stamps to report progress incrementally (e.g., for multi-stage executions). In particular, the progress percentage and the end of the (estimated) execution time period can be refined at each update." },
     { "const": "FAILED", "description": "The command has failed during execution. The `message` property provides the reason for failure. This is a final state. No further status updates will be sent." },
     { "const": "COMPLETED", "description": "The command has completed after a successful execution. The actual execution time must be provided using the `executionTime` property. This is a final state. No further status updates will be sent." }
   ]
diff --git a/api/part2/openapi/schemas/json/observation.json b/api/part2/openapi/schemas/json/observation.json
@@ -39,7 +39,7 @@
       "description": "Result of the observation. Must be valid according to the result schema provided in the datastream metadata."
     },
     "result@link": {
-      "description": "Link to external result data (e.g. large raster dataset served by a tiling service)",
+      "description": "Link to external result data (e.g., large raster dataset served by a tiling service)",
       "$ref": "../common/commonDefs.json#/$defs/Link"
     }
   },
diff --git a/api/part2/standard/23-002r0.adoc b/api/part2/standard/23-002r0.adoc
@@ -2,12 +2,12 @@
 :doctype: standard
 :encoding: utf-8
 :lang: en
-:status: draft
+:status: approved
 :committee: technical
 :external-id: http://www.opengis.net/doc/DIS/ogcapi-connectedsystems-2/1.0
-:docnumber: 23-002r0
-:received-date: yyyy-mm-dd
-:issued-date: yyyy-mm-dd
+:docnumber: 23-002
+:received-date: 2025-03-19
+:issued-date: 2025-06-02
 :published-date: yyyy-mm-dd
 :fullname: Alexandre Robin
 :docsubtype: implementation
diff --git a/api/part2/standard/sections/clause_0_front_material.adoc b/api/part2/standard/sections/clause_0_front_material.adoc
@@ -2,15 +2,15 @@
 
 The OGC API - Connected Systems Standard is part of the suite of OGC API Standards.
 
-To increase the brevity and readability of this Standard, many OGC document titles are shortened and/or abbreviated. Therefore, in the context of this document, the following phrases are defined:
+To increase the brevity and readability of this Standard, many OGC document titles are shortened and/or abbreviated. Therefore, in the context of this document, the following phrases are defined.
 
-- “this Standard” shall be interpreted as equivalent to “OGC API - Connected Systems - Part 2: Dynamic Resources Standard”.
+- “this Standard” shall be interpreted as equivalent to “OGC API - Connected Systems - Part 2: Dynamic Resources Standard.”
 
 - “CS API” or “CS API Standard” shall be interpreted as equivalent to “OGC API - Connected Systems Standard” (including all its parts).
 
-- “OGC API - Features” shall be interpreted as equivalent to “OGC API - Features - Part 1: Core corrigendum”.
+- “OGC API - Features” shall be interpreted as equivalent to “OGC API - Features - Part 1: Core corrigendum.”
 
-- “OGC API - Common” shall be interpreted as equivalent to “OGC API - Common - Part 1: Core”.
+- “OGC API - Common” shall be interpreted as equivalent to “OGC API - Common - Part 1: Core.”
 
 
 [abstract]
diff --git a/api/part2/standard/sections/clause_10_requirements_class_command_feasibility.adoc b/api/part2/standard/sections/clause_10_requirements_class_command_feasibility.adoc
@@ -4,13 +4,13 @@
 === Overview
 include::../requirements/feasibility/requirements_class_feasibility.adoc[]
 
-The execution of certain commands is sometimes impossible due to internal or external constraints (e.g. conflict with other scheduled commands, conflict with another user that has exclusive control on the system, etc.).
+The execution of certain commands is sometimes impossible due to internal or external constraints (e.g., conflict with other scheduled commands, conflict with another user that has exclusive control on the system, etc.).
 
 In order for a client to know if a command/task is feasible without sending the actual command, feasibility channels are supported by the CS API.
 
-In addition to providing a binary (i.e. YES/NO) response to a feasibility request, the CS API also provides a mechanism for returning detailed feasibility analysis information to a client (e.g. provide chances of success, task execution steps, alternatives, etc.).
+In addition to providing a binary (i.e., YES/NO) response to a feasibility request, the CS API also provides a mechanism for returning detailed feasibility analysis information to a client (e.g., provide chances of success, task execution steps, alternatives, etc.).
 
-A feasibility request is initiated by creating a `Command` resource on the feasibility channel. The server can then respond synchronously or asynchronously just like for a regular command channel. The parameters used for the feasibility request are the same as the one for the corresponding commands (i.e. both commands and feasibility share the same parameters schema).
+A feasibility request is initiated by creating a `Command` resource on the feasibility channel. The server can then respond synchronously or asynchronously just like for a regular command channel. The parameters used for the feasibility request are the same as the one for the corresponding commands (i.e., both commands and feasibility share the same parameters schema).
 
 
 
@@ -97,7 +97,7 @@ Below are examples of feasibility results for various use cases:
 In addition to a binary (yes/no) feasibility response, the result of the feasibility analysis may include the earliest time at which the location could be reached, as well as the expected trajectory.
 
 *Example 2: Tasking a satellite to cover an area with visible imagery* +
-The result of the feasibility analysis may include all the attempts needed to have a high enough chance of success to obtain a clear (i.e. cloud free) image of the area. If the area is too large to be covered with a single image, an estimated success rate and completion time could be provided separately for each subdivision of the geographic area.
+The result of the feasibility analysis may include all the attempts needed to have a high enough chance of success to obtain a clear (i.e., cloud free) image of the area. If the area is too large to be covered with a single image, an estimated success rate and completion time could be provided separately for each subdivision of the geographic area.
 ====
 
 The set of result items associated to a given feasibility request is available at a nested endpoint under the corresponding `Feasibility` resource:
diff --git a/api/part2/standard/sections/clause_12_requirements_class_system_history.adoc b/api/part2/standard/sections/clause_12_requirements_class_system_history.adoc
@@ -8,7 +8,7 @@ include::../requirements/systemhistory/requirements_class_system_history.adoc[]
 
 This requirements class specifies how a server can historize `System` feature descriptions and make the different versions available through the API.
 
-The history mechanism allows the server to retain older versions of a system's description, valid at different times. This is useful to capture the exact metadata of the system at a given point in time since it can be needed to properly process older observations (e.g. older calibration tables, etc.).
+The history mechanism allows the server to retain older versions of a system's description, valid at different times. This is useful to capture the exact metadata of the system at a given point in time since it can be needed to properly process older observations (e.g., older calibration tables, etc.).
 
 Typically, a new entry would be added to the system history whenever a description with a newer valid time is created. History entries are also often correlated with system events. A new history entry is typically created when a system event results in important changes to the system's metadata (such as relocation, recalibration, etc. See <<clause-system-events>>).
 
diff --git a/api/part2/standard/sections/clause_15_requirements_class_create_replace_delete.adoc b/api/part2/standard/sections/clause_15_requirements_class_create_replace_delete.adoc
@@ -58,7 +58,7 @@ part:: If the request contains the `cascade` parameter, the server SHALL accept
 
 NOTE: A schema must be provided before observations can be inserted in the datastream. The schema is provided along with the `DataStream` resource itself. Only one schema (for only one format) can be provided by a create operation for a given datastream. However, the server is allowed to automatically convert observations to/from other supported formats, as appropriate. This implies that the server can also automatically generate equivalent schemas for these other formats. Future extensions may define patterns to allow client to define multiple schemas themselves.
 
-NOTE: After a datastream has been created and observations have been associated to it, the server may reject certain updates to the schema (e.g. adding or removing result fields, changing UoM, etc.). Datastream schema evolution will be addressed in more details in a future revision, but the current workaround is to create a new datastream if the schema changes.
+NOTE: After a datastream has been created and observations have been associated to it, the server may reject certain updates to the schema (e.g., adding or removing result fields, changing UoM, etc.). Datastream schema evolution will be addressed in more details in a future revision, but the current workaround is to create a new datastream if the schema changes.
 
 
 
diff --git a/api/part2/standard/sections/clause_16_requirements_class_update.adoc b/api/part2/standard/sections/clause_16_requirements_class_update.adoc
@@ -4,7 +4,7 @@
 === Overview
 include::../requirements/crud/update/requirements_class_update.adoc[]
 
-The "Update" requirements class specifies how instances of the resource types defined in this Standard are updated (i.e. patched) via a CS API endpoint.
+The "Update" requirements class specifies how instances of the resource types defined in this Standard are updated (i.e., patched) via a CS API endpoint.
 
 All resources are updated using the UPDATE (HTTP PATCH) operation, as defined by the {ogcapi-features-4} Standard.
 
diff --git a/api/part2/standard/sections/clause_1_scope.adoc b/api/part2/standard/sections/clause_1_scope.adoc
@@ -2,9 +2,9 @@
 
 This Standard defines extensions to {ogcapi-features} for exposing metadata and dynamic data regarding all kinds of observing systems and associated resources. It provides an actionable implementation of concepts defined in the <<SOSA-SSN,Semantic Sensor Network Ontology (SSN)>> and also complies with {ogcapi-common}.
 
-More specifically, Part 2 of the API, specified in this document, implements the SSN concepts allowing exchange of dynamic (possibly real-time) data flowing to and from various types of connected systems (e.g. sensors, actuators, platforms). Several encoding formats are defined in this Standard, including JSON, CSV and binary formats based on the OGC - SWE Common Standard. Additional encodings can be added by extensions.
+More specifically, Part 2 of the API, specified in this document, implements the SSN concepts allowing exchange of dynamic (possibly real-time) data flowing to and from various types of connected systems (e.g., sensors, actuators, platforms). Several encoding formats are defined in this Standard, including JSON, CSV and binary formats based on the OGC - SWE Common Standard. Additional encodings can be added by extensions.
 
-The following types of resources are defined by Part 2 of the API:
+The following types of resources are defined by Part 2 of the API.
 
   - *DataStream* resources represent data feeds coming out of `Systems` and are containers for `Observations`. They are used for receiving and ingesting real-time `Observations` as well as accessing historical `Observations`. A `DataStream` is a particular case of `sosa:ObservationCollection` where all `Observations` are coming from the same sensor.
 
diff --git a/api/part2/standard/sections/clause_20_requirements_class_json_encoding.adoc b/api/part2/standard/sections/clause_20_requirements_class_json_encoding.adoc
@@ -305,7 +305,7 @@ part:: If a `CommandResult` resource includes inline data, the content of the `d
 
 part:: For regular commands, the schema is provided by the the `resultSchema` property of the schema resource.
 
-part:: For feasibility requests (i.e. commands received on a feasibility channel), the schema is provided by the the `feasibilityResultSchema` property of the schema resource.
+part:: For feasibility requests (i.e., commands received on a feasibility channel), the schema is provided by the the `feasibilityResultSchema` property of the schema resource.
 
 part:: See {json-commandschema-schema-json}.
 ====
diff --git a/api/part2/standard/sections/clause_23_requirements_class_swecommon_binary_encoding.adoc b/api/part2/standard/sections/clause_23_requirements_class_swecommon_binary_encoding.adoc
@@ -12,8 +12,8 @@ This requirements class defines binary encodings of `Observation` and `Command`
 
 The main objective of this encoding is better data size efficiency than text or JSON, thus allowing for:
 
-- Transfer of observations and commands over very low power / low bandwidth network links (e.g. LoRa,  etc.)
-- Transfer high bandwidth data sets such as raster data (e.g. video, LiDAR, etc.)
+- Transfer of observations and commands over very low power / low bandwidth network links (e.g., LoRa,  etc.); and
+- Transfer high bandwidth data sets such as raster data (e.g., video, LiDAR, etc.).
 
 For even better efficiency, this encoding can be combined with a transport protocol such as <<clause-protocol-mqtt,MQTT>>.
 
diff --git a/api/part2/standard/sections/clause_2_conformance.adoc b/api/part2/standard/sections/clause_2_conformance.adoc
diff --git a/api/part2/standard/sections/clause_3_references.adoc b/api/part2/standard/sections/clause_3_references.adoc
diff --git a/api/part2/standard/sections/clause_6_overview.adoc b/api/part2/standard/sections/clause_6_overview.adoc
diff --git a/api/part2/standard/sections/clause_7a_requirements_class_dynamic_feature_properties.adoc b/api/part2/standard/sections/clause_7a_requirements_class_dynamic_feature_properties.adoc
diff --git a/api/part2/standard/sections/clause_8_requirements_class_datastreams.adoc b/api/part2/standard/sections/clause_8_requirements_class_datastreams.adoc
diff --git a/api/part2/standard/sections/clause_9_requirements_class_controlstreams.adoc b/api/part2/standard/sections/clause_9_requirements_class_controlstreams.adoc

Original file line number	Diff line number	Diff line change
`@@ -8,7 +8,7 @@`
`8`	`8`	{ "const": "SCHEDULED", "description": "The command was validated and effectively scheduled by the receiving system. When this status code is used, the scheduled execution time must be provided using the `executionTime` property. Note that systems are not required to notify the planned execution time before execution." },
`9`	`9`	{ "const": "UPDATED", "description": "An update to the command was received and accepted. This code must be used if the system supports task updates. See the `ACCEPTED` status code for other details." },
`10`	`10`	{ "const": "CANCELED", "description": "The command was canceled by an authorized user. This code must be used if the system supports user driven task cancellations. The `REJECTED` and `FAILED` status codes are used instead if the command was canceled by the receiving system. This is a final state. No further status updates will be sent." },
`11`		- { "const": "EXECUTING", "description": "The command is currently being executed by the receiving system. The status message can provide more information about the current progress using the `percentCompletion` and `message` properties. A system can send several status updates with this code but different time stamps to report progress incrementally (e.g. for multi-stage executions). In particular, the progress percentage and the end of the (estimated) execution time period can be refined at each update." },
	`11`	+ { "const": "EXECUTING", "description": "The command is currently being executed by the receiving system. The status message can provide more information about the current progress using the `percentCompletion` and `message` properties. A system can send several status updates with this code but different time stamps to report progress incrementally (e.g., for multi-stage executions). In particular, the progress percentage and the end of the (estimated) execution time period can be refined at each update." },
`12`	`12`	{ "const": "FAILED", "description": "The command has failed during execution. The `message` property provides the reason for failure. This is a final state. No further status updates will be sent." },
`13`	`13`	{ "const": "COMPLETED", "description": "The command has completed after a successful execution. The actual execution time must be provided using the `executionTime` property. This is a final state. No further status updates will be sent." }
`14`	`14`	`]`
Original file line number	Diff line number	Diff line change
`@@ -39,7 +39,7 @@`
`39`	`39`	`"description": "Result of the observation. Must be valid according to the result schema provided in the datastream metadata."`
`40`	`40`	`},`
`41`	`41`	`"result@link": {`
`42`		`- "description": "Link to external result data (e.g. large raster dataset served by a tiling service)",`
	`42`	`+ "description": "Link to external result data (e.g., large raster dataset served by a tiling service)",`
`43`	`43`	`"$ref": "../common/commonDefs.json#/$defs/Link"`
`44`	`44`	`}`
`45`	`45`	`},`