What is it
AKOMA NTOSO 1.0 Schema
Document Actions
All content on one page (useful for printing, presentation mode etc.)
6 Document Lifecycle
AKOMA NTOSO 1.0 include a sophisticated mechanism to keep track of the life cycle and evolution of a legal document. This is particularly useful for acts that are amended and modified in time, while maintaining their fundamental nature.
The management of evolution of a document makes two important assumptions:
- Amendments and events in the life cycle of a document (including original approval, final repeal and any other event affecting its presence in the law system or its content) happen in precise moments in time that can be determined objectively (albeit possibly with difficulty) and attributed a specific date.
- Amendments and events in the life cycle are due to the enactment of a specific, individual document that can be objectively traced back and identified with an URI. If two different documents affect the same act on the same date, then these must be counted as two different and separate events on the amended act.
Handling events in AKOMA NTOSO centers around the <lifecycle> element in the meta section. This contains two containers, <events> and <references>, used to list the dates of all the events affecting a document, and the references to the URIs of all the documents generating these events. Each reference is provided with a required identifier, which is used by the event list to specify which document is responsible for which events. These elements must appear in all documents that have undergone two or more events (e.g., all acts except the ones that still have no amendments).
Documents in AKOMA NTOSO are organized in three main categories, as specified in the contain attribute of the document type element:
- originalVersion: this value reflects the fact that the content on the document is exactly the content that has been formally and explicitly approved by the relevant authority, with no amendments applied.
- singleVersion: this value reflects the fact that the content of the document is an editorially modified version of the original document, according to one or more subsequent amendment documents. These amendment documents and the enactment dates of the amendments must be all mentioned in the <lifecycle> element. Individual additions and deletions are not marked in the content.
- multipleVersions: this value reflects the fact that the content of the document is the juxtaposition of fragments belonging to two or more different versions of the same document, each fragment marked as belonging to one or many of these versions. Thus in a multipleVersions act there could be two or more copies of section 2, each associated to the date it started enactment and ended enactment.
The <lifecycle> element is a required element for all singleVersion and multipleVersion documents, and must be complete up to the enactment date of the latest document referenced in the <lifecycle> element (i.e., there can potentially exist subsequent amendments not included, but all amendments preceding the document’s date must be correctly listed and referenced, even if they play no part in the displayed content). originalVersion documents need not have the <lifecycle> element, but surely can have it if the editors decide so.
In case a multipleVersions document is being generated, each element and text fragment may be associated with an enactment specification through the means of the five attributes: start, end (for validity), startEfficacy, endEfficacy (for efficacy) and status. Each fragment (a whole element if appropriate, otherwise a newly inserted <span> or <inline> element for text fragments for which no exact containing element exists) must use these attribute to specify its nature.
The start and end attributes (and similarly the startEfficacy and endEfficacy attributes) contain a reference to the ID of the event that has marked the beginning or the end of the enactment (or of the efficacy) of the fragment. A start attribute with no end attribute marks a fragment that has appeared in an amendment and still exists in the latest recorded version of the document. An end attribute with no start attribute mark a fragment that was part of the original document but has been repealed before or at the latest recorded version of the document. The status attribute records the type of amendment of the fragment. The value “omissis” can only be used by non-authoritative publications that need to display only part of the whole document: when status=”omissis”, the structure must be complete as if all contents was present, but unrequired parts of the actual content can be removed. Similarly, the value “editorial” can be used to add fragments of text of editorial nature (i.e., that are generated by editors rather than authors). Examples include annotations and translated sentences. For instance:
<p xml:lang=”afr” id=”blk123”>Partye wat deel wil vorm van die proses van regering, is vol verligting. ``Sien,'' sˆ die Nuwe NP, ``die ANC is nie magshonger nie!'' Ryke ironie, komende van waar die Nuwe NP sit. <span xml:lang=”eng” status=”editorial”>(Translation of Afrikaans paragraph follows.)</span></p>
<p xml:lang=”eng” status=”editorial” refersTo=”blk123”>[Parties who want to form part of government are quite relieved. ``You see'', says the New NP, ``the ANC is not power-hungry!'' Such irony, if one considers where the New NP is sitting.]</p>