Closed jechterhoff closed 1 year ago
@wilkoquak what do you recommend?
From reading this it seems kind of tricky. I don't have a solution myself, because I don't know enough about the details of JSON schema validation. We do have UML models that define collections (e.g. IMGeluid, about noise regulations).
Decision: Summarize the issue in the document, but do not create specific requirements (since this is a new topic, and an open discussion).
Created new Annex D
One topic that the specification does not address thus far is feature collections. The encoding rules create schema definitions for single features / types with identity. Thus far, we do not have requirements (classes) with which to define the schema for collections of such types. That may be ok, but let's discuss it here. There are different aspects to consider, which I've documented (with according labels) in the following:
scope and naming of collection definitions
In practice, uniform as well as mixed collections are possible. A uniform collection contains features of a single specific type, whereas a mixed collection can have objects of different type. JSON Schema definitions for uniform collections could be defined with name being
{type name} + Collection
, whereas a single definition with nameFeatureCollection
could cover the case of all mixed collections (at least for all types with identity defined by the application schema).structure of collection definitions
The definition for a uniform collection would ensure that the collection members are all valid against a single type definition.
The definition for the general FeatureCollection would use either an anyOf or oneOf, with a choice of schema definitions for all types with identity. Cases in which an object is valid against more than one of these definitions can be problematic:
anyOf seems to be the better choice between the two evils. Right now I do not see a different solution for a general FeatureCollection, but am open for suggestions.
performance
Not sure how performant the validation against the general FeatureCollection would be in practice, in case of a large or complex application schema. Then again, validation time may not be that critical to an application that wants to ensure that data within a collection is valid.
abstract types
It is unclear if collection definitions should be created for or include abstract types. It may be useful to create such definitions for "uniform" collections of abstract types, even if that implies that actual collections may have objects of different subtypes of the abstract type. Definitions for abstract types should not be included in the general FeatureCollection.
base schemas
Another aspect is which base schema to use for the collections. GeoJSON and JSON-FG both define schemas for feature collections (see https://geojson.org/schema/FeatureCollection.json and https://github.com/opengeospatial/ogc-feat-geo-json/blob/main/core/schemas/featurecollection.json). These schemas should be used as base in according encodings. But what about the plain JSON encoding? I suggest to simply use a JSON array for encoding a collection in a plain JSON encoding.
requirements classes
We could define requirements for the generation in the three encoding requirements classes. However, it may be better to create additional requirements classes that depend on them, since communities may want to create different schema definitions for collections. We may even have separate requirements classes for uniform collections and the general collection, since communities may or may not want to use both types of collections.