Should User Allowed to Create Invalid Contract Definitions?

[harnvo]

My Question

Here invalid means a contract definition referring to assets/policies that does not even exist.

It seems connector does not check if assets/policies actually exists, and this could confuse users when they have a typo when creating a contract definition.

Is this feature implemented on purpose? Or it would be better to validate contract definition upon contract definition&assetId&policyId updates?

[jimmarino]

Assets existing and policies are two separate things.

It is a design decision allow contract definitions (and policies) to exist before assets for top-down scenarios where the roles of a "data officer" and "asset owner" are independent. Please read up on the concept of asset selectors and the indirection they apply to contract definitions and assets.

[harnvo]

It is a design decision allow contract definitions (and policies) to exist before assets for top-down scenarios where the roles of a "data officer" and "asset owner" are independent.

I see a rationale for creating contract definition before assets. But connector also allows creating contract definition before creating a policy.

To my own understanding, it is unreasonable to create any contract definition without knowing what the policy would look like. Are there any possible scenerio where we actually need this feature?

[paullatzelsperger]

I would turn the question around in asking "what would we gain from imposing that restriction"? In other words, what exactly is your use case for requiring policies to be there? A person manually creating CDs, assets, policies is not the typical scenario, so that's not a good enough reason IMO.
This would create a considerable validation, testing effort, it would potentially break downstream projects and samples, so there would have to be a very good reason.

[harnvo]

I would turn the question around in asking "what would we gain from imposing that requirement"?

I agree that imposing the requirement in a upsteam project is not worst the effort. But I believe there should be an easy way to optionally validate CDs (and it don't have to be in this project).

Maybe I should change my question: Is it possible for a downstram project to write a simple custom extension for validating some requirement regarding CDs?

In other words, what exactly is your use case for requiring policies to be there?

IMO, there should not exist an opportunity for a potential misuse. Having a invalid CD would work, and data transfer would continue as if there are no policy constraints. This would only occure with some silly mistakes but it seems the consequence is not acceptable as data transfers would go in an automated way in real-world applications.

[paullatzelsperger]

Maybe I should change my question: Is it possible for a downstram project to write a simple custom extension for validating some requirement regarding CDs?

yes it is. it's possible to contribute/replace validation upon API ingress through an extension. I recommend looking at the JsonObjectValidatorRegistry, and its use in the ContractDefinitionApiExtension

Alternatively, you can register custom interceptors for the ContractDefinition API and plug your custom validation in there.