Is your feature request related to a problem? Please describe.
Resolving a PID with e.g. /api/v1/pit/pid/21.11152/474a4b1c-de93-4d4a-b33d-1d32d63baf4b?validation=true will fail because the record will contain a URL field.
This is because the URL field is currently considered interesting, and is returned by the HandleProcotol wrapper in the Typed PID Maker.
Describe the solution you'd like / consider
Either
a) make sure such fields are never returned
b) make sure such fields (which are not resolveable but part of the provider) are ignored while validation (at least when validating-on-resolution)
To be honest, b) sounds like it would complicate things. But we will need to discuss it.
Additional context
Searching for the PID will (as soon as the according branch is merged, which will soon be the case) lead you to a test case which can easily be modified to reproduce and analyze the issue.
Is your feature request related to a problem? Please describe.
Resolving a PID with e.g.
/api/v1/pit/pid/21.11152/474a4b1c-de93-4d4a-b33d-1d32d63baf4b?validation=truewill fail because the record will contain a URL field.This is because the URL field is currently considered interesting, and is returned by the HandleProcotol wrapper in the Typed PID Maker.
Describe the solution you'd like / consider
Either
a) make sure such fields are never returned
b) make sure such fields (which are not resolveable but part of the provider) are ignored while validation (at least when validating-on-resolution)
To be honest, b) sounds like it would complicate things. But we will need to discuss it.
Additional context
Searching for the PID will (as soon as the according branch is merged, which will soon be the case) lead you to a test case which can easily be modified to reproduce and analyze the issue.