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