From af8ffd566f20b57261cef0e157ebba3a9a3d897d Mon Sep 17 00:00:00 2001 From: Clemens Portele Date: Wed, 7 Mar 2018 13:52:32 -0700 Subject: [PATCH] Implement new resource structure * change path structure, resolves #64 * change remaining uses of "collectionId" to "name" --- core/UML/ISO 191xx-1 Edition 1.xmi | 4 +- core/standard/clause_0_front_material.adoc | 3 + core/standard/clause_7_core.adoc | 217 +++++--- .../requirements/requirement_fc-md-op.adoc | 2 +- docs/17-069.html | 487 +++++++++++------- 5 files changed, 455 insertions(+), 258 deletions(-) diff --git a/core/UML/ISO 191xx-1 Edition 1.xmi b/core/UML/ISO 191xx-1 Edition 1.xmi index 86a6aaf5..0705d476 100755 --- a/core/UML/ISO 191xx-1 Edition 1.xmi +++ b/core/UML/ISO 191xx-1 Edition 1.xmi @@ -776,7 +776,7 @@ - + @@ -973,7 +973,7 @@ - + diff --git a/core/standard/clause_0_front_material.adoc b/core/standard/clause_0_front_material.adoc index 4120a7ca..f3338ac1 100644 --- a/core/standard/clause_0_front_material.adoc +++ b/core/standard/clause_0_front_material.adoc @@ -14,8 +14,11 @@ Query operations allow features or values of feature properties to be retrieved This part of this International Standard defines the following resources: +* Landing page [1] * Service definition [1] +* Conformance classes [1] * Feature collections metadata [1] +* Feature collection metadata [0..n] * Feature collection [0..n] * Feature [0..n] diff --git a/core/standard/clause_7_core.adoc b/core/standard/clause_7_core.adoc index 6b35aa57..fcd89c0e 100644 --- a/core/standard/clause_7_core.adoc +++ b/core/standard/clause_7_core.adoc @@ -60,6 +60,8 @@ which describes the capabilities of the server and which can be used by clients to connect to the server or by development tools to support the implementation of servers and clients. +!!! Update diagram and description + [#img_core,reftext='{figure-caption} {counter:figure-num}'] .Resources in the Core requirements class image::figures/PT1_FIG01.png[align="center"] @@ -67,9 +69,70 @@ image::figures/PT1_FIG01.png[align="center"] CAUTION: link:https://github.com/opengeospatial/WFS_FES/issues/30[ISSUE 30] + Allow also features that do not belong to any collection? -=== API definition +=== API landing page + +==== Operation + +[width="90%",cols="2,6a"] +|=== +|*Requirement {counter:req-id}* |/req/core/root-op + + +The server SHALL support the HTTP GET operation at the path `/`. +|=== + +==== Response + +[width="90%",cols="2,6a"] +|=== +|*Requirement {counter:req-id}* |/req/core/root-success + + +A successful execution of the operation SHALL be reported as a response with a +HTTP status code `200`. + +The content of that response SHALL be based upon the OpenAPI 3.0 schema link:https://raw.githubusercontent.com/opengeospatial/WFS_FES/master/core/openapi/schemas/root.yaml[root.yaml] +and include at least links to the following resources: + +* `/api` (relation type 'service') +* `/conformance` (relation type 'conformance') +* `/collections` (relation type 'data') +|=== + +NOTE: TODO + +Check, if we can reuse existing relation types instead of 'conformance' and 'data'? + +.link:https://raw.githubusercontent.com/opengeospatial/WFS_FES/master/core/openapi/schemas/root.yaml[Schema for the landing page] +[source,JSON] +---- +type: object +required: + - links +properties: + links: + type: array + items: + $ref: https://raw.githubusercontent.com/opengeospatial/WFS_FES/master/core/openapi/schemas/link.yaml +---- + +.Landing page response document +================= +[source,JSON] +---- +{ + "links": [ + { "href": "http://data.example.org/", + "rel": "self", "type": "application/json", "title": "this document" }, + { "href": "http://data.example.org/api", + "rel": "service", "type": "application/openapi+json;version=3.0", "title": "the API definition" }, + { "href": "http://data.example.org/conformance", + "rel": "conformance", "type": "application/json", "title": "WFS 3.0 conformance classes implemented by this server" }, + { "href": "http://data.example.org/collections", + "rel": "data", "type": "application/json", "title": "Metadata about the feature collections" } + ] +} +---- +================= -==== General requirements +=== API definition Every WFS is defined by an API definition that describes the capabilities of the server and which can be used by clients to connect to the server or @@ -77,7 +140,7 @@ by development tools to support the implementation of servers and clients. include::requirements/requirement_api-definition.adoc[] -The API definition document is the "landing page" for the API. I.e., +The API definition document describes the API. I.e., there is no need to include the `/api` operation in the API definition itself. The idea is that any WFS can be used by developers that are familiar with @@ -87,20 +150,17 @@ client using the OpenAPI definition. The developer may need to learn a little bit about geometry, etc., but it should not be required to read this standard to access the data via the API. -==== Requirements specific to Web Feature Services - -===== Support for generic clients +=== Declaration of conformance classes -In addition, it should be possible to write a "generic" client that can -access Web Feature Services in general, i.e. that are not written for a -specific server or API. To support such clients, the server has to declare the -requirements classes it implements and conforms to. +To support "generic" clients for accessing Web Feature Services in general - and +not "just" a specific API / server, the server has to declare the +requirements classes it implements and conforms to, too. [width="90%",cols="2,6a"] |=== |*Requirement {counter:req-id}* |/req/core/conformance-op + -The server SHALL support the HTTP GET operation at the path `/api/conformance`. +The server SHALL support the HTTP GET operation at the path `/conformance`. |=== [width="90%",cols="2,6a"] @@ -319,7 +379,7 @@ included in a response or a link is not known when the HTTP headers of the response are created. |=== -=== Feature collection metadata +=== Feature collections metadata ==== Operation @@ -338,43 +398,20 @@ The content of that response SHALL be based upon the OpenAPI 3.0 schema link:htt |=== .link:https://raw.githubusercontent.com/opengeospatial/WFS_FES/master/core/openapi/schemas/content.yaml[Schema for the metadata about feature collections] -[source,JSON] +[source,YAML] ---- type: object required: + - links - collections properties: links: type: array items: - $ref: link.yaml + $ref: https://raw.githubusercontent.com/opengeospatial/WFS_FES/master/core/openapi/schemas/link.yaml collections: type: array items: - type: object - required: - - name - - links - properties: - name: - type: string - title: - type: string - description: - type: string - links: - type: array - items: - $ref: link.yaml - extent: - $ref: bbox.yaml - crs: - description: the list of coordinate reference systems supported by the service; the first item is the default coordinate reference system - type: array - items: - type: string - default: - - http://www.opengis.net/def/crs/OGC/1.3/CRS84 $ref: https://raw.githubusercontent.com/opengeospatial/WFS_FES/master/core/openapi/schemas/collectionInfo.yaml ---- @@ -389,9 +426,7 @@ of the response: * a link to the response document in every other media type supported by the server (relation: `alternate`), * links to each feature collection resource in this distribution of the -dataset for each supported encoding (relation: `item`), and -* links to the API definition document in each supported encoding -(relation: `service`). +dataset for each supported encoding (relation: `item`). All links SHALL include the `rel` and `type` link parameters. |=== @@ -467,10 +502,10 @@ For each feature collection, the `extent` property, if provided, SHALL be a boun ---- type: object required: - - collectionId + - name - links properties: - collectionId: + name: description: identifier of the collection used, for example, in URIs type: string title: @@ -514,35 +549,28 @@ geometries only in the default system (WGS84 longitude/latitude). ---- { "links": [ - { "href": "http://data.example.org/index.json", + { "href": "http://data.example.org/collections.json", "rel": "self", "type": "application/json", "title": "this document" }, - { "href": "http://data.example.org/index.html", + { "href": "http://data.example.org/collections.html", "rel": "alternate", "type": "text/html", "title": "this document as HTML" }, - { "href": "http://data.example.org/api.json", - "rel": "service", "type": "application/openapi+json;version=3.0", "title": "the OpenAPI definition as JSON" }, - { "href": "http://data.example.org/api.html", - "rel": "service", "type": "text/html", "title": "the OpenAPI definition as HTML" }, - { "href": "http://catalog.example.org/datasets/buildings#wfs", - "rel": "???", "type": "application/json+ld" } + { "href": "http://schemas.example.org/1.0/foobar.xsd", + "rel": "describedBy", "type": "application/xml", "title": "XML schema for ACME Inc. data" } ], "collections": [ { - "collectionId": "buildings", + "name": "buildings", "title": "Buildings", "description": "Buildings in the city of Bonn.", "extent": { "bbox": [ 7.01, 50.63, 7.22, 50.78 ] }, "links": [ - { "href": "http://data.example.org/buildings.json", - "rel": "about", "type": "application/geo+json", - "title": "Buildings as GeoJSON" }, - { "href": "http://data.example.org/buildings.html", - "rel": "about", "type": "text/html", - "title": "Buildings as HTML" }, + { "href": "http://data.example.org/collections/buildings/items", + "rel": "item", "type": "application/geo+json", + "title": "Buildings" } { "href": "http://example.org/concepts/building.html", "rel": "describedBy", "type": "text/html", - "title": "Feature catalogue for the buildings" } + "title": "Feature catalogue for buildings" } ] } ] @@ -550,6 +578,32 @@ geometries only in the default system (WGS84 longitude/latitude). ---- ================= +=== Feature collection metadata + +==== Operation + +[width="90%",cols="2,6a"] +|=== +|*Requirement {counter:req-id}* |/req/core/sfc-md-op + + +The server SHALL support the HTTP GET operation at the path `/collections/{name}`. + +`name` is the property of the same name in the feature collections metadata. +|=== + +==== Response + +[width="90%",cols="2,6a"] +|=== +|*Requirement {counter:req-id}* |/req/core/sfc-md-success + + +A successful execution of the operation SHALL be reported as a response with a +HTTP status code `200`. + +The content of that response SHALL be the same to the content for this feature +collection in the `/collections` response. +|=== + === Feature collections ==== Operation @@ -560,9 +614,9 @@ geometries only in the default system (WGS84 longitude/latitude). + For every feature collection identified in the metadata about the feature collection (path "/"), -the server SHALL support the HTTP GET operation at the path `/{collectionId}`. +the server SHALL support the HTTP GET operation at the path `/collections/{name}/items`. -`collectionId` is the property of the same name in the feature collection metadata. +`name` is the property of the same name in the feature collections metadata. |=== CAUTION: link:https://github.com/opengeospatial/WFS_FES/issues/17[ISSUE 17] + @@ -842,38 +896,38 @@ the optional `prev` links): [source] ---- -Link: ; rel="self"; type="application/geo+json" -Link: ; rel="alternate"; type="text/html" -Link: ; rel="next"; type="application/geo+json" +Link: ; rel="self"; type="application/geo+json" +Link: ; rel="alternate"; type="text/html" +Link: ; rel="next"; type="application/geo+json" ---- Following the `next` link could return: [source] ---- -Link: ; rel="self"; type="application/geo+json" -Link: ; rel="alternate"; type="text/html" -Link: ; rel="prev"; type="application/geo+json" -Link: ; rel="next"; type="application/geo+json" +Link: ; rel="self"; type="application/geo+json" +Link: ; rel="alternate"; type="text/html" +Link: ; rel="prev"; type="application/geo+json" +Link: ; rel="next"; type="application/geo+json" ---- If an explicit `count` of "50" is used, the links in the response could be: [source] ---- -Link: ; rel="self"; type="application/geo+json" -Link: ; rel="alternate"; type="text/html" -Link: ; rel="next"; type="application/geo+json" +Link: ; rel="self"; type="application/geo+json" +Link: ; rel="alternate"; type="text/html" +Link: ; rel="next"; type="application/geo+json" ---- Following the `next` link could return: [source] ---- -Link: ; rel="self"; type="application/geo+json" -Link: ; rel="alternate"; type="text/html" -Link: ; rel="prev"; type="application/geo+json" -Link: ; rel="next"; type="application/geo+json" +Link: ; rel="self"; type="application/geo+json" +Link: ; rel="alternate"; type="text/html" +Link: ; rel="prev"; type="application/geo+json" +Link: ; rel="next"; type="application/geo+json" ---- ================= @@ -926,10 +980,11 @@ not seem to be needed given the 'Date' HTTP header. For `numberMatched` and |=== |*Requirement {counter:req-id}* |/req/core/f-op + -For every feature in a feature collection (path "/{collectionId}"), -the service SHALL support the HTTP GET operation at the path `/{collectionId}/{id}`. +For every feature in a feature collection (path `/collections/{name}/items`), +the service SHALL support the HTTP GET operation at the path +`/collections/{name}/items/{id}`. -`collectionId` is the property of the same name in the feature collection metadata. +`name` is the property of the same name in the feature collection metadata. `id` is the unique identifier of the feature within the dataset. |=== @@ -973,9 +1028,9 @@ The links in a feature could be (in this example represented as link headers): [source] ---- -Link: ; rel="self"; type="application/geo+json" -Link: ; rel="alternate"; type="text/html" -Link: ; rel="collection"; type="application/geo+json" +Link: ; rel="self"; type="application/geo+json" +Link: ; rel="alternate"; type="text/html" +Link: ; rel="collection"; type="application/geo+json" ---- ================= diff --git a/core/standard/requirements/requirement_fc-md-op.adoc b/core/standard/requirements/requirement_fc-md-op.adoc index 7f7e94f0..bb10aaff 100644 --- a/core/standard/requirements/requirement_fc-md-op.adoc +++ b/core/standard/requirements/requirement_fc-md-op.adoc @@ -2,5 +2,5 @@ |=== |*Requirement {counter:req-id}* |/req/core/fc-md-op + -The server SHALL support the HTTP GET operation at the path `/`. +The server SHALL support the HTTP GET operation at the path `/collections`. |=== diff --git a/docs/17-069.html b/docs/17-069.html index 061c44a1..9d6d20bc 100644 --- a/docs/17-069.html +++ b/docs/17-069.html @@ -649,36 +649,44 @@

OGC Web Feature Service 3.0 - Part 1: Core

  • 7. Requirement Class "Core" @@ -738,12 +746,21 @@

    OGC Web Feature Service 3.0 - Part 1: Core

    • +

      Landing page [1]

      +
      • +

    • Service definition [1]

    • +

      Conformance classes [1]

      +
      • +

    • Feature collections metadata [1]

    • +

      Feature collection metadata [0..n]

      +
      • +

    • Feature collection [0..n]

    • @@ -1519,6 +1536,9 @@

      7.1. Overview

      clients to connect to the server or by development tools to support the implementation of servers and clients.

    +
    +

    !!! Update diagram and description

    +
    PT1 FIG01 @@ -1540,9 +1560,115 @@

    7.1. Overview

    -

    7.2. API definition

    +

    7.2. API landing page

    -

    7.2.1. General requirements

    +

    7.2.1. Operation

    + ++++ + + + + + + +

    Requirement 1

    +

    /req/core/root-op

    +
    +
    +

    The server SHALL support the HTTP GET operation at the path /.

    +
    +
    +
    +

    7.2.2. Response

    + ++++ + + + + + + +

    Requirement 2

    +

    /req/core/root-success

    +
    +
    +

    A successful execution of the operation SHALL be reported as a response with a +HTTP status code 200.

    +
    +
    +

    The content of that response SHALL be based upon the OpenAPI 3.0 schema root.yaml +and include at least links to the following resources:

    +
    +
    +
      +
    • +

      /api (relation type 'service')

      +
      • +
    • +

      /conformance (relation type 'conformance')

      +
      • +
    • +

      /collections (relation type 'data')

      +
      • +
    +
    +
    + + + + + +
    +
    Note
    +    		 +TODO
    +Check, if we can reuse existing relation types instead of 'conformance' and 'data'? +
    +
    +
    +
    Schema for the landing page
    +
    +
    type: object
+required:
+  - links
+properties:
+  links:
+    type: array
+    items:
+      $ref: https://raw.githubusercontent.com/opengeospatial/WFS_FES/master/core/openapi/schemas/link.yaml
    +
    +
    +
    +
    Example 2. Landing page response document
    +
    +
    +
    +
    {
+  "links": [
+    { "href": "http://data.example.org/",
+      "rel": "self", "type": "application/json", "title": "this document" },
+    { "href": "http://data.example.org/api",
+      "rel": "service", "type": "application/openapi+json;version=3.0", "title": "the API definition" },
+    { "href": "http://data.example.org/conformance",
+      "rel": "conformance", "type": "application/json", "title": "WFS 3.0 conformance classes implemented by this server" },
+    { "href": "http://data.example.org/collections",
+      "rel": "data", "type": "application/json", "title": "Metadata about the feature collections" }
+  ]
+}
    +
    +
    +
    +
    +
    +
    +
    +

    7.3. API definition

    Every WFS is defined by an API definition that describes the capabilities of the server and which can be used by clients to connect to the server or @@ -1555,7 +1681,7 @@

    < -

    Requirement 1

    +

    Requirement 3
    -

    The API definition document is the "landing page" for the API. I.e., +

    The API definition document describes the API. I.e., there is no need to include the /api operation in the API definition itself.

    @@ -1601,15 +1727,12 @@

    < to access the data via the API.

    -
    -

    7.2.2. Requirements specific to Web Feature Services

    -
    -
    Support for generic clients
    +
    +

    7.4. Declaration of conformance classes

    -

    In addition, it should be possible to write a "generic" client that can -access Web Feature Services in general, i.e. that are not written for a -specific server or API. To support such clients, the server has to declare the -requirements classes it implements and conforms to.

    +

    To support "generic" clients for accessing Web Feature Services in general - and +not "just" a specific API / server, the server has to declare the +requirements classes it implements and conforms to, too.

    @@ -1618,12 +1741,12 @@

    Requirement 2

    +
    @@ -1635,7 +1758,7 @@

    Requirement 3

    +

    Requirement 4

    /req/core/conformance-op

    -

    The server SHALL support the HTTP GET operation at the path /api/conformance.

    +

    The server SHALL support the HTTP GET operation at the path /conformance.

    Requirement 5

    /req/core/conformance-success

    @@ -1664,7 +1787,7 @@
    -
    Example 2. Requirements class response document
    +
    Example 3. Requirements class response document

    This example response in JSON is for a server that supports OpenAPI 3.0 for @@ -1685,10 +1808,8 @@

    -

    7.3. HTTP 1.1

    +

    7.5. HTTP 1.1

    @@ -1696,7 +1817,7 @@

    7.3. HTTP 1.1

    - +

    Requirement 4

    Requirement 6

    /req/core/http

    @@ -1711,7 +1832,7 @@

    7.3. HTTP 1.1

    -

    7.4. Web caching

    +

    7.6. Web caching

    Entity tags are a mechanism for web cache validation and for supporting conditional requests to reduce network traffic. Entity tags are specified by HTTP/1.1 (RFC 2616).

    @@ -1762,7 +1883,7 @@

    7.4. Web cachin

    -

    7.5. Support for cross-origin requests

    +

    7.7. Support for cross-origin requests

    To access data from a HTML page where the data is on another host than the webpage is by default prohibited for security reasons ("same-origin policy"). @@ -1803,7 +1924,7 @@

    -

    7.6. Encodings

    +

    7.8. Encodings

    While WFS 3.0 does not include any mandatory encoding, it recommends the following encodings. See Clause 6 (Overview) for a discussion.

    @@ -1895,7 +2016,7 @@

    7.6. Encodings<

    -

    7.7. Link headers

    +

    7.9. Link headers

    @@ -1921,9 +2042,9 @@

    7.7. Link hea

    -

    7.8. Feature collection metadata

    +

    7.10. Feature collections metadata

    -

    7.8.1. Operation

    +

    7.10.1. Operation

    @@ -1931,19 +2052,19 @@

    7.8.1. Operation

    - +

    Requirement 5

    Requirement 7

    /req/core/fc-md-op

    -

    The server SHALL support the HTTP GET operation at the path /.

    +

    The server SHALL support the HTTP GET operation at the path /collections.
    -

    7.8.2. Response

    +

    7.10.2. Response

    @@ -1951,7 +2072,7 @@

    7.8.2. Response

    - + - + - + - + - +

    Requirement 6

    Requirement 8

    /req/core/fc-md-success

    @@ -1968,41 +2089,18 @@

    7.8.2. Response

    Schema for the metadata about feature collections
    -
    type: object
+
    type: object
 required:
+  - links
   - collections
 properties:
   links:
     type: array
     items:
-      $ref: link.yaml
+      $ref: https://raw.githubusercontent.com/opengeospatial/WFS_FES/master/core/openapi/schemas/link.yaml
   collections:
     type: array
     items:
-      type: object
-      required:
-        - name
-        - links
-      properties:
-        name:
-          type: string
-        title:
-          type: string
-        description:
-          type: string
-        links:
-          type: array
-          items:
-            $ref: link.yaml
-        extent:
-          $ref: bbox.yaml
-        crs:
-          description: the list of coordinate reference systems supported by the service; the first item is the default coordinate reference system
-          type: array
-          items:
-            type: string
-          default:
-            - http://www.opengis.net/def/crs/OGC/1.3/CRS84
       $ref: https://raw.githubusercontent.com/opengeospatial/WFS_FES/master/core/openapi/schemas/collectionInfo.yaml
    @@ -2013,7 +2111,7 @@

    7.8.2. Response

    Requirement 7

    Requirement 9

    /req/core/fc-md-links

    @@ -2032,11 +2130,7 @@

    7.8.2. Response

  • links to each feature collection resource in this distribution of the -dataset for each supported encoding (relation: item), and

    -
    • -
  • -

    links to the API definition document in each supported encoding -(relation: service).

    +dataset for each supported encoding (relation: item).

    • @@ -2100,7 +2194,7 @@

    7.8.2. Response

    Requirement 8

    Requirement 10

    /req/core/fc-md-items

    @@ -2118,7 +2212,7 @@

    7.8.2. Response

    Requirement 9

    Requirement 11

    /req/core/fc-md-links

    @@ -2155,7 +2249,7 @@

    7.8.2. Response

    Requirement 10

    Requirement 12

    /req/core/fc-md-extent

    @@ -2170,10 +2264,10 @@

    7.8.2. Response

    type: object
 required:
-  - collectionId
+  - name
   - links
 properties:
-  collectionId:
+  name:
     description: identifier of the collection used, for example, in URIs
     type: string
   title:
@@ -2210,7 +2304,7 @@ 
    7.8.2. Response
    -
    Example 3. Feature collection metadata response document
    +
    Example 4. Feature collection metadata response document

    This feature collection metadata example response in JSON is for a dataset with @@ -2232,35 +2326,28 @@

    7.8.2. Response

    {
   "links": [
-    { "href": "http://data.example.org/index.json",
+    { "href": "http://data.example.org/collections.json",
       "rel": "self", "type": "application/json", "title": "this document" },
-    { "href": "http://data.example.org/index.html",
+    { "href": "http://data.example.org/collections.html",
       "rel": "alternate", "type": "text/html", "title": "this document as HTML" },
-    { "href": "http://data.example.org/api.json",
-      "rel": "service", "type": "application/openapi+json;version=3.0", "title": "the OpenAPI definition as JSON" },
-    { "href": "http://data.example.org/api.html",
-      "rel": "service", "type": "text/html", "title": "the OpenAPI definition as HTML" },
-    { "href": "http://catalog.example.org/datasets/buildings#wfs",
-      "rel": "???", "type": "application/json+ld" }
+    { "href": "http://schemas.example.org/1.0/foobar.xsd",
+      "rel": "describedBy", "type": "application/xml", "title": "XML schema for ACME Inc. data" }
   ],
   "collections": [
     {
-      "collectionId": "buildings",
+      "name": "buildings",
       "title": "Buildings",
       "description": "Buildings in the city of Bonn.",
       "extent": {
         "bbox": [ 7.01, 50.63, 7.22, 50.78 ]
       },
       "links": [
-        { "href": "http://data.example.org/buildings.json",
-          "rel": "about", "type": "application/geo+json",
-          "title": "Buildings as GeoJSON" },
-        { "href": "http://data.example.org/buildings.html",
-          "rel": "about", "type": "text/html",
-          "title": "Buildings as HTML" },
+        { "href": "http://data.example.org/collections/buildings/items",
+          "rel": "item", "type": "application/geo+json",
+          "title": "Buildings" }
         { "href": "http://example.org/concepts/building.html",
           "rel": "describedBy", "type": "text/html",
-          "title": "Feature catalogue for the buildings" }
+          "title": "Feature catalogue for buildings" }
       ]
     }
   ]
@@ -2272,9 +2359,9 @@ 
    7.8.2. Response
    -

    7.9. Feature collections

    +

    7.11. Feature collection metadata

    -

    7.9.1. Operation

    +

    7.11.1. Operation

    @@ -2282,17 +2369,68 @@

    7.9.1. Operatio

    - + + + + +

    Requirement 11

    Requirement 13

    +

    /req/core/sfc-md-op

    +
    +
    +

    The server SHALL support the HTTP GET operation at the path /collections/{name}.

    +
    +
    +

    name is the property of the same name in the feature collections metadata.

    +
    +
    +
    +

    7.11.2. Response

    + ++++ + + + + + + +

    Requirement 14

    +

    /req/core/sfc-md-success

    +
    +
    +

    A successful execution of the operation SHALL be reported as a response with a +HTTP status code 200.

    +
    +
    +

    The content of that response SHALL be the same to the content for this feature +collection in the /collections response.

    +
    +
    +
    +
    +

    7.12. Feature collections

    +
    +

    7.12.1. Operation

    + ++++ + + + @@ -2312,7 +2450,7 @@

    7.9.1. Operatio
    -

    7.9.2. Parameter count

    +

    7.12.2. Parameter count

    Requirement 15

    /req/core/fc-op

    For every feature collection identified in the metadata about the feature collection (path "/"), -the server SHALL support the HTTP GET operation at the path /{collectionId}.

    +the server SHALL support the HTTP GET operation at the path /collections/{name}/items.

    -

    collectionId is the property of the same name in the feature collection metadata.

    +

    name is the property of the same name in the feature collections metadata.
    @@ -2320,7 +2458,7 @@

    7.9.2.

    - + - +

    Requirement 12

    Requirement 16

    /req/core/fc-count-definition

    @@ -2370,7 +2508,7 @@

    7.9.2.

    Requirement 13

    Requirement 17

    /req/core/fc-count-response-1

    @@ -2412,7 +2550,7 @@

    7.9.2.

    -

    7.9.3. Parameter bbox

    +

    7.12.3. Parameter bbox

    @@ -2420,7 +2558,7 @@

    7.9.3. Pa

    - + - +

    Requirement 14

    Requirement 18

    /req/core/fc-bbox-definition

    @@ -2455,7 +2593,7 @@

    7.9.3. Pa

    Requirement 15

    Requirement 19

    /req/core/fc-bbox-response

    @@ -2492,7 +2630,7 @@

    7.9.3. Pa (west-most box edge) is larger than the third value (east-most box edge).

    -
    Example 4. The bounding box of the New Zealand Exclusive Economic Zone
    +
    Example 5. The bounding box of the New Zealand Exclusive Economic Zone

    The bounding box of the New Zealand Exclusive Economic Zone in WGS84 (from 160.6°E to 170°W and from 55.95°S to 25.89°S) @@ -2507,7 +2645,7 @@

    7.9.3. Pa

    -

    7.9.4. Parameters for filtering on feature properties

    +

    7.12.4. Parameters for filtering on feature properties

    @@ -2556,7 +2694,7 @@

    -
    Example 5. An additional parameter to filter buildings based on their function
    +
    Example 6. An additional parameter to filter buildings based on their function
    @@ -2582,7 +2720,7 @@

    -

    7.9.5. Response

    +

    7.12.5. Response

    @@ -2590,7 +2728,7 @@

    7.9.5. Response

    - + - + - +

    Requirement 16

    Requirement 20

    /req/core/fc-response

    @@ -2653,7 +2791,7 @@

    7.9.5. Response

    Requirement 17

    Requirement 21

    /req/core/fc-links

    @@ -2772,7 +2910,7 @@

    7.9.5. Response

    Requirement 18

    Requirement 22

    /req/core/fc-rel-type

    @@ -2796,7 +2934,7 @@

    7.9.5. Response

    -
    Example 6. Links
    +
    Example 7. Links

    If the request is to return building features and "10" is the default count, @@ -2806,9 +2944,9 @@

    7.9.5. Response
    -
    Link: <http://data.example.org/buildings.json>; rel="self"; type="application/geo+json"
-Link: <http://data.example.org/buildings.html>; rel="alternate"; type="text/html"
-Link: <http://data.example.org/buildings.json?startIndex=10>; rel="next"; type="application/geo+json"
    +
    Link: <http://data.example.org/collections/buildings/items.json>; rel="self"; type="application/geo+json"
+Link: <http://data.example.org/collections/buildings/items.html>; rel="alternate"; type="text/html"
+Link: <http://data.example.org/collections/buildings/items.json?startIndex=10>; rel="next"; type="application/geo+json"
    @@ -2816,10 +2954,10 @@

    7.9.5. Response
    -
    Link: <http://data.example.org/buildings.json?startIndex=10>; rel="self"; type="application/geo+json"
-Link: <http://data.example.org/buildings.html?startIndex=10>; rel="alternate"; type="text/html"
-Link: <http://data.example.org/buildings.json?startIndex=0>; rel="prev"; type="application/geo+json"
-Link: <http://data.example.org/buildings.json?startIndex=20>; rel="next"; type="application/geo+json"
    +
    Link: <http://data.example.org/collections/buildings/items.json?startIndex=10>; rel="self"; type="application/geo+json"
+Link: <http://data.example.org/collections/buildings/items.html?startIndex=10>; rel="alternate"; type="text/html"
+Link: <http://data.example.org/collections/buildings/items.json?startIndex=0>; rel="prev"; type="application/geo+json"
+Link: <http://data.example.org/collections/buildings/items.json?startIndex=20>; rel="next"; type="application/geo+json"
    @@ -2827,9 +2965,9 @@

    7.9.5. Response
    -
    Link: <http://data.example.org/buildings.json?count=50>; rel="self"; type="application/geo+json"
-Link: <http://data.example.org/buildings.html?count=50>; rel="alternate"; type="text/html"
-Link: <http://data.example.org/buildings.json?count=50&startIndex=50>; rel="next"; type="application/geo+json"
    +
    Link: <http://data.example.org/collections/buildings/items.json?count=50>; rel="self"; type="application/geo+json"
+Link: <http://data.example.org/collections/buildings/items.html?count=50>; rel="alternate"; type="text/html"
+Link: <http://data.example.org/collections/buildings/items.json?count=50&startIndex=50>; rel="next"; type="application/geo+json"
    @@ -2837,10 +2975,10 @@

    7.9.5. Response
    -
    Link: <http://data.example.org/buildings.json?count=50&startIndex=50>; rel="self"; type="application/geo+json"
-Link: <http://data.example.org/buildings.html?count=50&startIndex=50>; rel="alternate"; type="text/html"
-Link: <http://data.example.org/buildings.json?count=50&startIndex=0>; rel="prev"; type="application/geo+json"
-Link: <http://data.example.org/buildings.json?count=50&startIndex=100>; rel="next"; type="application/geo+json"
    +
    Link: <http://data.example.org/collections/buildings/items.json?count=50&startIndex=50>; rel="self"; type="application/geo+json"
+Link: <http://data.example.org/collections/buildings/items.html?count=50&startIndex=50>; rel="alternate"; type="text/html"
+Link: <http://data.example.org/collections/buildings/items.json?count=50&startIndex=0>; rel="prev"; type="application/geo+json"
+Link: <http://data.example.org/collections/buildings/items.json?count=50&startIndex=100>; rel="next"; type="application/geo+json"

    @@ -2897,9 +3035,9 @@

    7.9.5. Response

    -

    7.10. Feature

    +

    7.13. Feature

    -

    7.10.1. Operation

    +

    7.13.1. Operation

    @@ -2907,16 +3045,17 @@

    7.10.1. Operati

    - + + + + + + + + + - + - + - + - + - + - + - + - + + - + @@ -4531,28 +4670,28 @@

    Annex

    - + - + - + - +

    Requirement 19

    Requirement 23

    /req/core/f-op

    -

    For every feature in a feature collection (path "/{collectionId}"), -the service SHALL support the HTTP GET operation at the path /{collectionId}/{id}.

    +

    For every feature in a feature collection (path /collections/{name}/items), +the service SHALL support the HTTP GET operation at the path +/collections/{name}/items/{id}.

    -

    collectionId is the property of the same name in the feature collection metadata.

    +

    name is the property of the same name in the feature collection metadata.

    id is the unique identifier of the feature within the dataset.

    @@ -2953,7 +3092,7 @@

    7.10.1. Operati

    -

    7.10.2. Response

    +

    7.13.2. Response

    @@ -2961,7 +3100,7 @@

    7.10.2. Response<

    - + - +

    Requirement 20

    Requirement 24

    /req/core/f-success

    @@ -2979,7 +3118,7 @@

    7.10.2. Response<

    Requirement 21

    Requirement 25

    /req/core/f-links

    @@ -3019,16 +3158,16 @@

    7.10.2. Response<

    -
    Example 7. Links
    +
    Example 8. Links

    The links in a feature could be (in this example represented as link headers):

    -
    Link: <http://data.example.org/buildings/123.json>; rel="self"; type="application/geo+json"
-Link: <http://data.example.org/buildings/123.html>; rel="alternate"; type="text/html"
-Link: <http://data.example.org/buildings.json>; rel="collection"; type="application/geo+json"
    +
    Link: <http://data.example.org/collections/buildings/items/123.json>; rel="self"; type="application/geo+json"
+Link: <http://data.example.org/collections/buildings/items/123.html>; rel="alternate"; type="text/html"
+Link: <http://data.example.org/collections/buildings/items.json>; rel="collection"; type="application/geo+json"
    @@ -3129,7 +3268,7 @@

    Requirement 22

    Requirement 26

    /req/html/definition

    @@ -3147,7 +3286,7 @@

    Requirement 23

    Requirement 27

    /req/html/content

    @@ -3238,7 +3377,7 @@

    Requirement 24

    Requirement 28

    /req/geojson/definition

    @@ -3265,7 +3404,7 @@

    Requirement 25

    Requirement 29

    /req/geojson/content

    @@ -3347,7 +3486,7 @@

    Requirement 26

    Requirement 30

    /req/gmlsf0/definition

    @@ -3375,7 +3514,7 @@

    Requirement 27

    Requirement 31

    /req/gmlsf0/content

    @@ -3469,7 +3608,7 @@

    Requirement 28

    Requirement 32

    /req/gmlsf2/definition

    @@ -3497,7 +3636,7 @@

    Requirement 29

    Requirement 33

    /req/gmlsf2/content

    @@ -3564,7 +3703,7 @@

    9

    Requirement 30

    Requirement 34

    /req/oas30/oas-definition-1

    @@ -3582,7 +3721,7 @@

    9

    Requirement 31

    Requirement 35

    /req/oas30/oas-definition-2

    @@ -3603,7 +3742,7 @@

    9

    Requirement 32

    Requirement 36

    /req/oas30/oas-impl

    The server SHALL implement all capabilities specified in the OpenAPI @@ -3647,7 +3786,7 @@

    Requirement 33

    Requirement 37

    /req/oas30/completeness

    @@ -3701,7 +3840,7 @@

    9.3. Exceptions

    Requirement 34

    Requirement 38

    /req/oas30/exceptions-codes

    @@ -3732,7 +3871,7 @@

    9.3. Exceptions

    Requirement 35

    Requirement 39

    /req/oas30/exceptions-400

    @@ -3764,7 +3903,7 @@

    9.3. Exceptions

    Requirement 36

    Requirement 40

    /req/oas30/exceptions-500

    @@ -3790,7 +3929,7 @@

    9.3. Exceptions

    -
    Example 8. An exception response object definition
    +
    Example 9. An exception response object definition
    @@ -3816,7 +3955,7 @@

    9.4. Security

    Requirement 37

    Requirement 41

    /req/oas30/security

    @@ -3869,7 +4008,7 @@

    Requirement 38

    Requirement 42

    /req/oas30/fc-md-op

    @@ -4517,7 +4656,7 @@

    Annex

    0.3

    C. Portele

    all

    address issues #2, #5, #6, #7, #8, #14, #15, #19

    address issues #2, #5, #6, #7, #8, #14, #15, #19

    2018-01-22

    0.5

    C. Portele

    2,3,5,7

    add links to recent issues on GitHub; address issues #31, #32

    add links to recent issues on GitHub; address issues #31, #32

    2018-02-11

    0.6

    C. Portele

    2,6,7,8

    address issue #25

    address issue #25

    2018-02-27

    0.7

    C. Portele

    all

    address issues #3, #9, #12, #22, #23, #24, #44; add links to issues #41, #45, #46, #47

    address issues #3, #9, #12, #22, #23, #24, #44; add links to issues #41, #45, #46, #47

    2018-03-04

    0.8

    T. Schaub

    7,B

    JSON schema fixes #54, #55

    JSON schema fixes #54, #55
    @@ -4580,7 +4719,7 @@

    Annex D: Biblio