Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

STP Validation Framework

OSGi-based Validation Framework

This is a proposal for a generic, OSGi-based validation framework for use within Eclipse. This proposal is written to solicit additional participation and input from the Eclipse community.

The goal of the validation framework is to provide extensible validation framework - a general architecture where validation providers can register validation implementations that are capable of validating objects of a defined type and report any validation problems through a standardized API validation consumers can look up registered validation providers and use these to validate objects and receive the validation results

It is envisioned that a typical validation implementation will be a general engine for a certain content type (e.g., XML Schema or Relax NG validation for XML documents) that uses an appropriate configuration (e.g., an XML-Schema-Definition or RELAX-NG-Schema) to provide validation services for a particular document type.

This proposal has been inspired by some of the existing validation solutions in Eclipse such as the EMF validation component, the WTP validation framework an others. It does not intend to replace these existing solutions. Its goal is to generalize and extend them to provide a general-purpose solution for a common problem. Its general nature would also allow the integration of existing solutions.

The main improvements that this proposal aims to introduce are

  1. the introduction of a model-agnostic framework so that the validation mechanisms can be re-used as widely as possible
  2. a common interface for calling validation providers and receiving validation reports so that validation providers and consumers can be implemented independently and re-used widely
  3. the ability to validate the same document with multiple validation engines with one call (“chained validation”)
  4. a nested context model to handle references from a validated object to external entities (parts of validated entity located separately for simplifying, light-weighting, etc) which are required for the validation process. This provides the ability to validate one object in the context of other objects of potentially different types (“consistency validation”). An example for this is the validation of a WSDL document together with some imported XML Schemas.
  5. a “validator repository” to dynamically register validation providers that can be looked up by validation consumers as needed

The class diagram shows the current draft of the API:

STP ValidationFrameworkProposal-ClassDiagram.png

The short description of interfaces and classes represented on diagram:

  1. IValidationObjectType – describes validated entity types (added for general validators / validated entities categorization)
  2. IValidator – an implementation of this interface validates an entity. A validator loads input entity model through an IValidationContext, traverses the model itself, and reports validation results to the user through the IReporter.
  3. IValidationContext – is the interface for the entity model loading mechanism for the IValidator. The IValidationContext separates the IValidator from its environment; every model that the IValidator validates is retrieved by the IValidationContext implementation. The IValidator asks IValidationContext to retrieve an object, and the validation context knows how to load the object for a particular type of environment. Taking into the account that validated entity can reference on other entities, the IValidationContext has methods for operating with nested contexts.
  4. IValidationObject – is the interface for accessing data stream of the validation entities. Each validation object is unique in the scope of the actual context.
  5. IValidationObjectID – is identification information about validated entities. Serves to lookup nested (dependent) validation contexts possible required by the validator. Consists of unique in the actual context identifier of validated entity and validated entity type.
  6. IReporter – is the interface through which the IValidation interacts with the user to report validation problems. Each IReporter implementation is customized for a particular environment: it can save validation messages into report file; represent them in GUI, send via network or store into database. Implementation of IReporter for Eclipse Environment will represent validation messages via the Eclipse Problems View.
  7. IMessage – is the Locale-independent message that the IValidation uses to report a problem to the user providing detailed info about problem location and severity.
  8. ILocation – is the interface for problem location description. Possible extensions are can contain for example line number, offset and length for text presentation of XML document, xPath for DOM model, etc.
  9. ValidationRunner – the implementation of IValidator interface for composite validator which allows performing chained validation.
  10. IValidationFactory – the interface for factory to obtain specific validator implementation (by actefact type) and all supported validation entity types. There is also possibility to organize performing sequential validation by several different validators in one call by ValidationRunner. By introducing interface for validation factory there is ability provided to platform specific implementation (even without OSGi background)

The following code snippet shows how the proposed API could be used to validate a String object.

public void _valbyall(final String validatorType, final String validationString) throws Exception {
  if (null == validatorType || 0 == validatorType.length() || null == validationString || 0 == validationString.length()) {
    System.out.println("validator type and string to validate should be specified exactly.");
    return;
  }

  IValidationFactory osgiValidationFactory = getValidationFactory();
  if (null == osgiValidationFactory) {
    System.out.println("OSGi Validation Factory is not available.");
    return;
  }

  Collection<IValidator> validators = osgiValidationFactory.getAvailableValidators(buildValidationObjectType(validatorType));
  if (validators.isEmpty()) {
  System.out.println("validation framework does not provide validation of type [" + validatorType +"].");
  } else {
    IValidator validator = osgiValidationFactory.getValidationRunner(new ArrayList<IValidator>(validators), true);
    MemoryReporter reporter = new MemoryReporter();

    validator.validate(buildValidationContext(validatorType, validationString), reporter);

    printValidationResult(reporter);
  }
}


private void printValidationResult(IReporter reporter) {
  System.out.println("validation " + ((0 == reporter.getErrorsCount()) ? "succesfull" : "failed")
    + ((0 == reporter.getMessages().size()) ? "" : " - additional details:"));
  Iterator<IMessage> it = reporter.getMessages().iterator();
  while (it.hasNext()) {
    System.out.println("\t " + it.next().toString());
  }
} 

We’re currently working on an initial implementation, the current state can be made available under EPL on request.

Gerald.preissler.sopera.de 11:59, 1 February 2008 (EST)

Back to the top