Enable using the Type API instead of Cordra to get a profiles JSON Schema.

[Pfeil]

Currently, we get the Schemas for the types from Cordra directly. There is a Type API available which we should consider supporting: http://typeapi.pidconsortium.net/docs#/

Introducing a configuration option to choose one of the ways to do it should be considered.

[DevPJ9]

Hello @Pfeil I would like to work on this.

[Pfeil]

Hi, thank you for your interest.

I haven't put a lot of effort into this issue so far, but I think before this can be implemented, it needs some refactoring in the validation architecture, as the Type API is involved in validation of PID Records. After some refactoring, this issue can actually be worked on. You may choose to do so, but actually I do not yet have a good/final plan.

To see which parts are currently doing validation, you may follow the call of the "create" REST endpoint. You will see that Validation mainly involves the TypeValidationUtils, TypeDefinition, PIDRecord, and the TypeRegistry classes.

I think what we require is an interface ValidationInfoProvider which represents different sources of validation information. Each ValidationInfoProvider should be able to execute a ValidationStrategy (currently implemented as a simple function), as we want to be able to have different ways/constraints/levels for validation. So far, I would assume that Provider and Strategy are selected by configuration, not at runtime (e.g., via different REST endpoints).

The new API then would be a new ValidationInfoProvider Implementation with the same strategy as the current one (see executeValidationStrategy).

This is probably the issue with most work to do, so far :). Do you have a special interest in the Typed PID Maker or a personal need/priority on this issue?

[Lienhop]

Hi @Pfeil. We are currently fully reworking the TypeAPI, so if there are any features you would like to have included there, let us know!

[Pfeil]

Hi, thank you for the hint! I guess this is also an indicator to wait with this issue a little until this is done. :) Currently, I do not have additional feature requests or suggestions, but I will keep it in mind. Some minor comments on the current API:

• Having a version-scoped API sooner or later would be great (like, api/v1/dtype/... or so. This way you can change the API without breaking current user's implementations :) )
• So far, we only need the JSON-Schema representation of a profile (or its types; currently we validate each type and check the profile information using the given DTR representation). Any other format with good validation tooling will also work, but I guess JSON Schema is the best choice here.