The AKOMA NTOSO document model is designed, first and foremost, to be actually used. As a consequence, a high premium has been placed on simplicity throughout its design. Data models created to handle complex document types (as legislation) need to deal with two apparently opposed requirements: on the one hand, they need to be sufficiently sophisticated to handle all possible occurrences and situations that may occur in the actual documents. On the other, they need to be speedily understood and used by the people who would need to apply these models.

These opposed requirements can be jointly satisfied not by simplifying the vocabularies of available structures and elements, which would reduce the available descriptive sophistication of the language, but rather by simplifying the structure variability and types (in XML parlance, the content models), thereby reducing the learning time and the software complexity without compromising a full and detailed descriptive power of the language. The idea therefore is to identify a number of basic, fundamental classes of structures (containers, hierarchies, blocks, etc.) that can be immediately understood and used appropriately, regardless of their actual names.

Validation is the act of checking the correctness of an XML document according to some pre-defined structural rules expressed in one or more DTDs and XML Schemas. The validation step verifies whether the XML document contains, in number and position, all the expected elements of the type this document is an instance of. The AKOMA NTOSO schema could impose a number of constraints and restrictions on the final form of the XML document, requiring for instance a specific order in the containment of parts or that any part is preceded by a heading, etc.

The problem with being too restrictive in the constraints of the schema is that, e.g. the Parliaments may have approved, and may decide to approve in the future, documents that do not conform to these rules: in most countries there are guidelines for the correct drafting of legislation, but this is just what they are: guidelines, that can be ignored and modified at will by a higher authority such as a Parliament or Court.

This fact has a very important effect on the generation of XML versions of documents: everything that gets approved by Parliaments or written by Courts has to be accepted by the system, and everything that has already been approved even more so. Therefore, failing XML validation (i.e., violating one or more of the constraints and restrictions expressed in the schemas) cannot have the effect of rejecting documents, but, at most, of pointing out issues and differences from the guidelines that the authority itself, if it wants and has time to spend on this, can consider for editing and modifications.

In reality there are two different actors in the complex issue of validating a piece of legislation: the legislator, who is writing the actual content of the document, and the marker, who is converting it into XML by identifying all interesting bits of the text and correctly marking them up using the AKOMA NTOSO vocabulary.

If we consider the validation schema a contract, then this contract clearly binds only the marker, leaving the legislator/judge absolutely free to do as he/she chooses. Thus compliance to rules such as "An identifier will always be added to each substructure of the act" or "The enactment date will be specified" can be safely required, as they bind the behaviour of the marker only, while structural rules (such as "Every subpart will have a heading", or "A section will contain paragraphs which contain clauses") cannot be imposed, as they would interfere with the authority and independence of the legislator, which in the case of Parliaments  is most often complete and not constrainable by more mundane requirements such as the adherence to an abstract document structure.

Forcing markers to fully describe in XML all document parts, and yet leaving to the legislator the maximum freedom in writing, may seem incompatible and hard-to-reach goals, but they can be and are reached in the AKOMA NTOSO framework. AKOMA NTOSO clearly separates data and metadata, thereby clearly distinguishing the contribution of the legislator (data) and the contribution of the marker (metadata); AKOMA NTOSO provides a richly evocative vocabulary of structures and elements, so that the marker can correctly and precisely describe what is actually contained in the documents. AKOMA NTOSO imposes little or no constraints on data, letting the legislator write and organize the text matter as he wishes, but imposes a number of constraints on the metadata, forcing the marker of texts to provide all bits of information that are necessary to manage and organize the documents.

Yet it might be appropriate to also give guidance and help in following the drafting guidelines enacted in each country. This is the reason to provide both a General Schema(GS) and several Detailed Schemas (DSs): the GS is fully  descriptive, only binding the marker and not the legislator, but allowing the marker to describe as precisely as possible the actual structure of the document as approved and generated by the Parliament. The DSs are more prescriptive, and are used to check whether the document actually conforms to the existing legal drafting guidelines in each individual country. Successful validation of documents will only be required against the GS, as errors would signal incorrect markup from the marker, while the DSs can be used, at the discretion of the Parliament itself, to automatically check conformance of the proposed bill against the drafting guidelines, and thus be able to modify it accordingly in case conformance is sought.

The descriptive (GS) and prescriptive (DS) schema, of course, are closely related. As mentioned, they both use the same vocabularies, and differ in the number of rules and constraints they enact. All rules enforced in the GS are also enforced in the DSs, so that, correspondingly, all documents that are valid according to one of the DSs  (i.e. are conformant to a set of stricter rules) are also valid according to the GS (i.e., they are also conformant to the set of shallower rules).

Furthermore, this pair of schema classes also allows interoperability of systems dealing with documents coming from different African countries. In fact the descriptive GS schema can work on all AKOMA NTOSO documents of all the interested African countries, and can be used as the baseline for accessing and displaying documents regardless of their provenance.

On the other hand each prescriptive DS schema is created to deal with the specific guidelines of each individual country, helping the legal drafting process and the correct preservation of cultural peculiarities of each individual country. The fundamental commonality of GS and DSs provides therefore full description of individual and country-specific document types without renouncing interoperability and document interchange.

Just as many are the users (some of whom are not even aware of the fact they are using or relying on AKOMA NTOSO-compatible systems), many also are the tools that will be created around the AKOMA NTOSO document model. Some of them are basic tools that are necessary for the AKOMA NTOSO system to work at all. Others are additional applications that will be created once the basic tasks have been catered for.

Although this is not the place to provide a full list of the foreseeable tools, a brief list of the main categories may help in explaining the breadth and variety of the AKOMA NTOSO project, and the number of issues that need to be considered in the development of the data formats.

Post-editing tools