You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardexpand all lines: core/standard/clause_0_front_material.adoc
+3-3
Original file line number
Diff line number
Diff line change
@@ -32,7 +32,7 @@ A record is the atomic unit of information in a catalog, It contains descriptive
32
32
* links to access the resource,
33
33
* etc.
34
34
35
-
This information is generic and can be used to describe a wide variety of resources. This specification expects and encourages implementations to enrich the information content of a record to suit specific use cases, requirements, domains or communities.
35
+
This information is generic and can be used to describe a wide variety of resources. This specification expects and encourages implementations to enrich the information content of a record to suit specific use cases, requirements, domains or communities of interest.
36
36
37
37
A collection of records is itself described by a record that provides descriptive information about the catalog. The collection also provides access to the records of the collection either by explicitly linking to each record that is an item of the collection or by providing a search endpoint that allows the collection of records to be searched.
38
38
@@ -43,15 +43,15 @@ The search API allows collections of records to be searched using logically conn
A special use case of the catalog deployed as an API is the _local resources catalog_. A local resources catalog is a catalog deployed to make local resources offered by a provider searchable using the catalog information model and API. An example of a local resources catalog is the `/collections` endpoint of http://docs.opengeospatial.org/DRAFTS/20-024.html[OGC API - Common - Part 2: Geospatial data] or http://docs.ogc.org/is/17-069r3/17-069r3.html[OGC API - Features - Part 1: Core]. Adding catalog capabilities to this endpoint allows a client to search for collections that satisfy a specified filter expression. Any API endpoint whose function is to provide a list of resources, such as the `/collections` endpoint, can be extended to be a local resources catalog to search for records describing resources served by that API.
54
+
A special use case of the catalog deployed as an API is the _local resources catalog_. A local resources catalog is a catalog deployed to make local resources offered by a provider searchable using the catalog information model and API. An example of a local resources catalog is the `/collections` endpoint of http://docs.opengeospatial.org/DRAFTS/20-024.html[OGC API - Common - Part 2: Geospatial data] or http://docs.ogc.org/is/17-069r3/17-069r3.html[OGC API - Features - Part 1: Core]. Adding catalog capabilities to this endpoint allows a client to search for collections that satisfy a specified filter expression. Any API endpoint defined in an OGC API specification whose function is to provide a list of resources, such as the `/collections` endpoint, can be extended to be a local resources catalog that can be searched for records describing resources served by that API.
Copy file name to clipboardexpand all lines: core/standard/clause_10_security.adoc
+1-1
Original file line number
Diff line number
Diff line change
@@ -3,4 +3,4 @@
3
3
4
4
Given the dependencies on <<OACommon,OGC API - Common>> and <<OAFeat-1,OGC API - Features>> and OGC API - Features and OGC API - Common, aspects of security are discussed in those specifications.
5
5
6
-
Metadata record encryption is out of scope for this specification, however communities who wish to implement record encryption are free to do so as needed.
6
+
Metadata record encryption is out of scope for this Standard, however communities who wish to implement record encryption are free to do so as needed.
Copy file name to clipboardexpand all lines: core/standard/clause_2_conformance.adoc
+23-19
Original file line number
Diff line number
Diff line change
@@ -3,7 +3,7 @@
3
3
4
4
=== Overview
5
5
6
-
Conformance with this standard shall be checked using the tests specified in Annex A (normative) of this document. The framework, concepts, and methodology for testing, and the criteria to claim conformance, are specified in the OGC Compliance Testing Policies and Procedures and the OGC Compliance Testing web site.
6
+
Conformance with this Standard shall be checked using the tests specified in <<annex_ats,Annex A (normative)>> of this document. The framework, concepts, and methodology for testing, and the criteria to claim conformance, are specified in the OGC Compliance Testing Policies and Procedures and the OGC Compliance Testing web site.
7
7
8
8
The standardization target of the conformance classes:
9
9
@@ -17,7 +17,7 @@ The standardization target of the conformance classes:
@@ -37,14 +37,14 @@ The standardization target of the conformance classes:
37
37
38
38
is "Document encoding".
39
39
40
-
https://docs.opengeospatial.org/is/17-069r4/17-069r4.html[OGC API - Features] provides a common foundation for OGC API standards for feature access. Therefore, this standard should be viewed as an extension to OGC API - Features. Conformance to this standard requires demonstrated conformance to the applicable Conformance Classes of https://docs.opengeospatial.org/is/17-069r4/17-069r4.html#_conformance[OGC API - Features].
40
+
https://docs.opengeospatial.org/is/17-069r4/17-069r4.html[OGC API - Features] provides a common foundation for OGC API standards for feature access. Therefore, this Standard should be viewed as an extension to OGC API - Features. Conformance to this Standard requires demonstrated conformance to the applicable Conformance Classes of https://docs.opengeospatial.org/is/17-069r4/17-069r4.html#_conformance[OGC API - Features].
41
41
42
-
The Conformance Classes implemented by an API are advertised through the <<conformance-classes,`/conformance`>> path on the <<landing-page,landing page>>. Each Conformance Class has an associated Requirements Class. The Requirements Classes define the functional requirements which will be tested through the associated Conformance Class.
42
+
The Conformance Classes implemented by an API are advertised through the <<conformance-classes,`/conformance`>> path on the https://docs.ogc.org/is/17-069r3/17-069r3.html#_api_landing_page[landing page]. Each Conformance Class has an associated Requirements Class. The Requirements Classes define the functional requirements which will be tested through the associated Conformance Test.
43
43
44
44
[[building-block-requirements-classes]]
45
45
=== Building blocks
46
46
47
-
This standard also identifies nine (9) building block requirements classes:
47
+
This standard also identifies ten (10) building block requirements classes:
48
48
49
49
* <<clause-record-core,Record Core>>
50
50
* <<clause-record-collection,Record collection>>
@@ -54,6 +54,7 @@ This standard also identifies nine (9) building block requirements classes:
54
54
* <<clause-filtering,Filtering>>
55
55
* <<requirements-class-json-clause,JSON>>
56
56
* <<requirements-class-html-clause,HTML>>
57
+
* <<clause-oas30,OpenAPI 3.0>>
57
58
* <<clause-autodiscovery,Autodiscovery>>
58
59
59
60
The <<clause-record-core,_Record Core_>> conformance class defines the requirements for the core schema of a catalog record which is a set of properties (<<core-properties,core properties>>) that can be used to make any resource discoverable via a catalog. This core set of properties can be extended as required by specific communities of interest and/or use cases.
@@ -72,12 +73,14 @@ The <<requirements-class-json-clause,_JSON_>> conformance class defines the requ
72
73
73
74
The <<requirements-class-html-clause,_HTML_>> conformance class defines the requirements for an HTML representation of a standard catalog record.
74
75
75
-
The <<clause-autodiscovery,Autodiscovery>> conformance class defines requirements that allow catalogs associated with a web page or web site to be discovered.
76
+
The <<<<clause-oas30,OpenAPI 3.0>> conformance class defines the requirements for server that use an http://spec.openapis.org/oas/v3.0.3#openapi-document[OpenAPI 3.0] document to define their API.
77
+
78
+
The <<clause-autodiscovery,Autodiscovery>> conformance class defines requirements that allow catalogs that conform to this Standard and are associated with a web page or web site to be automatically discovered.
76
79
77
80
[[catalog-requirements-classes]]
78
81
=== Catalog deployments
79
82
80
-
Using the above-mentioned building blocks, this standard identifies the following catalog requirements classes:
83
+
Using the above-mentioned building blocks, this Standard identifies the following catalog requirements classes:
Implementors of this specification select one or more of the <<catalog-requirements-classes,catalog requirements classes>> they wish to implement and then implement the required building block requirements classes.
119
+
Implementors of this Standard select one or more of the <<catalog-requirements-classes,catalog deployment requirements classes>> they wish to implement and then implement the required building block requirements classes.
116
120
117
121
=== Conformance testing
118
122
119
-
Conformance with this standard shall be checked using all the relevant tests
123
+
Conformance with this Standard shall be checked using all the relevant tests
120
124
specified in <<ats,Annex A>> of this document. The framework, concepts, and
121
125
methodology for testing, and the criteria to be achieved to claim conformance
122
126
are specified in the OGC Compliance Testing Policies and Procedures and the
@@ -127,9 +131,9 @@ OGC Compliance Testing web site.
0 commit comments