-
Notifications
You must be signed in to change notification settings - Fork 52
Open
Description
This topic was raised during the code sprint:
When we are transforming from a more relaxed schema to another more restrictive, it is possible that the result will not be compliant with the output schema, as we are not validating the output.
I took a look on how this could be implemented, and here are my thoughts about it:
- The current
validatecommand is a proxy tovalidate_mcf - I understand that we want to keep
validate_mcf, as it is used in thepygeoapi_plugin - Validation can be useful on its own, not only when transforming
- The commands that accept an MCF as an input are different from the commands that accept metadata in other schemas
The path I am following is:
- Add a
validatemethod toBaseOutputSchema - Add
can_validateto theschema_matrixelements inget_supported_schemas - Add
validateto theschemasclick command fromget_supported_schemas - Modify the
get_supported_schemasto filter by schemas that can validate? - Add a
validateoption to thetransformclick command using the previous filter when calling toget_supported_schemasto build the list of choices - If the option
validateis present, call toschema_object_output.validate(content)intransform_metadata
The questions I have are:
- What to do with
can_validateinget_supported_schemasforinclude_autodetect - Should we add the filter by validate in
get_supported_schemas? - How to generalize the
validateclick command? It seems like a design decision to have differentiated the commands that accept MFC from the ones that accept metadata in other schemas, so a unification might break that principle
I will reference a branch in my fork to show all the details mentioned in this issue.
Metadata
Metadata
Assignees
Labels
No labels