Change Details

** Done when ** [x] Definitions changed in function-schemata. [x] Validation schema changed in function-schemata. [ ] Orchestrator (and its built-in validators) changed over. The suggestion is to change the signature of validators from taking the type being validated and returning a list of errors to taking a type and returning the same type. A validator would return a valid value unchanged, whereas in the case of an invalid value it would raise errors (an error representing a list of errors, if needed). This has the following advantages: * We have more control about when to validate in compositions. There are some functions, such as Z808/abstract, which create objects that might potentially have issues. By being able to use validation like a pipe, we can use it freely in implementations and capture errors sooner. Otherwise the orchestrator might need to use validators more frequently than really needed. * Returning errors might be difficult and become even more difficult with the changes to the error system. By pushing the errors to the error value, they become easier to handle. * It becomes easier to pipe validators together with other calls in all kind of circumstances.

This is **done when**: [x] Definitions changed in function-schemata. [x] Validation schema changed in function-schemata. [ ] Orchestrator (and its built-in validators) changed over. The suggestion is to change the signature of validators from taking the type being validated and returning a list of errors to taking a type and returning the same type. A validator would return a valid value unchanged, whereas in the case of an invalid value it would raise errors (an error representing a list of errors, if needed). This has the following advantages: * We have more control about when to validate in compositions. There are some functions, such as Z808/abstract, which create objects that might potentially have issues. By being able to use validation like a pipe, we can use it freely in implementations and capture errors sooner. Otherwise the orchestrator might need to use validators more frequently than really needed. * Returning errors might be difficult and become even more difficult with the changes to the error system. By pushing the errors to the error value, they become easier to handle. * It becomes easier to pipe validators together with other calls in all kind of circumstances.

** DThis is **done when ****: [x] Definitions changed in function-schemata. [x] Validation schema changed in function-schemata. [ ] Orchestrator (and its built-in validators) changed over. The suggestion is to change the signature of validators from taking the type being validated and returning a list of errors to taking a type and returning the same type. A validator would return a valid value unchanged, whereas in the case of an invalid value it would raise errors (an error representing a list of errors, if needed). This has the following advantages: * We have more control about when to validate in compositions. There are some functions, such as Z808/abstract, which create objects that might potentially have issues. By being able to use validation like a pipe, we can use it freely in implementations and capture errors sooner. Otherwise the orchestrator might need to use validators more frequently than really needed. * Returning errors might be difficult and become even more difficult with the changes to the error system. By pushing the errors to the error value, they become easier to handle. * It becomes easier to pipe validators together with other calls in all kind of circumstances.