ZedVal architectural overview

Version 1.0.0 — James Pritchett & Markus Gylling, 21 July 2003

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:
  3. Application locates and loads the test map and processor map
  4. Application initializes its output
  5. Application filters the test list to remove all inapplicable tests
  6. Application instantiates TestProcessor objects based on collation of ProcessorMap data and filtered test list.
  7. Each TestProcessor in turn executes its tests.
  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).