The semi-public (internal-public) package defining the API for invocation of the validation engine and for the implementation of constraint providers.

## Package Specification

This package defines the API for the client and provider sides of the "validation service." The main types involved are:

- {@link org.eclipse.emf.validation.service.ModelValidationService}: a singleton that provides clients of the validation engine with access to validators implementing batch or live mode validation
- {@link org.eclipse.emf.validation.service.IValidator}: the common interface of objects that perform the validation operation; its sub-interface define the contract for the batch and live modes of validation. The validators are the objects that clients of the validation service invoke to test their models
- {@link org.eclipse.emf.validation.service.IModelConstraintProvider}: the interface implemented by any class that provides constraints to the system. Constraints defined in plug-in manifests are provided by the pre-defined {@link org.eclipse.emf.validation.xml.XmlConstraintProvider}. Dynamic constraint providers typically implement this interface by extending the {@link org.eclipse.emf.validation.service.AbstractConstraintProvider} class.

Some supporting types provide additional functionality and/or controls on the validation engine:

- {@link org.eclipse.emf.validation.service.IConstraintDescriptor}: provides the validation engine with various meta-data about a constraint, to help it decide:
  - when the constraint should be invoked (the "triggers"). This enables deferred loading of the plug-ins that define constraints (in the case of the XML constraint provider. It is also possible that a dynamic provider may reside in a different plug-in from the constraints that it makes available to the system; at least, the loading of constraint implementation classes can be deferred)
  - whether it is safe to invoke a constraint. Constraints that fail on run-time exceptions (so-called "errored" constraints) are removed from the validation engine for safety's sake; the descriptor retains the exception that caused the failure
  - severity of the constraints (error/warning/etc.) and other information such as name and description that are primarily for presentation in the UI
- {@link org.eclipse.emf.validation.service.ConstraintRegistry}: keeps track of all constraint descriptors in the system, ensuring that they are unique. It is available to constraint providers and clients of the validation engine to look up constraint descriptors by the constraints' IDs, for "introspection" of the constraints in the system
- {@link org.eclipse.emf.validation.service.ITraversalStrategy}: supports the special traversal algorithms required by some EMF meta-models where the default containment-tree iteration is not sufficient or optimal. Used by {@link org.eclipse.emf.validation.service.IBatchValidator}s