Declaratively specify validation rules on a per-type basis, using an API similar to that of authorization rules. Execute rules on fact creation on both the client and the server such that j.fact throws immediately upon creating an invalid fact, and server responds with a 400 BAD REQUEST.
Also execute rules on the server when responding to load. Filter any invalid facts and their successors out of the response. This will eliminate facts that were saved under looser validation rules. An audit capability (defined in a different issue) will find circumstances in which validation rules have been tightened.
Validation rules will include checks for the following:
A field is required, and has the specified primitive type
A predecessor is required, and has the specified cardinality and fact type
No additional fields or predecessors are provided
Provide a mechanism for conditional validations. For example, if a given field or predecessor exists, then use one set of specifications. Or if a given field has a value that matches a specified predicate, then use one set of specifications. Otherwise, use another.
Declaratively specify validation rules on a per-type basis, using an API similar to that of authorization rules. Execute rules on fact creation on both the client and the server such that
j.factthrows immediately upon creating an invalid fact, and server responds with a 400BAD REQUEST.Also execute rules on the server when responding to
load. Filter any invalid facts and their successors out of the response. This will eliminate facts that were saved under looser validation rules. An audit capability (defined in a different issue) will find circumstances in which validation rules have been tightened.Validation rules will include checks for the following:
Provide a mechanism for conditional validations. For example, if a given field or predecessor exists, then use one set of specifications. Or if a given field has a value that matches a specified predicate, then use one set of specifications. Otherwise, use another.