Skip to content
Joel Håkansson edited this page May 9, 2017 · 2 revisions

Phases

The basic process should be as follows:

  • Identifying phase [one or more parts that identify the material to the greatest detail possible]
  • Source validation
  • Transforming phase [a combination of enhancers (E) and converters (C) matching (E*C)+E*]
  • Result validation

Phases overview Phases overview The above image outlines the task system's phases. Note that the only error condition depicted here is when a fix has already been attempted, but the input format is still invalid. Obviously, many other error conditions exist, but these are not included here, because they are on a lower level and irrelevant to the purpose of this image.

In the above process, validation is explicitly included before the source has been altered by the system and at the very end where a result is delivered to the user. Source validation is relevant to the user, as it can be used to avoid potential problems before they enter the system. Result validation is relevant to the user, who might want to know that the result is flawed. In addition to this, validation can also be performed between each of the transformation steps. This can however be time consuming and of limited value to the user.

Caveats: Some identification processes requires detailed processing, pretty much identical to the actual transformation that is to be done if successful. The same can be said about validation. In many cases it would be wasteful to perform the same operations several times. Perhaps a part can include several of these types in one.

Identification Phase

Assumption 1

Identification must be completed before a list of transformation tasks can be assembled (including source validation).

Transformation Phase

Assumption 1

A set of properties can be used to select between several parts that operate with identical input and output formats. These properties must be separate from user provided arguments, as they serve a different purpose.

Example

Assuming, for example, that a DTBook file is identified simply as xml due to the file's extension. In this case, properties provided in the identification phase could be used to describe the difference between xml in general and DTBook:

rootElement=dtbook
rootNamespace=http://www.daisy.org/z3986/2005/dtbook/

This information could consequently be required by any task operating only on DTBook xml.

Assumption 2

User provided arguments can be used to toggle optional steps (e.g. validating an intermediary result) or to qualify or disqualify a specific part for evaluation.

Clone this wiki locally