Merge branch 'master' into feature/cleanup-inconsistency

core/openapi/ogcapi-features-1.yaml

@@ -49,7 +49,7 @@ components:
         For WGS 84 longitude/latitude the values are in most cases the sequence of
         minimum longitude, minimum latitude, maximum longitude and maximum latitude.
         However, in cases where the box spans the antimeridian the first value
-        (west-most box edge) is larger than the third value (east-most box edge).
+        (west-most box edge) is larger than the third or fourth value (east-most box edge).
 
         If the vertical axis is included, the third and the sixth number are
         the bottom and the top of the 3-dimensional bounding box.
@@ -122,7 +122,7 @@ components:
         type: integer
         minimum: 1
         maximum: 10000
-        default: 10
+        default: 100
       style: form
       explode: false
   schemas:
@@ -244,7 +244,7 @@ components:
                   For WGS 84 longitude/latitude the values are in most cases the sequence of
                   minimum longitude, minimum latitude, maximum longitude and maximum latitude.
                   However, in cases where the box spans the antimeridian the first value
-                  (west-most box edge) is larger than the third value (east-most box edge).
+                  (west-most box edge) is larger than the third or fourth value (east-most box edge).
 
                   If the vertical axis is included, the third and the sixth number are
                   the bottom and the top of the 3-dimensional bounding box.
@@ -634,7 +634,7 @@ components:
         This information includes:
 
         * A local identifier for the collection that is unique for the dataset;
-        * A list of coordinate reference systems (CRS) in which geometries may be returned by the server. The first CRS is the default coordinate reference system (the default is always WGS 84 with axis order longitude/latitude);
+        * An optional list of coordinate reference systems (CRS) in which geometries may be returned by the server. The default value is a list with the default CRS (WGS 84 with axis order longitude/latitude).
         * An optional title and description for the collection;
         * An optional extent that can be used to provide an indication of the spatial and temporal extent of the collection - typically derived from the data;
         * An optional indicator about the type of the items in the collection (the default value, if the indicator is not provided, is 'feature').
@@ -706,7 +706,7 @@ components:
         includes:
 
         * A local identifier for the collection that is unique for the dataset;
-        * A list of coordinate reference systems (CRS) in which geometries may be returned by the server. The first CRS is the default coordinate reference system (the default is always WGS 84 with axis order longitude/latitude);
+        * An optional list of coordinate reference systems (CRS) in which geometries may be returned by the server. The default value is a list with the default CRS (WGS 84 with axis order longitude/latitude).
         * An optional title and description for the collection;
         * An optional extent that can be used to provide an indication of the spatial and temporal extent of the collection - typically derived from the data;
         * An optional indicator about the type of the items in the collection (the default value, if the indicator is not provided, is 'feature').

core/openapi/parameters/bbox.yaml

@@ -26,7 +26,7 @@ description: |-
   For WGS 84 longitude/latitude the values are in most cases the sequence of
   minimum longitude, minimum latitude, maximum longitude and maximum latitude.
   However, in cases where the box spans the antimeridian the first value
-  (west-most box edge) is larger than the third value (east-most box edge).
+  (west-most box edge) is larger than the third or fourth value (east-most box edge).
 
   If the vertical axis is included, the third and the sixth number are the
   bottom and the top of the 3-dimensional bounding box.

core/openapi/parameters/limit.yaml

@@ -6,12 +6,14 @@ description: |-
   Only items are counted that are on the first level of the collection in the response document.
   Nested objects contained within the explicitly requested items shall not be counted.
 
-  Minimum = 1. Maximum = 10000. Default = 10.
+  Minimum = 1. Maximum = 10000. Default = 100.
+
+  Note that the values for minimum, maximum and default are examples and can be changed.
 required: false
 schema:
   type: integer
   minimum: 1
   maximum: 10000
-  default: 10
+  default: 100
 style: form
 explode: false

core/openapi/schemas/extent.yaml

@@ -51,7 +51,7 @@ properties:
             For WGS 84 longitude/latitude the values are in most cases the sequence of
             minimum longitude, minimum latitude, maximum longitude and maximum latitude.
             However, in cases where the box spans the antimeridian the first value
-            (west-most box edge) is larger than the third value (east-most box edge).
+            (west-most box edge) is larger than the third or fourth value (east-most box edge).
 
             If the vertical axis is included, the third and the sixth number are
             the bottom and the top of the 3-dimensional bounding box.

core/standard/abstract_tests/core/ATS_fc-bbox-definition.adoc

@@ -2,7 +2,7 @@
 [width="90%",cols="2,6a"]
 |===
 ^|*Abstract Test {counter:ats-id}* |*/conf/core/fc-bbox-definition*
-^|Test Purpose |Validate that the bounding box query parameters are constructed correctly.
+^|Test Purpose |Validate that the bounding box query parameters are defined correctly.
 ^|Requirement |<<req_core_fc-bbox-definition,/req/core/fc-bbox-definition>>
 ^|Test Method |Verify that the `bbox` query parameter complies with the following definition (using an OpenAPI Specification 3.0 fragment):
 
@@ -23,21 +23,4 @@ schema:
 style: form
 explode: false
 ----
-
-Use a bounding box with four numbers in all requests, if the collection has spatial geometries in 2D:
-
-* Lower left corner, WGS 84 longitude
-* Lower left corner, WGS 84 latitude
-* Upper right corner, WGS 84 longitude
-* Upper right corner, WGS 84 latitude
-
-Use a bounding box with six numbers in all requests, if the collection has spatial geometries in 3D:
-
-* Lower left corner, WGS 84 longitude
-* Lower left corner, WGS 84 latitude
-* Minimum value, WGS 84 ellipsoidal height
-* Upper right corner, WGS 84 longitude
-* Upper right corner, WGS 84 latitude
-* Maximum value, WGS 84 ellipsoidal height
-
 |===

core/standard/abstract_tests/core/ATS_fc-bbox-response.adoc

@@ -2,9 +2,29 @@
 [width="90%",cols="2,6a"]
 |===
 ^|*Abstract Test {counter:ats-id}* |*/conf/core/fc-bbox-response*
-^|Test Purpose |Validate that the bounding box query parameters are processed correctly.
-^|Requirement |<<req_core_fc-bbox-response,/req/core/fc-bbox-response>>
-^|Test Method |. Verify that only features that have a spatial geometry that intersects the bounding box are returned as part of the result set.
-. Verify that the `bbox` parameter matched all features in the collection that were not associated with a spatial geometry (this is only applicable for datasets that include features without a spatial geometry).
-. Verify that the coordinate reference system of the geometries is WGS 84 longitude/latitude ("http://www.opengis.net/def/crs/OGC/1.3/CRS84" or "http://www.opengis.net/def/crs/OGC/0/CRS84h") since no parameter `bbox-crs` was specified in the request.
+^|Test Purpose |Validate that the bounding box query parameters are evaluated correctly.
+^|Requirement |<<req_core_fc-bbox-definition,/req/core/fc-bbox-definition>>, <<req_core_fc-bbox-response,/req/core/fc-bbox-response>>
+^|Test Method |Request Features with the `bbox` parameter and without a `bbox-crs` parameter.
+
+Use a bounding box with four numbers in all requests, if the collection has spatial geometries in 2D:
+
+* Lower left corner, WGS 84 longitude
+* Lower left corner, WGS 84 latitude
+* Upper right corner, WGS 84 longitude
+* Upper right corner, WGS 84 latitude
+
+Use a bounding box with six numbers in all requests, if the collection has spatial geometries in 3D:
+
+* Lower left corner, WGS 84 longitude
+* Lower left corner, WGS 84 latitude
+* Minimum value, WGS 84 ellipsoidal height
+* Upper right corner, WGS 84 longitude
+* Upper right corner, WGS 84 latitude
+* Maximum value, WGS 84 ellipsoidal height
+
+Verify that
+
+. only features that have a spatial geometry that intersects the bounding box are returned as part of the result set;
+. the `bbox` parameter matched all features in the collection that were not associated with a spatial geometry (this is only applicable for datasets that include features without a spatial geometry);
+. the coordinate reference system of the geometries is WGS 84 longitude/latitude ("http://www.opengis.net/def/crs/OGC/1.3/CRS84" or "http://www.opengis.net/def/crs/OGC/0/CRS84h") since no parameter `bbox-crs` was specified in the request.
 |===

core/standard/abstract_tests/core/ATS_fc-limit-definition.adoc

@@ -2,7 +2,7 @@
 [width="90%",cols="2,6a"]
 |===
 ^|*Abstract Test {counter:ats-id}* |*/conf/core/fc-limit-definition*
-^|Test Purpose |Validate that the bounding box query parameters are constructed correctly.
+^|Test Purpose |Validate that the limit query parameters are defined correctly.
 ^|Requirement |<<req_core_fc-limit-definition,/req/core/fc-limit-definition>>
 ^|Test Method |Verify that the `limit` query parameter complies with the following definition (using an OpenAPI Specification 3.0 fragment):
 

core/standard/abstract_tests/core/ATS_fc-limit-response.adoc

@@ -2,9 +2,10 @@
 [width="90%",cols="2,6a"]
 |===
 ^|*Abstract Test {counter:ats-id}* |*/conf/core/fc-limit-response* 
-^|Test Purpose |Validate that the limit query parameters are processed correctly.
+^|Test Purpose |Validate that the limit query parameters are evaluated correctly.
 ^|Requirement |<<req_core_fc-limit-response,/req/core/fc-limit-response>>
-^|Test Method |. Count the Features which are on the first level of the collection. Any nested objects contained within the explicitly requested items  are not be counted.
+^|Test Method |. Request Features with the `limit` parameter.
+. Count the Features which are on the first level of the collection. Any nested objects contained within the explicitly requested items are not counted.
 . Verify that this count is not greater than the value specified by the `limit` parameter. 
 . If the API definition specifies a maximum value for `limit` parameter, verify that the count does not exceed this maximum value.
 . If the API definition specifies a maximum value for `limit` parameter, submit another request with a `limit` value that is greater than the maximum and verify that the response is not an error and that the count does not exceed this maximum value.

core/standard/abstract_tests/core/ATS_fc-time-definition.adoc

@@ -2,7 +2,7 @@
 [width="90%",cols="2,6a"]
 |===
 ^|*Abstract Test {counter:ats-id}* |*/conf/core/fc-time-definition*
-^|Test Purpose |Validate that the datetime query parameters are constructed correctly.
+^|Test Purpose |Validate that the datetime query parameters are defined correctly.
 ^|Requirement |<<req_core_fc-time-definition,/req/core/fc-time-definition>>
 ^|Test Method |Verify that the `datetime` query parameter complies with the following definition (using an OpenAPI Specification 3.0 fragment):
 

core/standard/abstract_tests/core/ATS_fc-time-response.adoc

@@ -2,9 +2,10 @@
 [width="90%",cols="2,6a"]
 |===
 ^|*Abstract Test {counter:ats-id}* |*/conf/core/fc-time-response*
-^|Test Purpose |Validate that the datetime query parameters are processed correctly.
-^|Requirement |<<req_core_fc-time-response,/req/core/fc-time-response>>
-^|Test Method |. Verify that only features that have a temporal geometry that intersects the temporal information in the `datetime` parameter were included in the result set
-. Verify that all features in the collection that are not associated with a temporal geometry are included in the result set
-. Validate that the dateime parameter complies with the syntax described in <<req_core_fc-time-response,/req/core/fc-time-response>>.
+^|Test Purpose |Validate that the datetime query parameters are evaluated correctly.
+^|Requirement |<<req_core_fc-time-definition,/req/core/fc-time-definition>>, <<req_core_fc-time-response,/req/core/fc-time-response>>
+^|Test Method |Send requests with all variations described in <<req_core_fc-time-response,/req/core/fc-time-response>>: a date-time value, a bounded interval, a half-bounded interval at the start and a half-bounded interval at the end. Use both double-dot and the empty string for the half-bounded values.
+
+. Verify that only features that have a temporal geometry that intersects the temporal information in the `datetime` parameter were included in the result set.
+. Verify that all features in the collection that are not associated with a temporal geometry are included in the result set.
 |===

core/standard/clause_11_security_considerations.adoc

@@ -20,7 +20,7 @@ API designers should focus primarily on the Architectural view. However, there a
 
 * Web Problems.
 
-Many of the vulnerabilities described in the CWE are introduced through the HTTP protocol. API designers and developers should be familiar with how the HTTP 1.1 addresses these vulnerabilities. This information can be found in the "Security Considerations" sections of the <<rfc723x,IETF RFCs 7230 to 7235>>.
+Many of the vulnerabilities described in the CWE are introduced through the HTTP protocol. API designers and developers should be familiar with how the HTTP 1.1 addresses these vulnerabilities. This information can be found in the "Security Considerations" sections of <<rfc9110,IETF RFC 9110>> and <<rfc9112,IETF RFC 9112>>.
 
 The following sections describe some of the most serious vulnerabilities which can be mitigated by the API designer and developer. These are high-level generalizations of the more detailed vulnerabilities described in the CWE.
 

core/standard/clause_3_references.adoc

@@ -7,10 +7,12 @@ The following normative documents contain provisions that, through reference in
 
 * [[rfc3339]] Internet Engineering Task Force (IETF). RFC 3339: **Date and Time on the Internet: Timestamps** [online]. Edited by G. Klyne, C. Newman. 2002 [viewed 2020-03-16]. Available at https://www.rfc-editor.org/rfc/rfc3339.html
 
-* [[rfc723x]] Internet Engineering Task Force (IETF). RFC 7230 to RFC 7235: **HTTP/1.1** [online]. Edited by R. Fielding, J. Reschke, Y. Lafon, M. Nottingham. 2014 [viewed 2020-04-28]. Available at https://www.rfc-editor.org/rfc/rfc7230.html, https://www.rfc-editor.org/rfc/rfc7231.html, https://www.rfc-editor.org/rfc/rfc7232.html, https://www.rfc-editor.org/rfc/rfc7233.html, https://www.rfc-editor.org/rfc/rfc7234.html, and https://www.rfc-editor.org/rfc/rfc7235.html
-
 * [[rfc8288]] Internet Engineering Task Force (IETF). RFC 8288: **Web Linking** [online]. Edited by M. Nottingham. 2017 [viewed 2020-03-16]. Available at https://www.rfc-editor.org/rfc/rfc8288.html
 
+* [[rfc9110]] Internet Engineering Task Force (IETF). RFC 9110: **HTTP Semantics** [online]. Edited by R. Fielding, J. Reschke, Y. Lafon, M. Nottingham. 2022 [viewed 2023-04-10]. Available at https://www.rfc-editor.org/rfc/rfc9110.html
+
+* [[rfc9112]] Internet Engineering Task Force (IETF). RFC 9112: **HTTP/1.1** [online]. Edited by R. Fielding, J. Reschke, M. Nottingham. 2022 [viewed 2023-04-10]. Available at https://www.rfc-editor.org/rfc/rfc9112.html
+
 * [[GMLSF]] Open Geospatial Consortium (OGC). OGC 10-100r3: **Geography Markup Language (GML) Simple Features Profile** [online]. Edited by L. van den Brink, C. Portele, P. Vretanos. 2012 [viewed 2020-03-16]. Available at http://portal.opengeospatial.org/files/?artifact_id=42729
 
 * [[GeoJSON]] Internet Engineering Task Force (IETF). RFC 7946: **The GeoJSON Format** [online]. Edited by H. Butler, M. Daly, A. Doyle, S. Gillies, S. Hagen, T. Schaub. 2016 [viewed 2020-03-16]. Available at https://www.rfc-editor.org/rfc/rfc7946.html

core/standard/clause_5_conventions.adoc

@@ -48,11 +48,11 @@ Each resource representation includes an array of links. Implementations are fre
 
 === Use of HTTPS
 
-For simplicity, this document in general only refers to the HTTP protocol. This is not meant to exclude the use of HTTPS and simply is a shorthand notation for "HTTP or HTTPS." In fact, most servers are expected to use <<rfc2818,HTTPS>>, not <<rfc723x,HTTP>>.
+For simplicity, this document in general only refers to the HTTP protocol. This is not meant to exclude the use of HTTPS and simply is a shorthand notation for "HTTP or HTTPS." In fact, most servers are expected to use <<rfc2818,HTTPS>>, not <<rfc9110,HTTP>>.
 
 === HTTP URIs
 
-This document does not restrict the lexical space of URIs used in the API beyond the requirements of the <<rfc723x,HTTP>> and <<rfc3986,URI Syntax>> IETF RFCs. If URIs include reserved characters that are delimiters in the URI subcomponent, these have to be percent-encoded. See Clause 2 of <<rfc3986,RFC 3986>> for details.
+This document does not restrict the lexical space of URIs used in the API beyond the requirements of the <<rfc9110,HTTP>> and <<rfc3986,URI Syntax>> IETF RFCs. If URIs include reserved characters that are delimiters in the URI subcomponent, these have to be percent-encoded. See Clause 2 of <<rfc3986,RFC 3986>> for details.
 
 === API definition