Merge pull request #1009 from opengeospatial/cp-part5

cportele · web-flow · commit 18c2e28c4199 · 2025-07-14T16:57:22.000+02:00
Prepare Part 5 for v1.0.0

Merge as decided in the meeting 2025-07-14
diff --git a/extensions/schemas/standard/23-058.adoc b/extensions/schemas/standard/23-058.adoc
@@ -49,8 +49,8 @@
 [cols = "^", frame = "none", grid = "none"]
 |===
 |*Copyright notice*
-|Copyright (C) 2024 Open Geospatial Consortium
-|To obtain additional rights of use, visit http://www.opengeospatial.org/legal/
+|Copyright (C) 2025 Open Geospatial Consortium
+|To obtain additional rights of use, visit https://www.ogc.org/legal/
 |===
 
 [cols = "^", frame = "none"]
@@ -109,7 +109,7 @@ include::clause_6_overview.adoc[]
 
 include::clause_7_schemas.adoc[]
 
-include::clause_8_core_roles_for_features.adoc[]
+include::clause_8_advanced_property_roles.adoc[]
 
 include::clause_9_references.adoc[]
 
diff --git a/extensions/schemas/standard/annex_bibliography.adoc b/extensions/schemas/standard/annex_bibliography.adoc
@@ -7,7 +7,7 @@
 
 [[ogc-link-relations]] Open Geospatial Consortium (OGC). **OGC Link Relation Type Register** [online, viewed 2023-10-14], Available at http://www.opengis.net/def/rel
 
-[[OpenAPI]] OpenAPI Initiative (OAI). **OpenAPI Specification 3.0** [online, viewed 2023-10-14]. 2020. Available at http://spec.openapis.org/oas/v3.0.3
+[[OpenAPI]] OpenAPI Initiative (OAI). **OpenAPI Specification 3.1** [online, viewed 2025-07-14]. 2024. Available at http://spec.openapis.org/oas/v3.1.1 
 
 [[rfc6906]] Internet Engineering Task Force (IETF). RFC 6906: **The 'profile' Link Relation Type**. Edited by E. Wilde. 2013. Available at https://www.rfc-editor.org/rfc/rfc6906.html
 
diff --git a/extensions/schemas/standard/clause_0_front_material.adoc b/extensions/schemas/standard/clause_0_front_material.adoc
@@ -25,7 +25,7 @@ The main reasons for using JSON Schema are:
 
 This Standard specifies basic provisions for schemas that are applicable to any type of geospatial data as well as general provision for profiles. These provisions are not specific to features and as such could be copied in or moved to OGC API - Common in the future.
 
-Additional provisions are added for <<rc_core-roles-features,schemas for feature data>>.
+Additional provisions are added for <<rc_advanced-property-roles,schemas for feature data>>.
 
 In OGC Web APIs, geospatial data is shared in collections (path `/collections/{collectionId}`). The schema of items in a collection provides information as to how to interact with the collection. 
 
@@ -73,7 +73,10 @@ Recipients of this document are requested to submit, with their comments, notifi
 The following organizations submitted this document to the Open Geospatial Consortium (OGC):
 
 * CubeWerx Inc.
+* Ecere Corporation
 * interactive instruments
+* Meteorological Service of Canada
+* Natural Resources Canada
 
 [big]*v.     Submitters*
 
@@ -83,4 +86,7 @@ All questions regarding this submission should be directed to the editors or the
 |*Name* |*Affiliation*
 |Panagiotis (Peter) A. Vretanos _(editor)_ |CubeWerx Inc.
 |Clemens Portele _(editor)_ |interactive instruments
+|Jérôme Jacovella-St-Louis|Ecere Corporation
+|Joost van Ulden |Natural Resources Canada
+|Tom Kralidis |Meteorological Service of Canada
 |===
diff --git a/extensions/schemas/standard/clause_10_returnables_and_receivables.adoc b/extensions/schemas/standard/clause_10_returnables_and_receivables.adoc
@@ -36,4 +36,5 @@ This requirements class supports clients that want to discover the list of resou
 ^|*Requirement {counter:req-num}* |/req/{req-class}/{req}
 ^|A |A successful execution of the operation SHALL be reported as a response with a HTTP status code `200`.
 ^|B |For responses that use `application/schema+json` as the `Content-Type` of the response, the response SHALL conform to <<rc_schemas>>.
+^|C |The "additionalProperties" member with a value of "true" (the default) or "false" is used to state the expected behavior with respect to properties that are not explicitly declared in the schema. If "additionalProperties" is set to "false", properties that are not explicitly declared in the schema SHALL NOT be allowed, otherwise they SHALL be allowed.
 |===
diff --git a/extensions/schemas/standard/clause_13_profile_parameter.adoc b/extensions/schemas/standard/clause_13_profile_parameter.adoc
@@ -23,7 +23,7 @@ To request one or more profiles, a query parameter "profile" can be used:
 [width="90%",cols="2,7a"]
 |===
 ^|*Requirement {counter:req-num}* |/req/{req-class}/{req}
-^|A |The GET operation on selected resources SHALL support a query parameter "profile" with the following characteristics (using an OpenAPI Specification 3.0 fragment):
+^|A |The GET operation on selected resources SHALL support a query parameter "profile" with the following characteristics (using an OpenAPI Specification 3.1 fragment):
 
 [source,YAML]
 ----
diff --git a/extensions/schemas/standard/clause_14_profile_references.adoc b/extensions/schemas/standard/clause_14_profile_references.adoc
@@ -4,7 +4,7 @@
 
 The Requirements Class "Profiles for references" specifies three profiles for representing references to other resources.
 
-NOTE: As with <<rc_references>>, this requirements class can probably be generalized to cover also other types of references, but this requires a better understanding about the types of references that have to be supported.
+The requirements stated in this Standard cover only simple cases. More complex cases, such as references to geospatial data in different collections, are not covered. 
 
 [cols="2,7",width="90%"]
 |===
@@ -30,13 +30,9 @@ For features, the query parameter "profile" will be applicable to the GET operat
 [width="90%",cols="2,7a"]
 |===
 ^|*Requirement {counter:req-num}* |/req/{req-class}/{req}
-^|A |In the profile "rel-as-key" (`\http://www.opengis.net/def/profile/OGC/0/rel-as-key`) a reference in the response SHALL be represented by:
-
-- The `resourceId` of the referenced resource (a string or integer, depending on the type of the identifier property in the referenced collection), if the property with role "reference" has the keyword "x-ogc-collectionId" with a string value (a fixed collection).
+^|A |In the profile "rel-as-key" (`\http://www.opengis.net/def/profile/OGC/0/rel-as-key`) a reference in the response SHALL be represented by the `resourceId` of the referenced resource (a string or integer, depending on the type of the identifier property in the referenced collection), if the property with role "reference" has the keyword "x-ogc-collectionId" with a string value (a fixed collection).
 |===
 
-NOTE: What should be provided, if "x-ogc-collectionId" is an array (that is, the referenced resources/features may be in different collections)? A string that combines the `collectionId` and `resourceId`? An object with `collectionId` and `resourceId` properties?
-
 [[example_14_1]]
 .Encoding of a road accident feature in GeoJSON and profile "rel-as-key"
 ====
diff --git a/extensions/schemas/standard/clause_2_conformance.adoc b/extensions/schemas/standard/clause_2_conformance.adoc
@@ -4,7 +4,7 @@ This Standard defines the following requirements classes, grouped by their stand
 
 * Schema for a collection of data
 ** <<rc_schemas>> specifies basic provisions for schemas of items in a collection of geospatial data, for example, features, and the representation of a schema in JSON Schema.
-** <<rc_core-roles-features>> specifies additional property roles for feature data.
+** <<rc_advanced-property-roles>> specifies additional property roles for geospatial data, in particular, feature data.
 ** <<rc_references>> specifies additional provisions for properties that reference another resource.
 ** <<rc_profile-codelists>> specifies two profiles for representing values from a codelist in a schema.
 ** <<rc_profile-domains>> specifies two profiles for representing value domains of a property in a schema.
@@ -25,13 +25,13 @@ Conformance with this Standard shall be checked using all the relevant tests spe
 |===
 |Conformance class |URI
 |Schemas |`\http://www.opengis.net/spec/{standard}/{m_n}/conf/schemas`
-|Core roles for features |`\http://www.opengis.net/spec/{standard}/{m_n}/conf/core-roles-features`
+|Core roles for features |`\http://www.opengis.net/spec/{standard}/{m_n}/conf/advanced-property-roles`
 |References |`\http://www.opengis.net/spec/{standard}/{m_n}/conf/references`
 |Returnables and Receivables |`\http://www.opengis.net/spec/{standard}/{m_n}/conf/returnables-and-receivables`
 |Queryables |`\http://www.opengis.net/spec/{standard}/{m_n}/conf/queryables`
 |Sortables |`\http://www.opengis.net/spec/{standard}/{m_n}/conf/sortables`
 |Profile query parameter |`\http://www.opengis.net/spec/{standard}/{m_n}/conf/profile-parameter`
-|Profiles for feature references |`\http://www.opengis.net/spec/{standard}/{m_n}/conf/profile-references`
+|Profiles for references |`\http://www.opengis.net/spec/{standard}/{m_n}/conf/profile-references`
 |Profiles for codelists |`\http://www.opengis.net/spec/{standard}/{m_n}/conf/profile-codelists`
 |Profiles for value domains |`\http://www.opengis.net/spec/{standard}/{m_n}/conf/profile-domains`
 |===
diff --git a/extensions/schemas/standard/clause_6_overview.adoc b/extensions/schemas/standard/clause_6_overview.adoc
@@ -67,4 +67,4 @@ Profiles are a general mechanism that allows to support variations in the resour
 
 To request one or more profiles, a query parameter "profile" can be used. The server determines the applicable profile(s) for the selected media type.
 
-In total, four profiles are specified for schemas and three profiles are specified for feature data.
+In total, four profiles are specified for schemas and three profiles are specified for geospatial data.
diff --git a/extensions/schemas/standard/clause_7_schemas.adoc b/extensions/schemas/standard/clause_7_schemas.adoc
@@ -2,12 +2,14 @@
 [#rc_{req-class}]
 == Requirements Class "Schemas"
 
-The Requirements Class "Schemas" specifies basic provisions for schemas of items in a data collection, such as the features in a feature collection, and the representation of a schema in JSON Schema. The schema represents a logical model, independent of the format in which the web resource is encoded.
+The Requirements Class "Schemas" specifies basic provisions for schemas for a collection of geospatial data, such as the features in a feature collection, and the representation of a schema in JSON Schema. 
+
+The schema represents a logical model, independent of the format in which the data is encoded when a representation is requested via a HTTP request.
 
 [cols="2,7",width="90%"]
 |===
 ^|*Requirements Class* |http://www.opengis.net/spec/{standard}/{m_n}/req/{req-class}
-|Target type |Schema for a collection of data
+|Target type |Schema for a collection of geospatial data
 |Dependency |<<json-schema,JSON Schema: A Media Type for Describing JSON Documents>>
 |Indirect Dependency |<<json-schema-validation,JSON Schema Validation: A Vocabulary for Structural Validation of JSON>>
 |Indirect Dependency |<<ogc06_103r4,Simple feature access - Part 1: Common architecture>>
@@ -40,12 +42,11 @@ In addition to the JSON Schema data types, geospatial data typically also uses s
 ^|*Requirement {counter:req-num}* |/req/{req-class}/{req}
 ^|A |Each property SHALL include a "type" member, except for spatial properties.
 ^|B |Each spatial property SHALL not include a "type" or "$ref" member.
-^|C |Each spatial property SHALL include a "format" member with a string value "geometry", followed by a hyphen, followed by the name of the geometry type in lower case. I.e., the values for the Simple Feature geometry types are: "geometry-point", "geometry-multipoint", "geometry-linestring", "geometry-multilinestring", "geometry-polygon", "geometry-multipolygon", and "geometry-geometrycollection". In addition, the following special values are supported: "geometry-any" as the wildcard for any geometry type, "geometry-point-or-multipoint" for a Point or MultiPoint, "geometry-linestring-or-multilinestring" for a LineString or MultiLineString, and "geometry-polygon-or-multipolygon" for a Polygon or MultiPolygon.
+^|C |Each spatial property SHALL include a "format" member with a string value "geometry", followed by a hyphen, followed by the name of the geometry type in lower case. I.e., the values for the core Simple Feature geometry types are: "geometry-point", "geometry-multipoint", "geometry-linestring", "geometry-multilinestring", "geometry-polygon", "geometry-multipolygon", and "geometry-geometrycollection". In addition, the following special values are supported: "geometry-any" as the wildcard for any geometry type, "geometry-point-or-multipoint" for a Point or MultiPoint, "geometry-linestring-or-multilinestring" for a LineString or MultiLineString, and "geometry-polygon-or-multipolygon" for a Polygon or MultiPolygon.
 ^|D |Each temporal property SHALL be a "string" literal with the appropriate format (e.g., "date-time" or "date" for instances, depending on the temporal granularity).
 ^|E |As a general rule, if the data type of a property has to be more specific than the JSON Schema data types ("number", "integer", "string"), the "format" keyword SHALL be used.
 ^|F |Properties that are only applicable when creating new data or updating existing data SHALL include "writeOnly: true".
 ^|G |Properties that are only applicable when data is fetched SHALL include "readOnly: true".
-^|H |The "additionalProperties" member with a value of "true" (the default) or "false" is used to state the expected behavior with respect to properties that are not explicitly declared in the schema. If "additionalProperties" is set to "false", properties that are not explicitly declared in the schema SHALL NOT be allowed, otherwise they SHALL be allowed.
 |===
 
 The following recommendations are intended to simplify parsing a schema and to help understanding the meaning and representation of the properties:
@@ -66,17 +67,19 @@ The following recommendations are intended to simplify parsing a schema and to h
 ^|J |Properties that represent a 64-bit signed integer SHOULD be represented as an integer with format "int64" (defined in OpenAPI 3.1).
 ^|K |Properties that represent a 32-bit unsigned integer SHOULD be represented as an integer with format "uint32".
 ^|L |Properties that represent a 64-bit unsigned integer SHOULD be represented as an integer with format "uint64".
-^|M |In general, "format" values SHOULD be from the JSON Schema specifciation, the OpenAPI 3.1 specification or the OGC format register (to be established).
+^|M |In general, "format" values SHOULD be from the JSON Schema specifciation, the OpenAPI 3.1 specification or the OGC format register.
 ^|N |For string properties, "minLength", "maxLength", "enum" and/or "pattern" SHOULD be provided, where applicable.
 ^|O |For numeric properties, "multipleOf", "minimum", "exclusiveMinimum", "maximum", "exclusiveMaximum" SHOULD be provided, where applicable.
 ^|P |For integer properties that represent enumerated values (except for codelist values), "enum" SHOULD be provided.
 ^|Q |For string or integer properties that represent codelist values, one of the profiles "codelist-inline" or "codelist-ref" (see <<rc_profile-codelists>>) SHOULD be applied.
-^|R |For array properties, the property SHOULD consist of items that are strings or numbers.
+^|R |For array properties, the property SHOULD consist of items that are strings, numbers or objects.
 ^|S |Required properties SHOULD be included in "required".
 ^|T |The JSON Schema keywords SHOULD be constrained to those mentioned in this recommendation, requirement `/req/{req-class}/properties` and requirements in the _additional keywords_ section below.
 ^|U |"$ref" SHOULD NOT be used, schemas that are reused SHOULD be dereferenced and represented inline.
 |===
 
+NOTE: The OGC format register needs to be established.
+
 [#additional-keywords]
 === Additional keywords
 
diff --git a/extensions/schemas/standard/clause_8_advanced_property_roles.adoc b/extensions/schemas/standard/clause_8_advanced_property_roles.adoc
@@ -1,28 +1,28 @@
-:req-class: core-roles-features
+:req-class: advanced-property-roles
 [#rc_{req-class}]
-== Requirements Class "Core roles for features"
+== Requirements Class "Advanced property roles"
 
-The Requirements Class "Core roles for features" specifies additional property roles for feature data.
+The Requirements Class "Advanced property roles" specifies additional property roles for geospatial data. These roles are in particular applicable to feature data.
 
 [cols="2,7",width="90%"]
 |===
 ^|*Requirements Class* |http://www.opengis.net/spec/{standard}/{m_n}/req/{req-class}
-|Target type |Schema for a feature collection
+|Target type |Schema for a collection of geospatial data
 |Dependency |<<rc_schemas>>
 |===
 
-To understand how features are encoded in a specific format, additional property roles need to be identified in the logical schema. These roles depend on the format.
+To understand how geospatial data is represented in a specific data format, additional property roles need to be identified in the logical schema. The mapping of the roles to the data representation depends on the format.
 
-For example, the role "primary-geometry" is needed in feature types with multiple spatial properties to decide:
+For example, the role "primary-geometry" is needed in feature types with multiple spatial properties to decide, for example:
 
 * Which geometry is encoded as the geometry of a feature in formats such as FlatGeobuf, Shapefile or Mapbox Vector Tiles, which only support a single geometry; or,
 * Which geometry is encoded in the "geometry" member in GeoJSON.
 
-The other roles specified in this requirements class support feature formats that support representing primary temporal information or the type of the feature, such as JSON-FG.
+The other roles specified in this requirements class support formats that support representing primary temporal information or the type, such as JSON-FG.
 
 === Primary geometry
 
-If the features have multiple spatial properties, the role "primary-geometry" can be used to identify the primary geometry of the features.
+If the schema defines multiple spatial properties, the role "primary-geometry" can be used to identify the primary geometry property.
 
 :req: role-primary-geometry
 [#{req-class}_{req}]
@@ -38,7 +38,7 @@ NOTE: Since only a single property can be tagged in the schema as the primary ge
 
 === Primary temporal information
 
-If the features have multiple temporal properties, the roles "primary-instant", "primary-interval-start" and "primary-interval-end" can be used to identify the primary temporal information of the features.
+If the schema defines multiple temporal properties, the roles "primary-instant", "primary-interval-start" and "primary-interval-end" can be used to identify the primary temporal information.
 
 :req: role-primary-instant
 [#{req-class}_{req}]
@@ -68,20 +68,29 @@ If the features have multiple temporal properties, the roles "primary-instant",
 ^|B |At most one property in a schema SHALL have "x-ogc-role" with a value "primary-interval-end".
 |===
 
-:req: primary-temporal-constraints
+:req: role-primary-interval
 [#{req-class}_{req}]
 [width="90%",cols="2,7a"]
 |===
 ^|*Requirement {counter:req-num}* |/req/{req-class}/{req}
-^|A |If a schema has a property with role "primary-instant", the schema SHALL NOT have properties with role "primary-interval-start" or "primary-interval-end".
-^|B |If a schema has properties with both roles "primary-interval-start" and "primary-interval-end", both properties SHALL have the same temporal granularity ("date" or "date-time").
+^|A |A property with "x-ogc-role" set to "primary-interval" SHALL be a temporal property.
+^|B |At most one property in a schema SHALL have "x-ogc-role" with a value "primary-interval".
 |===
 
-NOTE: FUTURE WORK? Consider adding a role "primary-interval" with a proper representation of an interval, e.g., the interval representation in JSON-FG (an array with two dates or timestamps).
+:req: primary-temporal-constraints
+[#{req-class}_{req}]
+[width="90%",cols="2,7a"]
+|===
+^|*Requirement {counter:req-num}* |/req/{req-class}/{req}
+^|A |If a schema has a property with role "primary-instant", the schema SHALL NOT have properties with role "primary-interval-start", "primary-interval-end", or "primary-interval".
+^|B |If a schema has a property with role "primary-interval", the schema SHALL NOT have properties with role "primary-interval-start", "primary-interval-end", or "primary-instant".
+^|C |If a schema has properties with both roles "primary-interval-start" and "primary-interval-end", both properties SHALL have the same temporal granularity ("date" or "date-time").
+^|D |If a schema has a property with only one the roles "primary-interval-start" or "primary-interval-end", the primary temporal information SHALL be the half-bounded interval with the specified start or end.
+|===
 
-=== Feature type
+=== Type
 
-If the features have a property that represents the feature type, the role "type" can be used for this property.
+If the data is organized as features with a property representing the feature type, the role "type" can be used for this property.
 
 :req: role-type
 [#{req-class}_{req}]
diff --git a/extensions/schemas/standard/clause_9_references.adoc b/extensions/schemas/standard/clause_9_references.adoc

Original file line number	Diff line number	Diff line change
`@@ -67,4 +67,4 @@ Profiles are a general mechanism that allows to support variations in the resour`
`67`	`67`
`68`	`68`	`To request one or more profiles, a query parameter "profile" can be used. The server determines the applicable profile(s) for the selected media type.`
`69`	`69`
`70`		`-In total, four profiles are specified for schemas and three profiles are specified for feature data.`
	`70`	`+In total, four profiles are specified for schemas and three profiles are specified for geospatial data.`