ZedVal architectural overview

Basic concepts

File

A component part of a DTB. Types include XML files (package, NCX, SMIL, text, resource), audio files (MP3, AAC, WAV), image files (JPEG, PNG, SVG).

Test

A single validation test, expressed as a question about a single file. A test is applicable to one or more DTB multimedia types.

Test Processor

An object that performs one or more tests upon all instances of a particular class of file. Test processor are classified by the means by which they perform tests: DTDs, RelaxNG schemas, XSLT stylesheets, custom Java code. Test processors send messages (see next) in the case of errors or test failures.

Message

An output from the validator. Types include test failure messages, test processor error messages, and application error messages.

High-level components

Test Map

The list of all tests that can be performed.
A description of the Test Map grammar details are found in the top comment of the Test Map itself.

ZedVal engine (core)

Collection of objects that represent files, tests, test processors, and messages in a generic way. The ZedVal engine does not know anything about the content of tests. It does understand the fundamental structure of a Zed DTB.

Test processor suite (ZedSuite)

A set of actual test implementations. The ZedSuite exists as a collection of test processing resources and a test processor map (see next). The test processor suite is built based upon a specific test map.

Test processing resource

A specific document or object that is used by a test processor to perform one or more tests. These include DTDs, RelaxNG schema documents, XSLT stylesheets, and Java classes. The actual test evaluation logic is completely contained in the test.
The RelaxNG, XSLT and Java class test processors are used with a cascading rule; an XSLT test is only done if RelaxNG schema could not implement it, and a java class test is only done if XSLT could not implement it. As schema languages develop, more and more tests will be located in the lower regions of the cascade.

Test processor map (ProcessorMap)

A list of all the test processing resources in a particular ZedSuite, identifying which tests (from the Test Map) each resource implements.

ZedVal application

The actual validating application run by the user. The ZedVal application controls the overall program flow, the identification of inputs (DTBs, the test map, the processor map, the processor suite), the production of outputs (via the ZedReporter interface), and all other aspects of the user interface.

High-level program flow

1. Application started; reads command line arguments, etc.
2. Application locates and loads package file. This:
   • Parses the file and determines well-formedness
   • Stores some fundamental metadata values (uid, title, etc.)
   • Instantiates & initializes objects representing each file in the manifest
   • Builds lists of all the different types of files in the package
3. Application locates and loads the test map and processor map
   • Both maps are stored internally as DOM trees
4. Application initializes its output
   • Output is entirely handled by an implementation of the ZedReporter interface
   • ZedVal application has a default ZedReporter, but user can override via command line option
5. Application filters the test list to remove all inapplicable tests
   • Filters out tests that do not apply to the target DTB multimedia type
   • Filters out tests that apply to file types not used in the target DTB
   • Filters out recommendations if user indicates via command line option
6. Application instantiates TestProcessor objects based on collation of ProcessorMap data and filtered test list.
7. Each TestProcessor in turn executes its tests.
   • TestProcessor is passed the test processing resource used, a list of all files of the type it handles, and a list of all applicable tests implemented by the test processing resource.
   • The TestProcessor sets up the test processing resource.
   • The TestProcessor iterates over the list of files, executing the resource on each file in turn. If it cannot execute the resource, it sends a test processor error message to the reporter.
   • The TestProcessor creates messages to send to the ZedReporter, as needed.
8. Application closes output and exits

Flexibility, extensibility, adaptability

When the Zed spec changes the fundamental structure of a DTB ...

... it will require changes to the core engine classes (e.g., if additional media types are allowed).

When the Zed spec changes a requirement ...

... it will require the modification, removal, or addition of a test, and/or the associated modification of the test processing resource that implements that test.

If someone wants to add some tests ...

... they need only add them to the TestMap, write one or more test processing resources that implement them, and add these resources to the ProcessorMap.

If someone wants to subset the tests ...

... they need only remove the references from the processor map.

If a bug is found in a test implementation ...

... then only the test processing resource needs to be modified

If someone wants to use a different output report format ...

... then they need only write an implementation of the Java ZedReporter interface and identify it on the command line.

If someone wants to write an entirely different user interface for ZedVal ...

... then they need to write a new ZedVal application wrapper (ZedVal, ZedReporter, and possibly ZedContext classes).