[API Part2] Added command feasibility req class

api/part2/standard/23-002r0.adoc

@@ -62,17 +62,19 @@ include::sections/clause_8_requirements_class_datastreams.adoc[]
 
 include::sections/clause_9_requirements_class_controlstreams.adoc[]
 
-include::sections/clause_10_requirements_class_system_events.adoc[]
+include::sections/clause_10_requirements_class_command_feasibility.adoc[]
 
-include::sections/clause_11_requirements_class_system_history.adoc[]
+include::sections/clause_11_requirements_class_system_events.adoc[]
 
-// include::sections/clause_12_requirements_class_simple_filtering.adoc[]
+include::sections/clause_12_requirements_class_system_history.adoc[]
 
-include::sections/clause_13_requirements_class_advanced_filtering.adoc[]
+// include::sections/clause_13_requirements_class_simple_filtering.adoc[]
 
-include::sections/clause_14_requirements_class_create_replace_delete.adoc[]
+include::sections/clause_14_requirements_class_advanced_filtering.adoc[]
 
-include::sections/clause_15_requirements_class_update.adoc[]
+include::sections/clause_15_requirements_class_create_replace_delete.adoc[]
+
+include::sections/clause_16_requirements_class_update.adoc[]
 
 
 == Requirements Classes for Encodings

api/part2/standard/sections/clause_10_requirements_class_command_feasibility.adoc

@@ -0,0 +1,10 @@
+[[clause-command-feasibility]]
+== Requirements Class "Command Feasibility"
+
+=== Overview
+
+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 provides a mechanism to include detailed feasibility analysis in the response (e.g. provide chances of success, provide task execution details), as well as suggest alternatives if the command is not feasible or has a low chance of success.
+
+A feasibility channel is a regular command stream that is associated to the corresponding command channel. The parameters on the feasibility channel are exactly the same as the ones on the associated command channel, but the response is different. Instead of 

api/part2/standard/sections/clause_10_requirements_class_system_events.adoc → api/part2/standard/sections/clause_11_requirements_class_system_events.adoc

@@ -21,7 +21,7 @@ Below is the contextual class diagram of the `SystemEvent` resource:
 
 [#system-event-class,reftext='{figure-caption} {counter:figure-num}']
 .System Event Diagram
-image::figures/FIG007-systemevent-class.png[api-class-diagram, align="center"]
+image::figures/FIG008-systemevent-class.png[api-class-diagram, align="center"]
 
 ==== Properties
 

api/part2/standard/sections/clause_13_requirements_class_advanced_filtering.adoc → api/part2/standard/sections/clause_14_requirements_class_advanced_filtering.adoc

@@ -21,6 +21,8 @@ All filters defined in this section are implemented using URL query parameters a
 [[clause-observation-query-params]]
 === Observation Query Parameters
 
+The following query parameters are used to filter `Observation` resources at an {obs-resources-endpoint}.
+
 ==== Phenomenon Time Filter
 
 This filter is used to select observations based on their `phenomenonTime` property.
@@ -86,3 +88,12 @@ part:: In addition to the possible parameter values defined in {ogcapi-features-
 [[clause-command-query-params]]
 === Command Query Parameters
 
+The following query parameters are used to filter `Command` resources at an {command-resources-endpoint}.
+
+==== Issue Time Filter
+
+==== Execution Time Filter
+
+==== Sender Filter
+
+==== Status Filter

api/part2/standard/sections/clause_14_requirements_class_create_replace_delete.adoc → api/part2/standard/sections/clause_15_requirements_class_create_replace_delete.adoc

@@ -56,6 +56,10 @@ part:: By default, the server SHALL reject a DELETE request on a `DataStream` re
 part:: If the request contains the `cascade` parameter, the server SHALL accept the DELETE request and delete the `DataStream` resource as well as all its nested `Observation` resources.
 ====
 
+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.
+
 
 
 === Observations

api/part2/standard/sections/clause_7a_requirements_class_dynamic_feature_properties.adoc

@@ -0,0 +1,30 @@
+[[clause-dynamic-feature-props]]
+== Requirements Class "Dynamic Feature Properties"
+
+[cols="1,4",width="90%",options="header"]
+|===
+2+|*Requirements Class*
+2+|http://www.opengis.net/spec/ogcapi-connectedsystems-2/1.0/req/dynamic-props
+|Target type    |Web API
+|Dependency     |http://www.opengis.net/spec/ogcapi-connected-systems-1/1.0/core
+|===
+
+=== Overview
+
+Dynamic feature properties are feature properties whose values change over time.
+
+
+=== Dynamic Tag
+
+This requirements class defines a tag to be used in any JSON representation to identify properties that are dynamic (i.e. time varying).
+
+This is done by adding the `@dynamic` suffix to any JSON member name and setting the value to true.
+
+
+=== Feature Snapshot
+
+This requirements class also defines a behavior of a server when using the existing `datetime` property in a request.
+
+For dynamic features, when the `datetime` query parameter is used to specify a time instant, (and the `snapshot` parameter is set to true?), the server must take a snapshot of the feature properties at the specified time.
+
+This can be used in conjunction with the `temporalProperties` sub resource provided by OGC API - Moving Features.