Validation Requirements

One important requirement was to validate a TTML XML document against different sets of conformance rules without duplicating the implementation effort, another that the end user should only get one error message when the same rule of different specifications was broken. On top of that, the implementation of the software architecture was also guided by a number of non-functional requirements.

Team Expertise

The choice of technologies had to reflect the expertise available in the technical teams. For example, the IRT team worked intensively with XSLT, Schematron and W3C XML Schema but less with XQuery or Relax NG.

Deployment of Technologies

The technologies used needed to be widely deployed because it had to be possible to integrate the solution into different system environments.


We believed and still believe in the power of XML technologies. The cooperation of communities responsible for different XML technologies resulted in well-aligned XML technologies like XPath, XSLT, XQuery, Schematron and XPROC. We therefore wanted to use XML technologies wherever possible.

Separation of Concerns

We favoured a design approach with a framework of loosely coupled components that communicate over an agreed API. This way, different stakeholder groups can work on different parts of the framework without interfering with the work of other stakeholders.

We identified three different stakeholder groups:

End user Requirements

Existing validation strategies often come with very technical result messages, but users are often not technical. Even if they are, they may not be familiar with an XML schema technology or XML at all. Therefore, the validation should give information in an understandable way. The information should highlight not only what is wrong but also WHY something is wrong and how to correct it. It should enable the user to trace back the error to the documentation of a rule in the specification.

Product View

From the commercial side, some components needed to be integrated separately into different products. Different developer teams needed to work independently from each other.