I want to enforce input validation outside of individual client systems. This is related to the Content modeling use case.

This validation may include constraints for property domain and range, cardinality, uniqueness, etc.

Range validation should include both data types for literal properties and class constraints for in-repo resource properties.

Examples

• Restrict the “myns:created” property to xsd:dateTime;

• Restrict the “myns:hasInstance” property to resources of type “myns:Instance” or its subtypes (structural validation);

• Make myns:createdDate single-valued (i.e. cardinality = 0..1)

• Make myns:uid mandatory and single-valued (i.e. cardinality = 1..1)

• Inherit property constraints from super-types
  • type myns:Document has a property definition for myns:uid as mandatory and myns:content as single-valued
  • type myns:TextDocument inherits these definitions
  • type myns:ImageDocument inherits myns:uid but overrides myns:content to being multi-valued
• Ensure that no two resources with the same myns:uid are present in the repository (similar to a unique key constraint in a relational database)

Roles of the API Extension Architecture configuration

• Define HTTP methods that the Validation extension operates on
• Enable/disable and define execution priority of Validation service (e.g. pipeline)

Roles of the API Extension engine

• Forward data from user request or previous services
• Handle response from Validation extension and forward to further services

Roles of the Validation extension configuration

• Define content models which validation is performed on
  • For each model, define properties to be validated
  • For each property, define:
    • validation rules
    • RDF type of the resource or container that should be validated (optional)
    • Post-success actions (i.e. services to be called if all property values pass validation) (optional)
    • Post-failure actions (i.e. services to be called if any property value fails validation) (optional)

Roles of the Validation extension engine

• Parse input from API-X engine and determine content model(s) of resource
• Parse configuration for content model(s)
• If RDF type restriction (see point in config roles) are defined, query repo index to determine if the resource if its container are of the RDF type specified in the config
• Loop over property validation rules in config file:
  
  • If an RDF type restriction (see point in config roles) is defined, query repo or index to determine if the resource or its container are of the RDF type specified in the config
    • If result is positive, apply validation rule against user-provided property value(s)
    • If negative, skip validation
  • If no RDF type restriction is defined, apply validation
  • If validation passes:
    • if a post-success action is defined, execute it
    • if no post-success action is defined, move on to next rule
  • If validation fails:
    
    • if a post-failure action is defined, execute it
    • if no post-failure action is defined, abort whole process and raise an exception
• After all rules have been parsed, return to API-X engine

Note

Due to the long discussion in the comments, this use case has been split into three child pages. See links below.