| Title (Goal) | Optional content and structural validation |
|---|---|
| Primary Actor | Information architect, developer |
| Scope | Component |
| Level | Summary |
| Author | Stefano Cossu |
| Story (A paragraph or two describing what happens) | Make validation optional for some or all properties |
This use case exemplifies a repository in which the API-X server should issue a warning, or otherwise modify a resource in a way that does not prevent its being persisted in Fedora, if some validation rules are not met.
See Enforce validation across repository and AIC Use Case: Content and Structural Validation for more detailed examples of validation rule enforcement.
Example 1: all rules optional
- User uploads image file and metadata to create a new resource of type
cma:Image - Validation rules for
cma:Imageindicate that a resource SHOULD have at least onemyns:creatorproperty - If user-provided metadata do not include a
myns:creatorproperty, the validation engine forwards the request to a special process to handle the request. This process can perform any of the following actions:- Simply forward the request to Fedora or a pre-ingest pipeline as if validation passed
- Forward the request, and return the subsequent request headers and body with additional headers or body issuing a warning that a certain validation rule did not pass
- Modify the resource, e.g. by adding a
myns:Orphantype to the resource so as to indicate that the creator property did not pass optional validation.
- If user-provided metadata include a
myns:creatorproperty, 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: Some rules optional
Assuming the same validation rules and ingest scenario as Example 1:
- In addition to a
myns:creatorrecommended property, the image MUST have amyns:uidproperty - If the request does not include a valid
myns:uidproperty, the request fails and the server returns a 4XX response explaining the reason for the failure - If the request includes a valid
myns:uidproperty, steps 3. and 4. in example ones are applied
Personal consideration: this scenario may actually be merged with the Enforce validation across repository one. Instead of distinguishing between mandatory and optional rules, the configuration may indicate what to do if a validation rule does not pass (possibly making a 4XX response the default). This allows for a flexible combination of mandatory and recommended rules.
4 Comments
Stefano Cossu
Elliot Metsger, please feel free to add to or edit this page, in case I missed something in your use case description.
Elliot Metsger
My only clarifying comment is that I'd like to be able to apply Example 1 ("all optional"), Example 2 ("some optional"), or the stricter ("none optional") policies at the "collection" (e.g. Container) level. I think that this use case and the Enforce validation across repository use case captures our discussion quite well. Ah, I see Validation only for selected resources covers this.
I think it would be useful (maybe on the AIC Use Case: Content and Structural Validation page) to enumerate the roles of the Extension architecture and the validation extension itself. I think, though I may be proven wrong, that the roles of the API-X architecture and the role of the Validation extension are the same across all three examples.
Stefano Cossu
Correct. Good idea, I will add that distinction to the parent page.
Stefano Cossu
It might be useful also to define actions for when a recommended validation rule passes. In this case, if a subsequent request added the myns:creator property, the server could remove the myns:Orphan type.