Previous: 8.8 The IDs for Top Level Classes  

All content on one page (useful for printing, presentation mode etc.)

9 Release History

Differences between release 9/12/2009 and 21/10/2009

This release contains just two minor bug fixes:

• The complex Type AnyOtherType (allowing elements of any namespace except Akoma Ntoso) now allows any number (including zero) of elements instead of exactly one. This affects a number of metadata elements.
• Attribute refersTo now expects an URI instead of an IDREF value. This means that references to locations inside the document (e.g., in the references section) now need to be prefixed with character “#” instead of being bare (e.g. refersTo=”foobar” needs to become refersTo=”#foobar”). This is in accordance to  a general avoidance of the IDREF introduced  on the 23/10/2006 release and for some reasons ignored for the refersTo attribute.

Differences between release 21/10/2009 and 11/5/2009

This release contains some differences to previous versions regarding mainly the handling of judgments. Most differences regard metadata to analyze judgments, and only a few of them affect the document content. 

• A new inline element, docketNumber, has been introduced to handle the specification of the docket number, case number, file number or in general any number that represents the overall procedure of which this is one document. The term docketNumber has been chosen because it is clear, unambiguous, not overly restrictive (as would have been caseNumber) and not misunderstandable for a computer-related term (as would have been fileNumber).

• Speech-related containers such as administrationOfOaths, declarationOfVote, etc. have been added to the list of containers that can be specified anywhere.

• Element lawyer has a few difference in its attributes: the attribute represents has become for, and a new attribute empoweredBy has been added for lawyers that receive the representation not directly from the client but indirectly through a delegation of power via another lawyer.

• Element opinion, wrapping the opinion of the judges in a judgment, has a new attribute type that specifies whether each individual judge consents or dissents from the judgment.

• The element workflow has been clarified. A workflow is not composed of action elements anymore, but of step elements. Each step element defines (references to instances of) a date, an actor (either a TLCPerson or a TLCOrganization), a role (a TLCRole), and an outcome (a TLCConcept).

• A new analysis container has been added for judicial analysis. The element, judicial, contains a number of judicial arguments, each of which connects a structure of the document to external sources or other structures of the document itself. The judicial element contains one result element that specifies the actual result of the judgment (one of deny, dismiss, uphold, revert, replaceOrder, remit, decide, and approve), and as many elements as needed of the judicial argument category, which are: supports,  isAnalogTo, applies, extends, restricts, derogates, contrasts, overrules, dissentsFrom, putsInQuestion, distinguishes. It should be noted that the term putsInQuestion is hardly satisfactory, and different from the proposed questions, which cannot be used in this context because  it is already used as a section of the Speech containers.

Differences between release 11/5/2009 and 16/3/2009

This release contains no difference from the previous release but a few bug fix. The main justification of this release is to introduce systematic inline documentation to all structures of the language (groups, attribute groups, simple type, complex types and elements.

Additionally, a few bug fixes have been introduced:

• The internal date of the schema has been updated to reflect correctly the revision date of the schema. In previous release, in fact, the release date within the schema had not been updated, resulting in two very different schemas asserting to have been last updated on the same date.
• Group ANotherInline has been actually added to the inlineCM group , allowing elements entity and date to be actually used in document markup.
• Complex types anyOther and anyOtherType, which were identical, have been brought together into one type, anyOtherType. All elements and attributes have been updated accordingly.
• Several reshuffles of relative position of definitions have been made. No difference in content has been performed, though.

Differences between release 16/3/2009 and 5/11/2008

This is a major release, providing a number of relevant modifications to the previous releases. Many of these modifications are NOT backward-compatible. These will be explicitly noted as such in the following.

9.1.1 Sidenotes and out of line texts

A completely new take on side notes has been undertaken in this release. Rather than being header blocks at the beginning of hierarchical structures, side notes are now full members of a new category: authorial notes. An authorial note is by definition a note (i.e., an out-of-line text fragment) that was provided by the original author of the content (i.e., by the author of the specific FRBR expression). 

Thus the element sideNote has been removed, and substituted by a new container element, outOfLine, contained in a collection element outOfLines. Each outOfLine has a type attribute assuming either of the value sideNote or publicationNote, an href attribute pointing to a structure in the document to which the out of line text should be attached to, and contains blocks such as p elements.

Thus the fragment

<akomaNtoso xmlns="http://www.akomantoso.org/1.0">
    <act>
        ...
        <body>
            <section id="sect54.a">
                <num>54A</num>
                <heading>Conduct of prosecutions.</heading>
                <clause id="sect54.a-cla1">
                    <num>(1)</num>
                    <sideNote>Cap 75.</sideNote>
                    <content>
                        <p> Blah blah</p>
                    </content>
                </clause>
            </section>
        </body>
     </act>
</akomaNtoso>

needs to become:

<akomaNtoso xmlns="http://www.akomantoso.org/1.0">
    <act>
        ...
        <body>
            <section id="sect54.a">
                <num>54A</num>
                <heading>Conduct of prosecutions.</heading>
                <clause id="sect54.a-cla1">
                    <num>(1)</num>
                    <content>
                        <p> Blah blah</p>
                    </content>
                </clause>
            </section>
        </body>
        <outOfLines>
            <outOfLine id="out01" type="sideNote" href="#sect54.a-cla1">
                <p>Cap 75.</p>
            </outOfLine>
        </outOfLines>
    </act>
</akomaNtoso>

Please note three issues:

• Reference direction is reversed than with footnotes: rather than the inline content referring to the note, it is the side note referring to the structural fragment it appears with. This allows to get rid of reference markers within the text, and makes more sense in an abstract sense.
• Only referable structures can have a side note. This means that side notes are to be considered associated to sections, clauses, etc. and not to the text they contain. If a fragment of text needs to have a side note, it must be wrapped in a referable fragment, such as a ref or a span element.
• While the previous sideNote element was a block, and thus could contain directly text, the outOfLine element is a container, and thus must contain one or more blocks that in turn contain text.

This modification is NOT backward-compatible. Elements have been removed and a whole new section created in all types of documents.

9.1.2 Content model reorganization for speeches

After being shown an Australian judgement that was really a dialogue between the judge and the lawyers, and considering that AKOMA NTOSO already has all the necessary elements to deal with dialogues, only they were not available in judgements, it was decided that all speech elements should now be available everywhere a container is available. Thus elements such as speech, question and answer are now available even in judgements.

This modification IS backward-compatible. Content models have been expanded.

9.1.3 New inline elements

A number of new inline elements have been added to this release:

• Element lawyer is used to mark the specification of a lawyer. Attribute represents can be used to refer to the party it represents and the attribute role can be added to provide more detailed information about the kind of lawyer.
• Element opinion is used to specify the opinion of the individual judge within the coram of a judgement. Use attribute refersTo to point to a TLCConcept that provides computable assessment of the type of opinion held by the judge.
• Element signature is used to specify the presence of a signature in the document. Use attribute refersTo to point to a TLCPerson that provides the identification of the person responsible of the signature.
• Element entity is used to wrap any mention to a concept that is worth being mentioned in the references section. This includes persons, organizations, roles, and places, among others. Always use attribute refersTo to point to a Top Level Class element in the references section that provides computable assessment of the concept associated to that element.
• Element date is used to wrap explicit dates in the document (that are not documentDates). Use attribute date to provide an unambiguous form of the date in XSD 1.0 syntax yyyy-mm-dd. Use attribute refersTo, if appropriate, to point to a TLCEvent that provides computable assessment of the event associated to that date. Please note that a date element was already present in the schema in the identification section of the metadata, and that it has now been renamed FRBRdate (see section 9.1.5).

This modification IS backward-compatible. Elements have been added.

9.1.4 Judgement-specific and act-specific elements reunited

Elements judgementType, judgementTitle and judgementNumber were considered overlapping and redundant with respect to documentType, documentTitle and documentNumber, and thus removed. Judgements should now use these documents. Furthermore, a new section in the Release Notes has been added providing hints at how to use these elements, section 7.2, that specifies that these elements may be present multiple times in the document, but if there are more than one per type, then the attribute refersTo must be present and point to different instances of TLCConcepts.

This modification is NOT backward-compatible. Elements have been removed.

9.1.5 Name changes in metadata elements

Elements within FRBRWork,  FRBRExpression , FRBRManifestation, and FRBRItem have now an added FRBR prefix, and thus were turned from this, uri, alias, date, and author to FRBRthis FRBRuri, FRBRalias, FRBRdate, and FRBRauthor.

A new element date was added, and its name clashed with the elements within the FRBR levels. Given the philosophy of giving short names to elements within the content, and longer names to elements within the metadata, it was decided to change the name of the FRBR elements, and of all it neighbors, by introducing the same FRBR prefix for all.

This modification is NOT backward-compatible. Element names have been changed.

9.1.6 Bug fixes

• A few elements now required presence of two main attributes: id and refersTo. These are *ref and *mod elements, plus elements party, judge and the new element lawyer. Previously both id and refersTo were optional. This modification is NOT backward-compatible. Attributes have been made required.
• Element scene was previously present as both a container and a block. This is an error, and has been fixed. Element scene is now only a container available everywhere a container can be specified. This modification is NOT backward-compatible, but minor.

9.2 Differences between release 5/11/2008 and release 3/3/2008 

This release comprises a major modification in naming of elements, introducing a systematic usage of  camel case, settling a long-standing issue about incoherence in the usage of lower and uppercase characters in element names (as well as one element group). This change is thus fixing an overall problem of coherence in element naming, rather than a concrete problem of descriptiveness or completeness of the vocabulary.

Content differences:

• The spelling “judgment” has been replaced with “judgement” in observance to the above-mentioned mail by Mariya Badeva. This relates to all elements and attributes containing the word judgement.
• All Top Level Classes have now a proposed syntax for IDs (that was up to this day only mentioned as TBD).
• Element comment has been renamed scene according to remarks about adopting a vocabulary more connected to screenplays.
• Elements ActType, ActTitle, ActNumber, ActProponent, ActDate, and ActPurpose have been renamed docType, docTitle, docNumber, docProponent, docDate, and docPurpose so as to reflect a vocabulary apt to describe more than just legislation.
• Element recordedTime has now a new attribute type to allow for the specification of recorded times for the beginning of event (startEvent) and end of events (endEvent) if necessary
• A new inline element remark has been added to specify editorial inclusions within the main text (for instance the caption of the speaker in the new page continuing from the previous one). An attribute type with an initial list of remark types (sceneDescription, phenomenon, caption, translation) is also added.

Case differences (specific to the camelCase release):

• A specific policy for case in names has been decided. It only and specifically regards structure names in the schema (these include names for attributes, elements, simple types, complex types, attribute groups and element groups) that are composed of two separate terms in plain English. The policy is as follows:

• A name that is composed of a simple term is all in lowercase (e.g., section, act, publication).

• A name that is composed of two or more full terms has the first one in lowercase, and all the others have their initial letter in uppercase (that I call camelCase, as a reduced form of CamelCase). For instance, courtType, actDate, mainContent.

• A name that is composed of an acronym plus one or more full terms has the acronym in all capital letters and the remaining terms in camelCase (i.e., the first is all lowercase and the others have the first letter in uppercase). For instance, FRBRManifestation, TLCPerson.

• The element groups, complex types and simple types EventType, VersionType, InlineCM, SpeechSection,  HierarchicalStructure, OpenStructure, DebateStructure, JudgmentStructure and DocumentTypes are now eventType, iversionType, inlineCM, speechSection, hierarchicalStructure, openStructure, debateStructure, judgementStructure (note new spelling for judgement) and documentType (note, also singular now) in camelCase.

• 17 elements have changed their case in order to adopt the camelCase approach: elements activeModifications, activeRef, akomaNtoso, attachmentOf, debateRecord, efficacyMod, forceMod, hasAttachment, mainContent, meaningMod, noteRef, passiveModifications, passiveRef, proceduralMotions, scopeMod, textualMod, and tocItem.

9.3 Differences between release 3/3/2008 and 22/10/2007 

This is a tentative release of a major evolution, with a specific improvement, namely the support for judgments. Other minor modifications have been included. Existing documents that are not judgments should be unaffected by this release.

Most of the modifications accept and organize the proposal from Monica Palmirani in a document called “Common Open Standard for Judgments”.

Modifications unrelated to the judgment we find:

• A new element for debate documents called DeclarationofVote
• A new element this is added in all FRBR levels to report the URI of the specific component where the metadata block is found
• The name for the Attachment element in the analysis element is now HasAttachment in order to avoid confusions. 

Modifications related to the judgment as specified in Palmirani’s document are:

• A new document type “judgement” is introduced, that has its own schema composed of meta, header, judgmentBody, conclusions and attachment.
• Within the section header a number of additional inline-level purpose-specific elements have been added, namely: judgmentType, judgmentTitle, judgmentNumber, courtType, neutralCitation, party, judge, and judgmentDate.
• The judgmentBody has a repeatable choice of sections named introduction, background, motivation, and decision.
• An additional metadata element, workflow, and its repeatable child action have been added.

Some modifications diverge from Palmirani’s proposal, as follows:

• No elements such as coram, judges and judgmentDates have been specified, as they are containers, disallowed in the patterned structure of inline elements. The corresponding singular elements are used directly in the flow of the text.
• The element body has been substituted with judgmentBody, as body has been used already to refer to the content of hierarchical structures such as acts and bills.
• The href attributes in part, judge and action, meant to refer to the ontological section references, have been omitted as the proper attribute refersTo now exist for all elements in the schema, and therefore no need for such attribute was needed. The as attribute, on the other hand, has been kept as proposed.

Open issues are as follows:

• We have adopted the spelling “judgment” instead of “judgement” as proposed by Palmirani, but we are worried about the last sentence in the following fragment from http://en.wikipedia.org/wiki/Judgment_%28law%29: “However, the spelling judgement (with e added) largely replaced judgment in the United Kingdom in a non-legal context […] In the context of the law and theology, however, judgment is preferred. In the U.S. judgment strongly prevails. As with many such spelling differences, both forms are equally acceptable in Canada and Australia, although judgment is more common in Canada and judgement in Australia.[1] In New Zealand the form judgment is the preferred spelling in dictionaries, newspapers and legislation, although the variant judgement can also be found in all three categories. In South Africa, judgement is the more common form."
• We are not convinced of the need for a workflow element, and would have preferred to have it harmonized and included in the lifecycle element.

9.4 Differences between release 22/10/2007 and 17/09/2007

9.16 Differences between release 15/11/2005 and release 15/09/2005

Previous: 8.8 The IDs for Top Level Classes