# EMF Validation Framework Overview

The validation framework provides support for constraint providers for any EMF meta-model (batch and live constraints), customizable model traversal algorithms, constraint parsing for languages, configurable constraint bindings to application contexts and validation listeners. The following are the main extension points and classes to be used with the validation framework.

1. The extension point org.eclipse.emf.validation.constraintProviders is used to provide constraints. Static constraint providers declare constraints in the plugin.xml. Constraints are grouped into hierarchically structured categories. Constraint providers target one or more EPackages by namespace URI. A group of constraints declares categories in which they are members. Each constraint has a variety of meta-data associated with it (Language, ID, severity, mode, name, message, triggers, etc.). Dynamic constraint providers address situations where constraints cannot be declared statically. e.g., where constraints are defined in models or other resources. Dynamic providers declare a class implementing the `IModelConstraintProvider` interface. This class is responsible for making constraints available on the appropriate triggers, organizing them into categories, etc.
2. The extension point org.eclipse.emf.validation.traversal is used to provide customizable model traversal algorithms. Batch validation traverses a subset of the model starting from the user's selections. No traversal is performed in live validation. Some meta-models require custom strategies for traversal. The default strategy simply iterates the content tree via `eAllContents()` API. Some meta-models do not use EMF containment relationships extensively, or implement logical models on multiple distinct resources, making containment-based traversal impractical.
3. The extension point org.eclipse.emf.validation.constraintParsers is used to provide constraint parsing for languages. The validation framework provides support for two languages: Java and OCL. Clients can provide support for other constraint languages via constraint parsers. The `Language ID`: used in the `lang` attribute of constraint elements in the constraint XML. The `Class`: identifies an implementation of the `IXmlConstraintParser` interface, which constructs a constraint from the XML configuration data. Constraint parsers are responsible for parsing the content of a constraint element in the plugin.xml to produce `IModelConstraint` objects.
4. The extension point org.eclipse.emf.validation.constraintBindings allows clients of the EMF Validation framework to define "client contexts" that describe the objects that they are interested in validating, and to bind them to constraints that they are interested in enforcing on these objects. A client context can declare an `enablement` expression that matches model elements that are included in the context. Where that is not sufficient, an alternative is to define a selector class using a `selector` element. Client contexts can be bound to constraints, individually, or to constraint categories (to bind all of the constraints in the category). Binding to constraint categories has the advantage of allowing new constraint contributions in a category to automatically be bound to the appropriate client context, even if the constraint is defined in a plug-in that is unaware of that context or its binding to the category. Category bindings are inherited by sub-categories from their ancestors.
5. The extension point org.eclipse.emf.validation.validationListeners is used to define validation listeners for the validation service (`org.eclipse.emf.validation.service.ModelValidationService`). The validation service will inform this listener whenever validation has occurred, loading it if necessary in order to do so. This is most useful for cases where client plug-ins need to find out about validation events even before they are loaded. Otherwise, it is usually simpler just to programmatically add a listener to the validation service. The value of the `listener` element class attribute must be the fully qualified name of a class that implements the `IValidationListener` interface. Listeners can also be registered in code, at run-time, using the `ModelValidationService.addValidationListener()` method.
6. The `ModelValidationService` singleton coordinates the invocation of validation. It defines a single factory method for creation of `IValidator` for the batch and live evaluation modes. Validators validate one or more objects at a time; the kind of object accepted as input depends on the evaluation mode. They can be configured to report constraint passes as well as failures, for verbose results. Results are reported as `IValidationStatus`. Validators can be reused by a client for any number of validation operations. The `ILiveValidator` validates EMF `Notifications`. The `IBatchValidator` validates `EObjects` and, due to its support for model traversal, supports progress monitors. Registered traversal strategies can be overridden by the client.
7. Clients can create an `EValidator` implementation that delegates to the validation framework.
8. The framework provides implementation of an XML constraint parser (`org.eclipse.emf.validation.xml.IXmlConstraintParser`) API that supports definition of XML constraints in OCL. The class `OclConstraintParser` is the constraint parser implementation that creates instances of the `OclModelConstraint` class, the OCL-language constraint implementation, from XML constraint descriptors. It uses the `Query` class to test model elements against an OCL constraint expression.

Please refer to the tutorials Validation Tutorial, Validation Adapter Tutorial and OCL Validation Tutorial for reviewing some code samples.

Copyright (c) 2000,2005 IBM Corporation and others. All Rights Reserved.