This Pull Request is a suggestion to retrofit (without any changes to CS content) a testing and validation pipeline to improve examples. You will notice the first example we tried had a schema validation failure.
the bblocks set up references the normative artefacts and existing examples - e.g.
manually complete all examples using this pattern for each schema module (unit testing)
choose a set of "super-examples" that transitively test multiple schema components
write a script as a github action to generate the same configuration prior to running validations
Update bblocks-postprocess to traverse custom directory structures better,
Refactor CS repo to be traversable by existing code.
Note that any of these options can be extended to include mappings to RDF ontologies, as per SOSA baseline, which then allow much richer validation based on data content - e.g. making sure values exist in either a collection or items.
Once this testing is in place several other things are possible:
High quality examples
Set up of CS profiling approaches that inherit all tests from the main CS specification
Provision of validation services for compliance
Regression testing, allowing refactoring of CS to adopt (or promote) non-CS specific implementation patterns to resuable BuildingBlock registry.
If CS adopts at least basic validation processes, the COSI team is willing and able to support a process of deduplication of common patterns. This should avoid delays arguing or analysing implications of overlaps and duplications with existing OGC API standards - as it will reuse things. Deduplication also reduces the total amount of material requiring review.
(Note that if there is a valid reason to bundle all schemas into a directory tree - e.g. zip up a package for offline usage) - then the normative references to common solutions could be traversed to compile a bundle automatically. )
This Pull Request is a suggestion to retrofit (without any changes to CS content) a testing and validation pipeline to improve examples. You will notice the first example we tried had a schema validation failure.
the bblocks set up references the normative artefacts and existing examples - e.g.
"schema": "../../../../../api/part1/openapi/schemas/sensorml/deployment.json"five options to complete testing setup:
Note that any of these options can be extended to include mappings to RDF ontologies, as per SOSA baseline, which then allow much richer validation based on data content - e.g. making sure values exist in either a collection or items.
Once this testing is in place several other things are possible:
If CS adopts at least basic validation processes, the COSI team is willing and able to support a process of deduplication of common patterns. This should avoid delays arguing or analysing implications of overlaps and duplications with existing OGC API standards - as it will reuse things. Deduplication also reduces the total amount of material requiring review.
(Note that if there is a valid reason to bundle all schemas into a directory tree - e.g. zip up a package for offline usage) - then the normative references to common solutions could be traversed to compile a bundle automatically. )