Enforce validation across repository

This use case exemplifies a repository in which validation rules are relied upon for data consistency and validity. Resources that do not conform to the content model and property validation rules are considered invalid and not persisted in the repository. This rule is enforced across the whole repository.

Example 1: Creating a resource

1. User uploads an image file and some metadata to create a resource, specifying that the resource to be created has a cma:Image type.
2. The following CMA validation rules are specified for cma:Image:
   
   1. Uploaded file MUST be a TIFF, PNG, JPEG, or PDF file
   2. It MUST have exactly one myns:uid
   3. It MUST have one or more myns:documentType
   4. It MAY have myns:lightType, myns:viewAngle, myns:specialType attributes
3. If any of these pre-conditions fails, the create operation fails and the server returns a 4XX response explaining the reason for the failure
4. If all pre-conditions are met, the request is forwarded to Fedora or to a pre-ingest pipeline and the server returns the return headers and body of this subsequent request

Example 2: Updating a resource

Assuming that the Example1 returned success  along with the new resource URI,

1. User sends a PUT request with a metadata payload to replace the metadata set for the image in Example 1
2. If metadata does not conform to the validation rules, the resource is not updated and the server returns a 4XX response explaining the reason for the failure
3. If new metadata conform to the validation rules, the request is forwarded to Fedora or a pre-update pipeline and the server returns the return headers and body of this subsequent request

A special case is when validation rules require a property to be set on creation but do not allow updating it (e.g. an UID). Therefore, some validation rules should be able to distinguish between "scenarios" (in this case, create and update would be two different scenarios).

Example 3: Patching a resource

1. User sends a PATCH request with a metadata payload to insert or delete some properties for the image in Example 1
2. If the metadata resulting from the insert/delete action does not conform to the  validation rules, the resource is not updated and the server returns a 4XX response explaining the reason for the failure
3. If the metadata resulting from the insert/delete action conform to the validation rules, the request is forwarded to Fedora or a pre-update pipeline and the server returns the return headers and body of this subsequent request

Example 4: Deleting a resource

1. User sends a DELETE request on conatiner /a
2. Resource /b has a myns:hasReference property pointing to /a/b
3. Resource /c has a myns:hasReference property pointing to /a/b/c
4. Validation rules for content model of /b and /c indicates that it MUST have one and only one myns:hasReference
5. Normally, by deleting /a, Fedora would delete the myns:hasReference property pointing to the deleted resources
6. Since the deletion of /a would make /b and /c invalid according to their validation rules, the delete operation fails and the server returns a 4XX response explaining the reason for the failure

Example 5: Copying a resource

Copying a resource would result in a resource with the same properties as the original one, so in theory the new resource should be valid. However, if uniqueness is required for some properties, the new resource would be invalid. Two possible ways to obviate this would be:

1. Define a pre-validation process that transforms the properties defined as unique
2. Define an action within the validation configuration that indicates what to do when resources with unique property values are copied

Example 6: Moving a resource

TODO: verify what happens to resource references when the referred resource is moved