Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Well, this turned out to be more a flow chart than a simple definition of roles... it may change considerably during implementation, but it looks like a starting point to me.

...

  • 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)
  • Scan user-provided properties
  • 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.