As we saw in the 
				Parsing Constraints and Queries topic, the  
				
					OCL
				
				Facade provides an API for parsing OCL expressions embedded in models as constraints. 
			
The OCL specification defines a Complete OCL text document with which a UML (or Ecore) metamodel may be completed by providing many complementary constraints and expressions. In this case, the concrete syntax for context declarations indicates the context of constraints, equivalent to their placement in models.
As an example, consider the following Complete OCL document:

The Pivot binding provides a UML-aligned representation and so a Complete OCL document can be parsed to provide a similar Resource to that
					derived from a UML or Ecore metamodel. A 
					Root contains a 
					Model which contains 
					Packages
					and 
					Classes. The complementing Resource from the Complete OCL document is independent of the similarly structured 
					complemented Resource of the completed metamodel.
				
The Pivot binding uses an Xtext parser with a UML-aligned output. The input text is therefore specified by a URI and loaded by the Xtext parser to create a Concrete Syntax Resource. This may then be converted to the Pivot Abstract Syntax Resource. The Abstract Syntax Resource has a conventional Model, Package, Class, Operation hierarchy in order to provide a coherent composition context for the Constraints.
The elements of the independent complementing and complemented Resources are merged within 
					CompleteClasses and
					CompletePackages of the 
					CompleteModel managed behind the OCL facade. 
				
There are therefore two 
					Class objects named 
					Library, one for each Resource. The objects are distinct in so far as they belong to different resources, which can be separately serialized, and in so far as they may appear distinct to OCL expressions that use reflective access. However they are logically merged and the 
					CompleteEnvironment provides utility methods that allow the multiple objects to be accessed as a merged object.
				
The Ecore binding provided an
OCLInputclass to supervise the OCL source text, and the result of parsing the document was aList<Constraint>. p.
The Complete OCL document is a textual Resource with an associated text tooling. The 
					OCL facade provides
					an API to load a Resource from a given 
					URI.
				

The parsed resurce can be traversed in the same way as other EMF resources.

The contents of the Complete OCL document contribute to a 
					CompleteModel that merges all the contributions.
					The contributions can therefore be used as if defined in a primary metamodel.
				

The standard EMF validation makes use of an 
					EValidatorRegistry that maps the URI of an 
					EPackage to the
					derived 
					EValidator that provides the constraints appilcable to the 
					EPackage. If we want to exploit
					additional constraints defined in a Complete OCL document, we must extend the underlying 
					EValidator.
					The 
					ComposedValidator enables multiple 
					EValidator to be composed and to behave as a single
					EValidator. 
					ComposedEValidator.install() replaces the single 
					EValidator by a composite 
					initially containing just the replaced 
					EValidator. A 
					CompleteOCLEObjectValidator provides the additional validation of the given 
					uri and 
					EPackage.
				

The standard 
					Diagnostician does not directly support validation of a 
					Resource.
					MyDiagnostician remedies this deficiency and provides a 
					SubstitutionLabelProvider
					that provides slightly better labels within OCL diagnostics.
				

The source for these examples may be found in the org.eclipse.ocl.examples.xtext.tests plugin in model/parsingDocumentsExample.ocl and in src/org/eclipse/ocl/examples/test/xtext/PivotDocumentationExamples.java.