Constructor for derived classes.

The constructor does nothing.

Derived classes must create ValidatorHandler objects that have null ErrorHandler and null LSResourceResolver.

Sets the ContentHandler which receives the augmented validation result.

When a ContentHandler is specified, a ValidatorHandler will work as a filter and basically copy the incoming events to the specified ContentHandler.

In doing so, a ValidatorHandler may modify the events, for example by adding defaulted attributes.

A ValidatorHandler may buffer events to certain extent, but to allow ValidatorHandler to be used by a parser, the following requirement has to be met.

1. When ContentHandler.startElement(String, String, String, Attributes), ContentHandler.endElement(String, String, String), ContentHandler.startDocument(), or ContentHandler.endDocument() are invoked on a ValidatorHandler, the same method on the user-specified ContentHandler must be invoked for the same event before the callback returns.
2. ValidatorHandler may not introduce new elements that were not present in the input.
3. ValidatorHandler may not remove attributes that were present in the input.

When a callback method on the specified ContentHandler throws an exception, the same exception object must be thrown from the ValidatorHandler. The ErrorHandler should not be notified of such an exception.

This method can be called even during a middle of a validation.

Sets the ErrorHandler to receive errors encountered during the validation.

Error handler can be used to customize the error handling process during a validation. When an ErrorHandler is set, errors found during the validation will be first sent to the ErrorHandler.

The error handler can abort further validation immediately by throwing SAXException from the handler. Or for example it can print an error to the screen and try to continue the validation by returning normally from the ErrorHandler

If any Throwable is thrown from an ErrorHandler, the same Throwable object will be thrown toward the root of the call stack.

ValidatorHandler is not allowed to throw SAXException without first reporting it to ErrorHandler.

When the ErrorHandler is null, the implementation will behave as if the following ErrorHandler is set:

class DraconianErrorHandler implements ErrorHandler {
     public void fatalError( SAXParseException e ) throws SAXException {
         throw e;
     }
     public void error( SAXParseException e ) throws SAXException {
         throw e;
     }
     public void warning( SAXParseException e ) throws SAXException {
         // noop
     }
 }

When a new ValidatorHandler object is created, initially this field is set to null.

Sets the LSResourceResolver to customize resource resolution while in a validation episode.

ValidatorHandler uses a LSResourceResolver when it needs to locate external resources while a validation, although exactly what constitutes "locating external resources" is up to each schema language.

When the LSResourceResolver is null, the implementation will behave as if the following LSResourceResolver is set:

class DumbLSResourceResolver implements LSResourceResolver {
     public LSInput resolveResource(
         String publicId, String systemId, String baseURI) {

         return null; // always return null
     }
 }

If a LSResourceResolver throws a RuntimeException (or instances of its derived classes), then the ValidatorHandler will abort the parsing and the caller of the validate method will receive the same RuntimeException.

When a new ValidatorHandler object is created, initially this field is set to null.

Obtains the TypeInfoProvider implementation of this ValidatorHandler.

The obtained TypeInfoProvider can be queried during a parse to access the type information determined by the validator.

Some schema languages do not define the notion of type, for those languages, this method may not be supported. However, to be compliant with this specification, implementations for W3C XML Schema 1.0 must support this operation.

Look up the value of a feature flag.

The feature name is any fully-qualified URI. It is possible for a ValidatorHandler to recognize a feature name but temporarily be unable to return its value. Some feature values may be available only in specific contexts, such as before, during, or after a validation.

Implementors are free (and encouraged) to invent their own features, using names built on their own URIs.

Set a feature for this ValidatorHandler.

Feature can be used to control the way a ValidatorHandler parses schemas. The feature name is any fully-qualified URI. It is possible for a SchemaFactory to expose a feature value but to be unable to change the current value. Some feature values may be immutable or mutable only in specific contexts, such as before, during, or after a validation.

All implementations are required to support the XMLConstants.FEATURE_SECURE_PROCESSING feature. When the feature is:

• true: the implementation will limit XML processing to conform to implementation limits. Examples include entity expansion limits and XML Schema constructs that would consume large amounts of resources. If XML processing is limited for security reasons, it will be reported via a call to the registered ErrorHandler.fatalError(SAXParseException exception). See setErrorHandler(ErrorHandler errorHandler).
• false: the implementation will processing XML according to the XML specifications without regard to possible implementation limits.

Set the value of a property.

The property name is any fully-qualified URI. It is possible for a ValidatorHandler to recognize a property name but to be unable to change the current value. Some property values may be immutable or mutable only in specific contexts, such as before, during, or after a validation.

ValidatorHandlers are not required to recognize setting any specific property names.

Look up the value of a property.

The property name is any fully-qualified URI. It is possible for a ValidatorHandler to recognize a property name but temporarily be unable to return its value. Some property values may be available only in specific contexts, such as before, during, or after a validation.

ValidatorHandlers are not required to recognize any specific property names.

Implementors are free (and encouraged) to invent their own properties, using names built on their own URIs.