4 Patterns

Categories of content models is the term used within AKOMA NTOSO to refer to families of elements that share the same conceptual organization of the internals. The AKOMA NTOSO 1.0 Schema uses systematically five categories of content models. This means that all content models and complex types used in the schema follow precisely the form of the relevant category, and all elements can be simply described and treated according to their category rather than individually.

These categories are:

• The markers: markers are content-less elements that are placed here and there in the document and are meaningful for their position, their names and their attributes. Markers are also known as empty elements or milestones. There are two main families of markers in the AKOMA NTOSO schema: placeholders in the text content (e.g., note references) that can appear in any position that also has text, and metadata elements that only appear in some subsection of the <meta> section. IN AKOMA NTOSO, all metadata elements are markers, so that metadata values are not part of the text content of a document, but rather become attribute values.

• The inlines: an inline element is an element placed within a mixed model element to identify a text fragment as relevant for some reason. There are both semantically relevant inlines and presentation oriented inlines. There is but one content model using inlines (and markers), which means that all mixed model elements (i.e., those that allow both text and elements) also allow a repeatable selection of all inline elements. For a discussion of why this is only a trade-off decision, and not the ideal solution, see the discussion at the end of this section.

• The blocks: a block is a container of text or inlines and placeholders that is organized vertically on the display (i.e., has paragraph breaks). Most blocks in AKOMA NTOSO are based on the HTML language. There is only one content model that uses blocks, and it allows a repeatable selection of all available blocks. This means that wherever any block is allowed, all blocks are allowed too: e.g., wherever a paragraph is allowed, a table or a list is also allowed.

• The containers: containers are sequences of specific elements, some of which can be optional. Containers are all different from each other (since the actual list of contained elements vary), and so there is no single container content model, but rather a number of content models that share the same conceptual category. The shared characteristic of containers, is that no text is allowed directly inside them, but only a collection of other elements. Text therefore can only be placed within a block within the container. 

• The hierarchy: a hierarchy is a set of sections nested to an arbitrary depth, all provided with title and numbering. Each level of the nesting can contain either more nested sections or a container. No text is allowed directly inside the hierarchy, but only within a block element that is contained within a container element (not considering, of course, titles and numbering). AKOMA NTOSO 1.0 uses only one hierarchy, with predefined names and no constraints on their order or systematic layering.

There are three exceptions to the systematic use of patterns:

• The <li> element allows both inlines and other nested lists (<ul> and <ol>). The pattern would require <li> elements to contain only text, and nested lists to be direct child of the main list (<ul>s within <ul>). Since this goes against universal HTML practice, we have decided against full pattern adherence and in favor of HTML tradition. 

• The <mod> element allows quoted text and structures within its content. No problems for quoted texts, but when an amendment clause specifies in full a new structure (such as a section) within the main flow, the full content of the new structure needs to be described, and it is thus possible to have a section within a paragraph within a clause, which is against the inline pattern. There is no simple way out of this issue.

• There is some inline elements that only make sense in the preface and/or preamble of the document: for  instance are <DocTitle>, <DocNumber>, for numbered documents such as acts or bills, or <party>, <judge> for judgements. They are in fact part of the one inline content model and thus are available everywhere in the document. There is no simple way to define blocks within <preamble> and <preface> to allow these elements and blocks elsewhere to reject them, so it has been decided that it is better to allow them everywhere rather than uselessly complicating the schema.