AKN4EU Documentation Version 3.0 (2020-03-30) Volume II - XML mark-up PART 1. AKN4EU GUIDELINES ........................................................................................................................... 3 1 PRINCIPLES FOR THE STRUCTURING OF THE TEXT .................................................................................... 4 1.1 THE AKOMA NTOSO PRINCIPLES .................................................................................................................... 4 1.1.1 Categories of content models ............................................................................................................ 4 1.1.2 The families of elements for the structuring of the text .................................................................... 5 1.2 THE AKN4EU USE OF AKOMA NTOSO FAMILIES OF ELEMENTS ............................................................................ 6 1.2.1 General principles .............................................................................................................................. 6 1.2.2 The subparagraph ............................................................................................................................. 7 1.2.3 Figure and table ................................................................................................................................ 7 1.2.4 Structure inside an article................................................................................................................ 10 1.2.5 The independent point .................................................................................................................... 16 2 THE METADATA PART OF THE AKOMA NTOSO DOCUMENT................................................................... 20 2.1 THE AKOMA NTOSO OVERALL STRUCTURE OF METADATA ................................................................................. 20 2.2 ATTRIBUTE @SOURCE FOR THE SECTION OF THE METADATA .............................................................................. 20 2.3 THE <IDENTIFICATION> SECTION OF THE METADATA ........................................................................................ 21 2.3.1 FRBRWork/FRBRcountry.................................................................................................................. 21 2.3.2 FRBRWork/FRBRprescriptive ........................................................................................................... 21 2.3.3 FRBRExpression/FRBRlanguage ...................................................................................................... 21 2.4 THE <ANALYSIS> SECTION OF METADATA....................................................................................................... 22 2.5 THE <REFERENCES> SECTION OF THE METADATA ............................................................................................. 22 3 DOCUMENTS EXCHANGED IN THE CONTEXT OF THE ORDINARY LEGISLATIVE PROCEDURE (OLP) .......... 24 3.1 REGULATION, DIRECTIVE, DECISION AS RESULTS OF THE OLP AND THE RESPECTIVE PROPOSALS - THE <ACT> AND THE <BILL> 24 3.1.1 The AKN4EU mark-up of the main part of the act ........................................................................... 27 3.1.2 Annexes (<doc name="ANNEX">) .................................................................................................... 39 3.2 THE PROPOSAL FROM THE COMMISSION: <DOCUMENTCOLLECTION NAME="PROP_ACT"> .................................. 44 3.2.1 The overall structure of the document: <documentCollection> ...................................................... 47 3.2.2 The Explanatory Memorandum: <doc name="EXPL_MEMORANDUM"> ....................................... 52 3.2.3 The legal text ................................................................................................................................... 53 3.3 THE EP LEGISLATIVE RESOLUTION (<BILL NAME="RES_LEGIS") ............................................................... 54 3.3.1 <preface>......................................................................................................................................... 54 4 OTHER DOCUMENTS .............................................................................................................................. 60 4.1 INTERNATIONAL AGREEMENT ...................................................................................................................... 60 4.1.1 <preface>......................................................................................................................................... 60 4.1.2 Preamble: the <preamble> .............................................................................................................. 61 4.1.3 Enacting terms: the <body> ............................................................................................................ 63 4.1.4 <conclusions> .................................................................................................................................. 63
124
Embed
AKN4EU Documentation Version 3.0 (2020-03-30) Volume II ...
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
AKN4EU Documentation
Version 3.0 (2020-03-30)
Volume II - XML mark-up
PART 1. AKN4EU GUIDELINES ........................................................................................................................... 3
1 PRINCIPLES FOR THE STRUCTURING OF THE TEXT .................................................................................... 4
1.1 THE AKOMA NTOSO PRINCIPLES .................................................................................................................... 4
1.1.1 Categories of content models ............................................................................................................ 4
1.1.2 The families of elements for the structuring of the text .................................................................... 5
1.2 THE AKN4EU USE OF AKOMA NTOSO FAMILIES OF ELEMENTS ............................................................................ 6
1.2.1 General principles .............................................................................................................................. 6
1.2.2 The subparagraph ............................................................................................................................. 7
1.2.3 Figure and table ................................................................................................................................ 7
1.2.4 Structure inside an article ................................................................................................................ 10
1.2.5 The independent point .................................................................................................................... 16
2 THE METADATA PART OF THE AKOMA NTOSO DOCUMENT ................................................................... 20
2.1 THE AKOMA NTOSO OVERALL STRUCTURE OF METADATA ................................................................................. 20
2.2 ATTRIBUTE @SOURCE FOR THE SECTION OF THE METADATA .............................................................................. 20
2.3 THE <IDENTIFICATION> SECTION OF THE METADATA ........................................................................................ 21
3.2 THE PROPOSAL FROM THE COMMISSION: <DOCUMENTCOLLECTION NAME="PROP_ACT"> .................................. 44
3.2.1 The overall structure of the document: <documentCollection> ...................................................... 47
3.2.2 The Explanatory Memorandum: <doc name="EXPL_MEMORANDUM"> ....................................... 52
3.2.3 The legal text ................................................................................................................................... 53
3.3 THE EP LEGISLATIVE RESOLUTION (<BILL NAME="RES_LEGIS") ............................................................... 54
6.1 CASE OF THE AMENDING ACT: AMENDMENTS ................................................................................................. 71
6.1.1 The part of an act that amends another act ................................................................................... 71
6.1.2 The AKN4EU mark-up for the amendment ...................................................................................... 76
6.1.3 Case of the amending Act: text that repeals an act ...................................................................... 103
6.1.4 Case of the amending Act: summary of the amendment mark-up ............................................... 105
7 ELI SYNTAX ........................................................................................................................................... 112
7.1 URI TEMPLATE FOR EUROPEAN UNION LEGISLATION AND PREPARATORY ACTS (DRAFT) ........................................ 112
7.2 REFERENCE TO SUBDIVISION IN ELI URI TEMPLATES (!!! DRAFT !!!) .................................................................. 113
PART 2. .............................................................. CORRESPONDENCE BETWEEN COV 3.0 AND AKN4EU 3.0
115
AKN4EU – Volume II – PART 1 & 2
30/03/2020 Page 3 of 124
PART 1. AKN4EU Guidelines Scope
This part provides an introductory documentation to AKN4EU regarding the XML mark-up. The
definition required for AKN4EU is carried out on two levels:
On the business level, the ‘Common Vocabulary’ (CoV) identifies and describes the semantic
and logical concepts extracted from examples of the exchanged documents.
On the technical level, the OASIS standard Akoma Ntoso is the structured, machine-readable
format used for implementation.
Because Akoma Ntoso is a rather generic standard that is designed to cover a big variety of legal
documents, it has to be defined how the semantic and logical concepts that are described by the CoV
have to be expressed in Akoma Ntoso. In other words, AKN4EU can be considered as the localisation
of Akoma Ntoso for EU legislation.
In the current version, this document is focused on the documents exchanged in the scope of the
Ordinary Legislative Procedure (OLP) and is a result of the ongoing work of the subgroup Format
Guidelines. Therefore, it currently covers the following document types:
Regulation,
Directive,
Decision,
Proposal for a Regulation,
Proposal for a Directive,
Proposal for a Decision.
Legislative Resolution of the European Parliament
In addition to these documents and beyond the OLP, the document type 'International Agreement' is
also included in this release.
In the current version of AKN4EU, the expression of a modification in an amending act is covered as
well as its associated metadata.
At this stage however, the mark-up for codification and recast and the metadata for consolidation
are not covered.
AKN4EU – Volume II – PART 1 & 2
30/03/2020 Page 4 of 124
1 Principles for the structuring of the text This section describes the general principle of Akoma Ntoso for the mark-up of the content of a
document
1.1 The Akoma Ntoso principles
1.1.1 Categories of content models
Akoma Ntoso defines the content model based on ‘categories of content model (‘refer to families of
elements that share the same conceptual organization of the internals’).
As explained in the Akoma Ntoso Version 1.0. Part 1: XML Vocabulary1, there are six categories of
content models:
The markers: markers are content-less elements placed inside the document. Inside the
content, they are meaningful for their position, their names and their attributes. Metadata
are also markers.
The inlines: an inline element is an element to identify a text fragment as relevant for some
reason. (semantic or presentation)
The blocks: a block is a container of text or inlines.
The subFlow: a subFlow element is an element placed within a mixed content element to
identify a completely separate context that, for any reason, appears within the flow of the
text, but does not belong to it or does not follow its rules.
The containers: containers are sequences of specific elements, some of which can be
optional. The shared characteristic of containers is that no text is allowed directly inside
them, but only a collection of other elements.
The hierarchy: a hierarchy is a set of sections nested to an arbitrary depth, usually provided
with title and numbering. 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 uses only one hierarchy, with predefined names and no
constraints on their order or systematic layering.
Therefore, only elements that are inline or block can contain textual content.
1 The Oasis specification is Akoma Ntoso 1.0 and corresponds to the AKN schema 3.0 (namespace
http://docs.oasis-open.org/legaldocml/ns/akn/3.0)
AKN4EU – Volume II – PART 1 & 2
30/03/2020 Page 5 of 124
1.1.2 The families of elements for the structuring of the text
There are two ways to mark up the structure of a text:
The hierarchical family gives names to the different structural elements, making a
correspondence with a functional reference. This family of elements is used to mark-up the
legislative text. A hierarchical element has a <num> and <heading> and up to 3 available
containers :
o the element <intro>, for introductory text, if any;
o either the element <content>, for the content of the element,
or other hierarchical element(s) if the structure is more complex;
The hierarchical element with a sub-element <content> is the last level of named
structure. Inside the <content> element there are block elements containing the
text.
o the element <wrapUp>, for the final block if any.
The hierarchical family contains 27 elements2, but the hierarchical relation between them is
not predefined in the standard. It depends on the legal tradition.
The family of ‘block elements’ enables the marking-up of content but without a clear naming
of the structure elements and with a predefined relation between the elements.
The table below shows the mapping between these two kinds of elements. Here is the informal
correspondence used in AKN4EU:
element for documents elements for legal text content (enacting terms)
In AKN4EU, an article has the following structure:
An <article> MUST have a heading (<num>) and can have a subject (<heading>).
An <article> MUST be composed of <paragraph>. The paragraph can be numbered (has
<num> element) or not.
An unnumbered paragraph MUST only have one subparagraph.
A numbered paragraph can have one or multiple subparagraphs.
Mark-up of <subparagraph> inside a <paragraph>
When there is only one subparagraph and the subparagraph is a simple block, the content of the subparagraph MUST be inside a <p> in the element <content> of <paragraph>.
When there are multiple subparagraphs, each subparagraph that is a simple block MUST be is in an element <subparagraph>5.
Mark-up of <subparagraph> inside a <point> or an <indent>
See above, section "The subparagraph"
5 So <subparagraph> will never be inside an unnumbered paragraph.
The following values for the attribute @name are used:
Value of the attribute @name
for <act> or <bill>
Description
"REG" - Regulation
- Legal text of the Proposal for a Regulation.
"DIR" - Directive
- Legal text of the Proposal for a Directive.
"DEC" - Decision
- Legal text of the Proposal for a Decision.
This section describes the mark-up for the following components:
(a) A Decision, Directive or Regulation (resulting from on Ordinary Legislative Procedure) and
published in the Official Journal:
(b) The legal text of the Proposal from the Commission:
AKN4EU – Volume II – PART 1 & 2
30/03/2020 Page 26 of 124
(c) The Position of the European Parliament (‘EP Consolidated text’) of the Texts Adopted.
AKN4EU – Volume II – PART 1 & 2
30/03/2020 Page 27 of 124
3.1.1 The AKN4EU mark-up of the main part of the act
The main part of the act has the following structure:
CoV
terminology
Regulation
Example AKN4EU
elements
<act
name="REG">
title
preamble
enacting terms
signature
<preface>
<longTitle>
<preamble>
<body>
<conclusions>
REGULATION (EU) 2017/1938 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL
of 25 October 2017 concerning measures to safeguard the security of gas supply
and repealing Regulation (EU) No 994/2010 (Text with EEA relevance)
THE EUROPEAN PARLIAMENT AND THE COUNCIL OF THE EUROPEAN UNION, Having regard to the Treaty on the Functioning of the European Union, and in particular Article 194(2) thereof, Having regard to the proposal from the European Commission, … Acting in accordance with the ordinary legislative procedure (2), Whereas:
(1) Natural gas (gas) remains an essential component of the energy supply of the Union. A large proportion of such gas is imported into the Union from third countries.
… HAVE ADOPTED THIS REGULATION:
Article 1 Subject matter
This Regulation establishes provisions aiming to safeguard the security of gas supply in the Union by ensuring the … This Regulation shall be binding in its entirety and directly applicable in all Member States.
Done at Strasbourg, 25 October 2017. For the European Parliament For the Council The President The President A. TAJANI M. MAASIKAS
AKN4EU – Volume II – PART 1 & 2
30/03/2020 Page 28 of 124
Akoma Ntoso requires in any documents a first container <meta> grouping all metadata associated
with the document (see the section ‘The metadata part of the Akoma Ntoso document’).
3.1.1.1 <preface>
The preface contains the title of the act as well as additional information like for example the
indication of "EEA relevance".
The title itself MUST be marked up with the element <longTitle>. Additional information MUST be
marked up with the element <container>.
3.1.1.1.1 Title of an act: the <longTitle>
The <longTitle> MUST contain only one <p>.
The <p> contains the following inline elements:
elements in <longTitle> Description
<docStage> The line comprising the information that the document is a proposal or the fragment that indicates that the document is the Position of the European Parliament. It MUST only used if the text is marked as a <bill>.
<docType> The line containing the type of the act. The attribute @refersTo, (mandatory for act and bill), contains the reference of the TLCReference related to the type of the act.
<docNumber> The number of the act.
<date> The date of the act. The mandatory attribute @date contains the date in normalized format.
<docPurpose> The subject of the act. The <docPurpose> can have the following sub-elements :
<ref> Marks the reference to an act mentioned in the subject of the current act. The mandatory attribute @href contains the ELI identifier of that act.
<mref> The fragment of the <docPurpose> that is common to multiple references to an act.
AKN4EU – Volume II – PART 1 & 2
30/03/2020 Page 29 of 124
3.1.1.1.1.1 Examples
For an act:
<longTitle>
<p><docType @refersTo="~_REG">Regulation <docNumber>(EU) No
1384/2014</docNumber> of the European Parliament and of the Council</docType>
of <date date="2014-12-18"> 18 December 2014</date>
<docPurpose>on the tariff treatment for goods originating in
Ecuador</docPurpose></p>
</longTitle>
For the legal text of a Proposal from the Commission:
<longTitle>
<p><docStage>Proposal for a</docStage>
<docType @refersTo="~_REG">Regulation of the European Parliament and of the
Council</docType>
<docPurpose>on the tariff treatment for goods originating in
Ecuador</docPurpose></p>
</longTitle>
NB: The references section of the <meta> element must comprise the corresponding TLCReference. For the above example, it will be: <meta>
(a) All references to one or more other acts in the title of an act is marked with the <ref> element. The mandatory attribute @href contains the ELI identifier of the act. For <act>, this mark-up MUST be present. For the bill, this mark-up SHOULD be used.
For example: <longTitle>
<p><docType @refersTo="~_REG">REGULATION <docNumber>(EU) No
254/2014</docNumber> OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL</docType>
of <date date="2014-02-26">26 February 2014</date>
<docPurpose>on a multiannual consumer programme for the years 2014-20 and
repealing <ref href="http://data.europa.eu/eli/dec/2006/1926">Decision No
1926/2006/EC</ref></docPurpose></p>
</longTitle>
(b) When multiple references are grouped in such a way that they cannot be easily separated,
because a part of reference – common to all of them – is mentioned only once, an <mref> element MUST be used to mark the whole span (common part and specific part).
AKN4EU – Volume II – PART 1 & 2
30/03/2020 Page 30 of 124
For example: <longTitle>
<p><docType @refersTo="~_REG">REGULATION <docNumber>(EU) No
254/2014</docNumber> OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL</docType>
of <date date="2014-02-26">26 February 2014</date>
<docPurpose>on a multiannual consumer programme for the years 2014-20 and
repealing <mref>Council Directives <ref
href="http://data.europa.eu/eli/dir/1991/672">91/672/EEC</ref> and <ref
As all elements representing an higher subdivision of text have the same structure, they are grouped
in this section.
These elements contain:
- a text providing the numbering of this structure that is associated with the parent structure,
- the subject of the structure,
- articles or sub-structures.
The official documentation12 prescribes an order for the use of these elements, which in practice has
not always been respected in the past.
Example:
<title>
<num>TITLE I</num>
<heading>SCOPE, DEFINITIONS AND GENERAL PRINCIPLES</heading>
<chapter>
<num>CHAPTER I</num>
<heading>Scope and definitions</heading>
<section>
<num>Section 1</num>
<heading>Subject-matter and definitions</heading>
<article>
<num>Article 1</num>
<heading>Subject-matter and scope</heading>
<paragraph>
<num>1.</num>
<content>
<p>This Directive establishes rules on the procedures for
procurement by contracting authorities with respect to public contracts as well as
design contests, whose value is estimated to be not less than the thresholds laid
down in Article 4.</p>
</content>
</paragraph>
<paragraph>
<num>2.</num>
<content>
<p>Procurement within the meaning of this Directive is the
acquisition by means of a public contract of works, supplies or services by one or
more contracting authorities from economic operators chosen by those contracting
authorities, whether or not the works, supplies or services are intended for a
public purpose.</p>
</content>
</paragraph>
...
</article>
...
</section>
12
Joint Practical Guide (2015) § 15.4
AKN4EU – Volume II – PART 1 & 2
30/03/2020 Page 36 of 124
</chapter>
</title>
3.1.1.3.3 The direct applicability: the <clause>
The body of a Regulation MUST end with a special formula expressing the direct applicability of the Regulation. This text is outside any <article>, but inside the <body>. It MUST be marked with the element <clause>. Example: <clause>
<content>
<p>This Regulation shall be binding in its entirety and directly applicable
in all Member States.</p>
</content>
</clause>
AKN4EU – Volume II – PART 1 & 2
30/03/2020 Page 37 of 124
3.1.1.4 Signature: the <conclusions>
This element marks up the information corresponding to the signature of the document: the
location, date and signature.
3.1.1.4.1 <references> section of the metadata for the <conclusions>
For the conclusions, the <references> part of the metadata must contain the following entries:
a <TLCLocation> for the location (authority table ‘Place’13).
a <TLCOrganization> for each institution that signs or will sign the act/bill. For an Ordinary Legislative Procedure, it will be the European Parliament and the Council (authority table ‘Corporate body’ 14).
Currently, annexes can have various structures. They differ structurally from the body of the act because they are not composed of articles. The structure of annexes can be composed of 3 levels of elements:
High-level structures, which can group sub-structures, as in the enacting terms of the act: part, title, chapter, section.
An intermediate structure, that can contain: o independent points; o unnumbered paragraphs.
A lower level, grouping all structures available inside paragraphs, using the same rules.
All these structures are optional: for example, an annex can be composed only of unnumbered paragraphs, or it can be composed of independent points with or without sub-structures or of an unnumbered paragraph followed by independent points.
3.1.2.2.1 High level structures
As in the enacting terms of acts, the following elements are available to represent the high-level
structures in annexes:
<title>
<part>
<chapter>
<section>
Example:
<chapter>
<num>CHAPTER I</num>
<heading>Subject matter for the training of staff performing official
controls and other official activities</heading>
…
</chapter>
AKN4EU – Volume II – PART 1 & 2
30/03/2020 Page 41 of 124
Inside a high-level structure, the following structures are available:
other high-level structures, respecting the hierarchical order of higher structures as defined
in the Joint Practical Guide;
independent points; or
unnumbered paragraphs.
3.1.2.2.2 Independent points: element <level>
In AKN4EU, the independent point MUST be marked with the element <level>.
Example:
<mainBody>
<level>
<num>1.</num>
<content>
<p>Obligations of manufacturers</p>
</content>
</level>
<level>
<num>1.1</num>
<content>
<p>The satisfactory operation of the multi-stage type-approval requires
joint action by all the manufacturers concerned. To that end approval authorities
must ensure, before granting first and subsequent stage type-approvals, that
suitable arrangements exist between the relevant manufacturers for the supply and
interchange of documents and information, so that the completed type of vehicle
meets the technical requirements of all the relevant regulatory acts listed in
Annex II. Such information must include details of relevant system, component and
separate technical unit type-approvals and of vehicle parts that form part of the
incomplete vehicle but have not yet been type-approved.</p>
</content>
</level>
<level>
<num>1.2</num>
<content>
<p>Each manufacturer involved in a multi-stage type-approval shall be
responsible for the approval and conformity of production of all systems,
components or separate technical units manufactured or added by that manufacturer
to the previously built stage. The manufacturer of the subsequent stage shall not
be responsible for objects that have been approved in an earlier stage, except
where that manufacturer modifies relevant parts to such an extent that the
Like in the enacting terms, the unnumbered paragraph is composed of one subparagraph that can be
simple or can be composed of a list of points or indents with an introductory part, or a table with
heading and/or subject, or a figure with heading and subject and/or legend.
The unnumbered paragraph MUST be marked with the element <paragraph> without subelement
<num>.
The <paragraph> element MUST contain one of these alternatives:
a sub-element <content> if the paragraph is simple;
a sub-element <list> if the paragraph is composed of a list of points with an introductory
part;
a sub-element <subdivision> if the paragraph is composed of a table with heading and
subject or is composed of a figure with heading and subject and/or legend.
Example
<mainBody>
<paragraph>
<list>
<intro>
<p>The national plan shall include the following information:</p>
</intro>
<point>
<num>(a)</num>
<content>
<p>national objectives and reduction targets to eliminate the
use of mercury and mercury compounds;</p>
</content>
</point>
…
</list>
</paragraph>
…
</mainBody>
3.1.2.2.4 Low level structure
3.1.2.2.4.1 Subparagraphs
The lower level structures are the same as in the enacting terms.
As in the enacting terms, the subparagraph can be simple, or it can be composed of:
a sequence of points with introductory part;
a table with a heading and a subject;
a figure with a heading and a subject and/or legend.
See above the section "The subparagraph" for the mark-up rule of subparagraph.
Example
AKN4EU – Volume II – PART 1 & 2
30/03/2020 Page 43 of 124
<level>
<num>4.2.</num>
<subparagraph>
<content>
<p>The manufacturer shall draw up a written EU declaration of
conformity for a PPE model and keep it, together with the technical documentation,
at the disposal of the national authorities for 10 years after the PPE has been
placed on the market. The EU declaration of conformity shall identify the PPE for
which it has been drawn up.</p>
</content>
</subparagraph>
<subparagraph>
<content>
<p>A copy of the EU declaration of conformity shall be made available
to the relevant authorities upon request.</p>
</content>
</subparagraph>
</level>
AKN4EU – Volume II – PART 1 & 2
30/03/2020 Page 44 of 124
3.2 The Proposal from the Commission: <documentCollection
name="PROP_ACT">
A Proposal from the Commission (Proposal for a Regulation, Proposal for a Directive or Proposal for a
Decision) is the document that initiates an OLP procedure.
The proposal is composed of at least two subdocuments:
- an Explanatory Memorandum,
- the legal text: it is the main component of the proposal as it is the first version of what can
become an act at the end of the OLP procedure. The legal text may have annexes.
The logical nesting of documents of the Proposal from the Commission is the following:
The annexes are referenced in the legal text only.
Each box in the image above corresponds to an Akoma Ntoso document in a specific file. 17
17
see the section 4.7 on the specification of the packaging of XML files for more information on the LEG
package.
Proposal from the Commission
Explanatory Memorandum
Legal Text
Annex to the legal text Annex to the legal text
AKN4EU – Volume II – PART 1 & 2
30/03/2020 Page 45 of 124
Taking this into account, the basis structure of a Proposal of the Commission in AKN4EU corresponds
to the following schema:
Physically, each box is a specific file. The all document is a LEG package (a kind of zip file containing
all the files that forms the document). The entry point is always named "main.xml".
Proposal from the Commission
Reference to EM
Reference to legal text
Cover page
Explanatory memorandum (EM)
Legal text
Reference to Annex(es)
Annex
AKN4EU – Volume II – PART 1 & 2
30/03/2020 Page 46 of 124
The overall structure of the Proposal from the Commission is the following:
Proposal for a
Regulation <documentCollection
name="PROP_ACT">
logo
place and date
reference
procedure_ide
ntifier
title of the act
<coverPage>
<container
name="logo">
<container
name="mainDoc">
<block
name="placeAndDate”>
<block
name="reference”>
<container name=
"procedureIdentifier">
<longTitle>
</coverPage>
Explanatory
Memorandum
heading
section
unnumber
ed
paragraph
<longtitle>
<tblock >
<p>
<doc
name="EXPL_MEMORANDUM
">
<preface>
--------------------
<mainBody>
Regulation
-------------
Preamble
procedure
identifier
title of the
act
<container name=
"procedureIdentifier">
<longTitle>
<bill name="REG">
<preface>
---------------------
<preamble>
EUROPEAN COMMISSION
Strasbourg, 15.12.2015
COM(2015) 668 final
2015/0306 (COD)
Proposal for a
REGULATION OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL
on a European travel document for the return of illegally staying third-country
nationals
AKN4EU – Volume II – PART 1 & 2
30/03/2020 Page 47 of 124
3.2.1 The overall structure of the document: <documentCollection>
The proposal from the Commission itself is like a dossier. It contains only the information needed to
display the coverPage of the dossier and the reference to the sub-documents it contains.
The Proposal from the Commission document MUST be marked as a <documentCollection>.
<documentCollection> has a mandatory attribute @name. The value of this attribute is:
Value of attribute @name Description
PROP_ACT This is the generic code issued from the Named Authority Lists of
the Metadata Registry ‘Resource type’.
NB. The attribute value is therefore the same for a ‘Proposal for a
Regulation’, a ‘Proposal for a Directive’ or a ‘Proposal for a Decision’.
The <documentCollection> for the Proposal of the Commission has the following structure:
a <coverPage> mandatory,
a <collectionBody> mandatory, containing one <component> per subdocuments.
Akoma Ntoso requires in any document a first container <meta> grouping all metadata associated to
the document (see the section ‘The metadata part of the Akoma Ntoso document’).
3.2.1.1 <coverPage>
The element <coverPage> contains all the information for the cover page and MUST have as sub-
elements:
- <longTitle>
This is the title of the proposal.
- <container>
This is a generic element gathering further information. The attribute @name is required and
defines the type of information in this element.
3.2.1.1.1 <longTitle>
The <longTitle> of <documentCollection> has the same structure as the <longTitle> of a <bill>
included in this <documentCollection>.
AKN4EU – Volume II – PART 1 & 2
30/03/2020 Page 48 of 124
3.2.1.1.2 <container>
Each <container> corresponds to a type of information.
The following containers are currently defined:
<container>:
value of attribute @name
Description
eeaRelevance Indicates the EEA relevance.
Example:
<container name="eeaRelevance"> <p>(Text with EEA relevance)</p> </container>
logo The container comprises the emblem and name of the proposing
entity that is responsible for the document.
The sub element of the container is a single <p> containing at least
one element <img> for the emblem.
mainDoc The information related to the document itself: location, date and
the document reference.
The <container> has two sub-elements :
- <block name="placeAndDate"> containing the place and the
date of the approbation of the document by the proposing
entity,
- <block name="reference"> containing the reference of the
document. The reference is inside a <docNumber>
element.
mainDocLanguage The language of the document.
procedureIdentifier The identifier and the type of the legislative procedure.
The sub-element of the container is a single <p> containing the
information inside a <docketNumber> element.
swdReferences The references to staff working documents e.g. the impact
assessment or the summary impact assessment.
AKN4EU – Volume II – PART 1 & 2
30/03/2020 Page 49 of 124
3.2.1.1.3 The reference to Staff Working Documents
In the cover page of the Proposal from the Commission, there may be cross references to Staff Working Documents (SWD) such as the impact assessment or the summary of the impact assessment.
<docType refersTo="~_DEC">DECISION OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL</docType>
<docPurpose>on establishing an information exchange mechanism with regard to
intergovernmental agreements and non-binding instruments between Member States and
third countries in the field of energy and repealing <ref href="http://data.europa.eu/eli/dec/2006/1926">Decision No 1926/2006/EC</ref> </docPurpose></p>
a <num> element (the <num> element contains the number of the section or the bullet sign
if the section is not numbered)
a <heading> element containing the subject of the section
its content:
o <blockContainer> or
o multiple <tblock> if the content is composed of nested sections.
3.2.2.2.2 The specific content: <blockContainer>
Each section for which content is allowed MUST have an element <blockContainer>.
The structure of the <blockContainer> is composed of one or more of these elements:
<p>
<blockList>, composed of <item>, optionally preceded by a <listIntroduction> (introductory
part) and optionally followed by a <listWrapUp> (conclusion of the list).
table.
Example:
<tblock>
<num>•</num>
<heading>Fundamental rights</heading>
<blockContainer>
<p>Not applicable</p>
</blockContainer>
</tblock>
3.2.3 The legal text
See above, [The outcome of the OLP procedure (Regulation, Directive, Decision) and their drafts - the
<act> and the <bill> ]
AKN4EU – Volume II – PART 1 & 2
30/03/2020 Page 54 of 124
3.3 The EP Legislative Resolution (<bill name="RES_LEGIS")
The European Parliament Legislative Resolution is a document that provides, in a formal way, the
position of the Parliament on a Proposal of the Commission. The Parliament may reject the proposal
as a whole1, approve it without amendments or, most commonly, adopt amendments to the
proposal.
The European Parliament Legislative Resolution is marked as a <bill> element. This element has a
mandatory attribute @name.
The value of this attribute comes from the corresponding code from the Named Authority List
‘Resource type’ (see https://publications.europa.eu/en/web/eu-vocabularies/at-dataset/-
/resource/dataset/resource-type).
Value of the attribute @name Description
RES_LEGIS Legislative Resolution document.
The European Parliament Legislative Resolution has the following structure:
The <preface> containing the title,
The preamble
The <body> that describes the position.
Preseeding these structures, Akoma Ntoso requires an additional <meta> part grouping all metadata
associated to the document (see the section ‘The metadata part of the Akoma Ntoso document’).
3.3.1 <preface>
The preface contains the title of the document as well as additional information like the step in the
legislative procedure, the document number of related document or the procedure number.
The block containing the title MUST be marked up with the element <longTitle>. Additional
information in a specific block MUST be marked up with the element <container>.
3.3.1.1 The <longTitle>
In the Legislative Resolution, additional information on the legislative procedure is provided on the
same line as the title of the document.
In AKN4EU, the title of the document is marked-up with the element <longTitle>. This element is a container of block. As in the Legislative Resolution the title and the complementary information are rendered in the same line, there is a need to separate them:
AKN4EU – Volume II – PART 1 & 2
30/03/2020 Page 55 of 124
Inside the <p> of the <longTitle>, the <docTitle> element MUST be used to group all the content that forms the title of the document (<docType>, <date> and <docPurpose> are sub-elements of this element). Additional <inline> elements can be added at the same level as the <docTitle> for the information that is not part of the title of the document.
The element <inline> has a mandatory attribute @name that is used to define the type of information inside the element.
The <p> contains the following inline elements:
elements in <longTitle> Description
<docTitle> The part of the line that contains the title
<docType> The type of the document. The attribute @refersTo, (mandatory for act and bill), contains the reference of the TLCReference related to the type of the document.
<date> The date of the document. The mandatory attribute @date contains the date in normalized format.
<docPurpose The subject of the document. The <docPurpose> can have the following sub-elements (optional):
<ref> Marks the reference to an act mentioned in the subject of the current document. The mandatory attribute @href contains the ELI identifier of that act.
<mref> The fragment of the <docPurpose> that is common to multiple references to an act.
<inline name="relatedProc"> The part of the line that contains complementary information on the legislative procedure
<ref href=""> <docNumber>
The related document number (in general, the Com document number and the EP number for the Proposal from the Commission. Each document number can be marked with a <ref> element with the @href attribute containing the ELI URI or a <docNumber> element.
<docketNumber> The number of the procedure The @refersTo attribute contains a reference to a TLCReference element with @name=”procedureNumber”
Slovenian, Spanish and Swedish languages, each text being equally authentic.</p>
<p>IN WITNESS WHEREOF, the undersigned, duly authorised thereto, have signed
this Agreement.</p>
<p xml:lang="..">… </p>
<p xml:lang="..">… </p>
…
<block name="signatory">
<signature>
…
</signature>
…
</block>
</conclusions>
4.1.4.2 Place and date
Each linguistic variant of the place and date MUST be marked with a <p> element with the @xml:lang attribute with, as value, the two-letter code of the language of the content.
In each linguistic variant, the <location> identifies the place of the signature and the <date> element
identifies the date of the signature.
Example:
<p xml:lang="bg">Съставено в <location refersTo="~_BEL_BRU">Брюксел</location> на
<date date="2016-10-30">тридесети октомври през две хиляди и шестнадесета
година</date>.</p>
<p xml:lang="es">Hecho en <location refersTo="~_BEL_BRU">Bruselas</location>, el
<date date="2016-10-30">treinta de octubre de dos mil dieciséis</date>.</p>
…
For each value of the @xml:lang attribute, a corresponding <TLCReference name="language"> MUST
be created in the <references> section of the metadata.
For each value of the @refersTo attribute of the <location> element, a corresponding <TLCLocation>
MUST be created in the <references> section of the metadata.
The signatory MUST be marked with a <block> element. The mandatory @name attribute MUST have the value "signatory". It contains one or more <signature> elements.
For the International Agreement each <signature> element MUST contain the following sub-elements:
Sub-elements of <signature> Description
<organization>
The <organization> to identify the party of the person who signs the document.
The attribute @refersTo MUST point to the corresponding <TLCOrganization> in the <references> part of the metadata.
In case of the International Agreement, the <TLCOrganization> MUST be an entry of the Authority table ‘Country’.
The information is expressed in an official language of the country that the signatory represents. Sometimes, the information can thus be expressed in multiple linguistic versions. In any case, it is not always the language of this Expression and this information remains in the original language.
For this reason, there can be multiple occurrences of <organization> in one <signature>, one for each specific linguistic version.
The following rules apply:
If there are multiple occurrences of <organization> in one <signature>, each <organization> of a same <signature> MUST have the same @refersTo value. It means that it MUST point to the same <TLCOrganization> in the references part of the metadata.
When there are multiple occurrences of <organization>, each occurrence MUST have an @xml:lang attribute with a different value.
A corresponding <TLCReference name="language"> MUST be created.
<person>
The <person> element with an empty @refersTo. This element will contain the image of the handwritten signature.
<remark> Additional information after the handwritten signature.
For example:
<remark xml:lang="fr">Cette signature engage également la
Communauté française, la Communauté flamande, la Communauté
germanophone, la Région wallonne, la Région flamande et la
Région de Bruxelles-Capitale.
</remark>
AKN4EU – Volume II – PART 1 & 2
30/03/2020 Page 66 of 124
Example
<block name="signatory">
<signature>
<organization refersTo="_BEL" xml:lang="nl">Voor het Koninkrijk
België</organization>
<organization refersTo="_BEL" xml:lang="fr">Pour le Royaume de
Belgique</organization>
<organization refersTo="_BEL" xml:lang="de">Für das Königreich
Belgien</organization>
<person refersTo="">
<img src="L_2016329EN.01006001.tif"/>
</person>
<remark xml:lang="nl">Deze handtekening verbindt eveneens de Vlaamse
Gemeenschap, de Franse Gemeenschap, de Duitstalige Gemeenschap, het Vlaamse Gewest,
het Waalse Gewest en het Brussels Hoofdstedelijk Gewest.</remark>
<remark xml:lang="fr">Cette signature engage également la Communauté
française, la Communauté flamande, la Communauté germanophone, la Région wallonne,
la Région flamande et la Région de Bruxelles-Capitale.</remark>
<remark xml:lang="de">Diese Unterschrift bindet zugleich die
Deutschsprachige Gemeinschaft, die Flämische Gemeinschaft, die Französische
Gemeinschaft, die Wallonische Region, die Flämische Region und die Region Brüssel-
If no consolidated version exists, but the current version is not the version published in the Official Journal, the <activeRef> MUST not be used.
23
<activeRef> is the reference in relation with <activeModification>, so it references the amended act.
AKN4EU – Volume II – PART 1 & 2
30/03/2020 Page 78 of 124
6.1.2.2 The mark-up of the text of an amendment
6.1.2.2.1 The element <mod>
To encapsulate all the text of an amendment, Akoma Ntoso provides the element <mod>. Only the
text specific to one amendment is to be marked-up with the element <mod>.
Consequently, in the following example, the part in green must be in a <mod> element (there are
two <mod> in the following example):
6.1.2.2.2 The elements <quotedStructure> and <quotedText>
To encapsulate the 'text of the amendment', two elements are provided:
<quotedStructure> MUST be used if the content is a complete subdivision
<quotedStructure> MUST be used if the content is a complete annex
<quotedText> MUST be used if the content is a fragment of a subdivision (word or sentence).
Both elements have the following attributes to manage the quotation marks:
@startQuote containing the opening quotation mark of the ‘text of the amendment’,
@endQuote containing the closing quotation mark of the ‘text of the amendment’,
@inlineQuote containing the character showing continuation of a quote e.g at the beginning of each line of the quote (not used).
Examples: When the content is a complete subdivision
<quotedStructure startQuote="‘" endQuote="‘">
<point><num>(n)</num>
<content><p>“young farmer” means a person who is no more than 40 years of age at the
moment of submitting the application, possesses adequate occupational skills and competence
and is setting up for the first time in an agricultural holding as head of that holding; the
setting up may be done solely or jointly with other farmers, irrespective of its legal
form;</p></content>
</point>
</quotedStructure>
AKN4EU – Volume II – PART 1 & 2
30/03/2020 Page 79 of 124
When the content is a complete annex In this case, the <quotedStructure> MUST only contain a <documentRef> element. The @href mandatory attribute of this element MUST contain the relative path to the xml file containing the text of the annex.
If the amendment modifies a text containing a footnote, all the footnotes included inside a ‘text of an
amendment’ are displayed at the end of this ‘text of the amendment’ and the closing quotation mark
is placed just after the text of the last footnote. The numbering of the footnote is expressed by a
number of "*".
Example
The mark-up of the footnote MUST be an element <authorialNote> with the following
characteristics:
The @marker is not a number but one or more '*' (the number of '*' is the number of the
note; the numbering is related to the current ‘text of the amendment’)
The @placement MUST be "bottom"
The @placementBase MUST always reference the last element in the <quotedStructure>,
because the footnote must be displayed as last element of <quotedStructure>, just before
the closing quotation mark.
The above example will be marked up as follows (here the <quotedStructure> contains only one <paragraph> that is also the last element in the <quotedStructure>, so the @placementBase references this <paragraph>): <p><mod>in Article 62, the following paragraph is added:
<quotedStructure startQuote="‘" endQuote="‘">
<paragraph xml:id="_qstruc_1__para_5">
<num>5.</num>
<content>
<p>Member States may apply this Chapter to areas producing wine suitable for producing
wine spirits with a geographical indication as registered in accordance with Annex III to
Regulation (EC) No 110/2008 of the European Parliament and of the Council<authorialNote
placement="bottom" placementBase="~_qstruc_1__para_5" marker="*"><p>Regulation (EC) No
110/2008 of the European Parliament and of the Council of <date date="2008-01-15">15 January
2008</date> on the definition, description, presentation, labelling and the protection of
geographical indications of spirit drinks and repealing Council Regulation (EEC) No 1576/89
(OJ L 39, 13.2.2008, p. 16).</p></authorialNote>. For the purposes of this Chapter, those
areas may be treated as areas where wines with a protected designation of origin or protected
metadata element specifying the period of the application modification,
<duration>
metadata element specifying the period of the duration modification,
<condition>
metadata element specifying an open set of conditions on the modification (not managed by
Akoma Ntoso),
<previous>
used for the renumbering.
In AKN4EU the elements <old> and <new> MUST only be used in the following cases:
when the <mod> element contains multiple <quotedStructure> or multiple <quotedText>,
(with some for the old, and some for the new text), <old> and <new> are used to mark the
distinction;
when the <quotedStructure> is outside the element <mod>: for example, in case of an
amendment that inserts or replaces a complete annex (the new version of the annex is in
one annex of the amending act but the amendment is in the enacting terms), or when the
result of the amendment is provided in a consolidated version (consolidated amendment of
EP, for example).
The attribute @href of the <source> element MUST contain a reference to an element <mod>, using
the @xml:id of this element (technical reference).
6.1.2.3.2 Example
6.1.2.3.2.1 Amendment of a subdivision
Considering the following amendment:
Context: textual subdivision identifier during the drafting and after the publication of a document:
the technical and functional identifier
A technical identifier is an identifier that carries no meaning. A functional identifier is an identifier that is meaningful. It is a machine-readable form of the way the user references a subdivision, based on its location inside the document.
During the drafting process, the main feature of the identifier of a subdivision is its immutability (once initialised, never to be changed thereafter), allowing to follow the evolution of the same text throughout the drafting process. As the structure of the document evolves a lot during the drafting without necessarily following a strict formal procedure, the use of a functional (business) identifier built on the location of the subdivision does not makes sense. Therefore, the identifier of a subdivision is during the drafting, a technical identifier (@xml:id).
AKN4EU – Volume II – PART 1 & 2
30/03/2020 Page 84 of 124
After the publication of a document users (e.g. lawyers) make reference to a subdivision by providing its location in the text, especially when the document is a legal act. This makes sense as the document will not evolve a lot and any modification is formalized by amendments following a legislative procedure. Modifications never comprise implicit renumbering, so that a subdivision’s location remains correct.
ELI defines for the reference to a subdivision a syntax mapped to the business approach to the referencing. The subdivision reference is based on the CoV concepts structuring the text.
In Akoma Ntoso, the @eId attribute is provided to store the identifier used for the business reference in a well-defined structure and machine readable way. The following example of mark-up is based on this logic:
in the proposal, the identifier is the @xml:id attribute.
for the amended act already published in the Official Journal, the identifier is (for the example) stored in the @eId attribute to indicate that it corresponds to a business way to identify the subdivision. This value is used as the subdivision part of ELI reference.
The mark-up for <textualMod> (metadata) is based on the following principles:
the @type MUST be completed following the table ;
the @href attribute of the <source> element MUST reference the element <mod>;
the @href attribute of the <destination> MUST be an ELI reference to the subdivision
specified in the amendment (see the syntax for the ELI reference).
AKN4EU – Volume II – PART 1 & 2
30/03/2020 Page 85 of 124
6.1.2.3.2.2 Example of an amendment of text
The following amendment:
will be represented as follows24:
The mark-up for <textualMod> (metadata) is based on the following principles:
The @type MUST completed following the table.
The @incomplete attribute MUST be used to indicate that the change cannot be automated.
The @href attribute of the <source> element MUST reference the element <mod>.
The @href attribute of the <old> element references the element <quotedText> with the old value.
The @href attribute of the <new> element references the <quotedText> with the new value.
24
Only part of the destinations are in the mark-up.
amendment
metadata
…
AKN4EU – Volume II – PART 1 & 2
30/03/2020 Page 86 of 124
The @href attribute of the <destination> MUST be an ELI reference to the subdivision specified in the amendment (see the syntax for the ELI reference).
If multiple subdivisions are provided, two cases can be distinguished:
o uses one <destination> and the attribute @upTo to indicate the end of the interval.
o provides one element <destination> per first level subdivision of the text that is affected by the amendment.
6.1.2.3.3 Metadata for the replacement
The replacement of a structure ("substitution" as AKN type) has the following characteristics:
The ‘text of the amendment’ MUST be in a <quotedStructure>.
The corresponding <textualMod> in the <activeModification> has the following
characteristics:
o The @type of the <textualMod> MUST have the value "substitution".
o The @href of the <source> MUST point to the corresponding <mod> element.
o The @href of the <destination> sub-element MUST point to the structure of the
amended act, that is referenced in the amendment.
o If a range of structures is modified, two options are available to specify the
destination:
there is one <destination> sub-element and the @upTo attribute of this
element points to the last structure modified in the amended act.
there is one <destination> per first level of subdivision modified.
6.1.2.3.4 Metadata for the insertion
The insertion of a structure ("insertion" as AKN type) inserts a new structure before or after an
already existing structure. As the principle of the amendment is to never renumber the existing
structure, the insertion uses a specific type of numbering.
For the insertion, the characteristics are as follows:
The 'text of the amendment' MUST be in a <quotedStructure>.
The corresponding <textualMod> in the <activeModification> has the following
characteristics:
o The @type of the <textualMod> MUST have the value "insertion".
o The @href of the <source> MUST point to the corresponding <mod> element.
o The <destination> sub-element has the following attributes:
The @href MUST point to the structure indicated in the amendment as the
reference structure.
The @pos MUST be used with the following value:
"after" if the referenced structure is the preceding structure;
AKN4EU – Volume II – PART 1 & 2
30/03/2020 Page 87 of 124
"start" if the referenced structure is the parent structure;
"before" if the referenced structure is the following structure.
6.1.2.3.5 Metadata for the addition
The addition of a structure ("insertion" as AKN type) adds a new structure at the end of an existing
structure. In this case, if the new structure is a numbered structure, it is an increment of the last
sibling structure.
For the addition, the characteristics are as follows:
The 'text of the amendment' MUST be in a <quotedStructure>.
The corresponding <textualMod> in the <activeModification> has the following
characteristics:
o The @type of the <textualMod> MUST be the value "insertion".
o The @href of the <source> MUST point to the corresponding <mod> element.
o The <destination> sub-element has the following attributes:
The @href MUST point to the parent structure.
The @pos MUST be used with the value "end" = insert at the end of the
parent structure.
6.1.2.3.6 Metadata for the deletion
For the deletion, the characteristics are as follows:
There is no text of the amendment.
The corresponding <textualMod> in the <activeModification> has the following
characteristics :
o The @type of the <textualMod> has the value "repeal".
o The @href of the <source> points to the corresponding <mod> element.
o the <destination> element has the following attribute:
the @href points to the structure to be deleted.
In case of deletion of an interval of subdivisions, two alternative mark-ups are
possible:
One <destination> element with the @href attribute pointing to the start of
the interval and @UpTo attribute pointing to the end of the interval.
Multiple <destination> elements (one per subdivision of the sequence), each
with the @href attribute pointing to the corresponding subdivision (no
@upTo attribute used in this case).
AKN4EU – Volume II – PART 1 & 2
30/03/2020 Page 88 of 124
Example 1:
<point> <num>(c)</num> <content>
<p><mod xml:id="_a123od">paragraph 3 is deleted<inline name="punctuationMod>;</inline></mod></p>
6.1.2.4.1 Modification of the first unnumbered structure of a numbered structure
When the first substructure of a modified structure is on the same line as the number of the
englobing structure, generally, the whole line is included in the quoted structure, including this
number.
In this case, the mark-up in the <quotedStructure> MUST be isolate in two sibling elements, the
amended text and the contextual text (generally the number of the parent structure) like in the
following examples:
The corresponding mark-up will be as follows:
<p><mod xml:id="_a123od">in paragraph 3, the first subparagraph is replaced by the following: <quotedStructure xml:id="_qstruc_1" startQuote="‘" endQuote="‘">
<num>3.</num> <subparagraph> <content> <p>The authorities or bodies selected to provide advice shall have appropriate resources in the form of regularly trained and qualified staff and advisory experience and reliability with respect to the fields in which they advise. The providers under this measure shall be chosen through a selection procedure open to both public and private bodies. That selection procedure shall be objective and shall exclude candidates with conflicts of interest.</p> </content> </subparagraph>
<point> <num>(a)</num> <content> <p><mod xml:id="_a123od">in paragraph 1, the introductory part is replaced by the following: <quotedStructure xml:id="_qstruc_1" startQuote="‘" endQuote="‘">
<num>1.</num> <intro> <p>Support under this measure shall cover new participation, or participation in the five preceding years, by farmers and groups of farmers, in:</p> </intro>
6.1.2.4.5.2 In the corresponding annex of the amending act
In this case, the content of the annex is the new annex. For example:
ANNEX II
‘
ANNEX V
LIST OF RESIDENCE PERMITS ENTITLING THE HOLDER TO TRANSIT THROUGH THE AIRPORTS OF
MEMBER STATES WITHOUT BEING REQUIRED TO HOLD AN AIRPORT TRANSIT VISA
…..
… .’.
In this case, the annex MUST contain:
the heading of the annex with its numbering; then
between quotation marks, the new annex;
finally, (optionally) the last punctuation mark. The new annex MUST be marked-up by a <quotedStructure> element inside a <mod> element. The <mod> MUST contain also the last punctuation mark. If it exists, it MUST be in an <inline name="punctuationMod"> element. <mod> is the only content of the <paragraph> element. As one of the rules in AKN4EU is to not allow subdocument inside document, the content of the annex as amended is not put directly in the annex of the amending act, but is in a specific file. The relative path MUST be referenced in this annex in the @href attribute of the element <documentRef>.
7.2 Reference to subdivision in ELI URI templates (!!! draft !!!)
The ELI subdivision in the ELI URI templates must be built on a generic, format-independent
reference, based on the Common Vocabulary. The objective is to ensure that for an EU act, the
subdivision used reflects the vocabulary used by drafters/users, is standardised and machine
readable and can be interpreted uniquely.
For the current draft, the following syntax is used :
The information on the subdivision is inserted just after the part identifying the document.
When a succession of subdivision is needed, each subdivision information is separated by a
"/".
For example :
http://data.europa.eu/eli/dir/2000/31/art_1/par_2
The type of subdivision is separated from the number by using an "_";
The acronym for the subdivision type of an act is the following :
article art
chapter cpt
citation cit
clause cls
enacting terms enc
footnote ftn
indent idt
numbered or unnumbered paragraph par
part prt
point pnt
preamble pbl
recital rct
section sec
subject tit
subparagraph sub
subsection sbs
table tab
title tis
"TEC" subdivision : reference in ELI subdivision using @xml:id (!!! early draft !!!)
AKN4EU – Volume II – PART 1 & 2
30/03/2020 Page 114 of 124
To allow to use ELI reference for preparatory acts that have been finalized (for example, Proposal)
with the subdivision reference specified using technical id, a special subdivision is defined : "TEC".
The number contains the value of an @xml:id
for example :
"…/eli/prop_act/2014/123/TEC_ eiroz158
It references the subdivision with @xml:id attribute with the value "eiroz158" of the document
COM(2014) 123.
AKN4EU – Volume II – PART 1 & 2
30/03/2020 Page 115 of 124
PART 2. Correspondence between CoV 3.0 and AKN4EU 3.0
CoV terms or business rules Akoma Ntoso mark-up
acting entity
COV DESCRIPTION
Indicates the name of the acting entity or entities of a document.
<formula name = "actingEntity">
no correspondence in CoV
DESCRIPTION
"textual amendment"
<mod>
annex
COV DESCRIPTION
Annexes in the strict sense are used to present material separately from the body of the enacting terms, because it is voluminous or technical or both [JPG 22.1.].
<doc name = "ANNEX">
IS REFERENCED BY
<attachments>/<attachment>/<documentRef>/@href in <act> or <bill> or <doc>
article
COV DESCRIPTION
Basic unit of the enacting terms of a legal act [ JPG 15.4.]
<article>
article on definition
COV DESCRIPTION
By way of exception, in the article on definitions and in amending provisions, if there is more than one definition or amendment, the numbering of points starts with Arabic numerals within brackets for the first level.
<article> with the @refersTo attribute pointing to the <TLCConcept> with the @href attribute= "http://publications.europa.eu/resource/subdivision-content/ART_DEF">
article with amendments
COV DESCRIPTION
By way of exception, in the article on definitions and in amending provisions, if there is more than one definition or amendment, the numbering of points starts with Arabic numerals within brackets for the first level.
<article> with the @refersTo attribute pointing to the <TLCConcept> with the @href attribute= "http://publications.europa.eu/resource/subdivision-content/ART_AMEND".
cell
COV DESCRIPTION
Individual unit, within a table, used for
<td>
AKN4EU – Volume II – PART 1 & 2
30/03/2020 Page 116 of 124
displaying data. chapter
COV DESCRIPTION
Indicates a level of higher subdivisions of an act [JPG 15.4.].
<chapter>
citation
COV DESCRIPTION
Sets out the legal basis of an act or a main step in the procedure leading to its adoption [JPG 9.].
<citation> (possibility to qualify a citation as legal basis)
CONTEXT: <citations>
closing part
COV DESCRIPTION
In a sentence including an enumeration of points or indents, the part following that enumeration.
<wrapUp>
CONTEXT: <list>
<listwrapUp>
CONTEXT: <blockList>
column
COV DESCRIPTION
Represents, in a table, a set of related data vertically.
no specific mark-up
column header
COV DESCRIPTION
Table cell used to indicate the subject of a column.
<th> for any cell considered as a 'header'
date
COV DESCRIPTION
Identifies a specific day in time.
<date>
decision
COV DESCRIPTION
Legal act of the European Union described in the fourth paragraph of Article 288 TFEU.
<act name="DEC">
direct applicability
COV DESCRIPTION
Corresponds, in Regulations, to the special formula used after the final article as regards the binding and directly applicable nature.
<clause> in <body>
CONTEXT:
<act name="REG">
<bill name="REG">
directive
COV DESCRIPTION
Legal act of the European Union specified in
<act name ="DIR">
AKN4EU – Volume II – PART 1 & 2
30/03/2020 Page 117 of 124
Article 288 TFEU. eea relevance
COV DESCRIPTION
Indicates that the subject-matter of the act is governed by the Agreement on the European Economic Area (EEA) [JH A, p.1].
<container name="eeaRelevance">
emblem
COV DESCRIPTION
Graphical element identifying an entity
<container name ="logo">/<img>
enacting formula
COV DESCRIPTION
Indicates the text between recitals and enacting terms
<formula name = "enactingFormula">
CONTEXT: <preamble>
enacting terms
COV DESCRIPTION
Operative part of the act.
<body>
CONTEXT: <act> or <bill>
EP consolidated text
COV DESCRIPTION
Consolidated version of European Parliament's position after first or second reading in the context of the ordinary legislative procedure.
to be defined
EP legislative resolution
COV DESCRIPTION
European Parliament's position on a given draft legislative act.
<bill name="RES_LEGIS">
<bill name="DRAFT_RES_LEGIS"> for the draft version
EP legislature
COV DESCRIPTION
Indicates the European Parliament legislative term.
to be defined
EP text adopted
COV DESCRIPTION
Resolution adopted by the European Parliament giving its position in the context of a given
procedure.
to be defined
AKN4EU – Volume II – PART 1 & 2
30/03/2020 Page 118 of 124
explanatory memorandum
COV DESCRIPTION
Document which accompanies all Commission proposals submitted to the Council or to the European Parliament and the Council. It explains the context, justifications and foreseen impact of the Commission's proposal based on the different stages of the preparatory process.
<doc name = "EXPL_MEMORANDUM">
IS REFERENCED BY
<documentCollection name ="PROP_ACT">/ <collectionBody>/<component>/<documentRef>/@href
figure
Indicates an image supplemented by related text..
<subdivision> with the @refersTo attribute pointing to the <TLCConcept> with the @href attribute= "http://publications.europa.eu/resource/subdivision/FIGURE".
heading
COV DESCRIPTION
Numbering, accompanied by a term, if any.
<num>
<inline name = "num">
CONTEXT: <doc name ="ANNEX">/<preface>/ <container name="headerOfAnnex">
image
JPG DESCRIPTION
Graphical element depicting an object which
may contain alphanumeric data.
Note: Alphanumeric data contained in an image should always be editable..
<img>
indent
COV DESCRIPTION
Indicates each element of an enumeration preceded by a dash.
<indent>
CONTEXT: <list>
<item>
CONTEXT: <blocklist>
international agreement
COV DESCRIPTION
Indicates agreements concluded by the European Union with third parties and agreements concluded jointly by the Member States and the European Union with third parties.
<act name ="AGREE_INTERNATION">
introduction to the recitals
COV DESCRIPTION
Indicates the word 'whereas' at the beginning of the statement of the reasons [JPG 10.1.].
<recitals>/<intro>
AKN4EU – Volume II – PART 1 & 2
30/03/2020 Page 119 of 124
introductory part
COV DESCRIPTION
One or more sentences or phrases in the
beginning of a paragraph, or of a subparagraph, or
of a point, preceding an enumeration (of points or
indents) and ending with a colon.
<intro>
CONTEXT: <list>
<listIntroduction>
CONTEXT: <blockList>
legal basis
COV DESCRIPTION
The provision(s) which directly confer competence to adopt the act, whether preceded or not by a general reference to the Treaty/ies.
<citation>/@refersTo that points to <TLCReference name="legalBasis">
legend
COV DESCRIPTION
Text detailing the meaning of the elements of an image, a table or a scientific formula it relates to.
to be defined
logo
COV DESCRIPTION
Graphic(al) element identifying an entity consisting of the emblem of the entity complemented by the name of the entity (author/proponent).
<container name = "logo">
note
COV DESCRIPTION
Consists of additional information giving further explanation/details to the reader.
<authorialNote>
numbered paragraph
COV DESCRIPTION
Indicates an independent subdivision of an article [JPG 15.4. (table)]
<article>/<paragraph>
<paragraph> must contain as first sub-element <num>
numbering
COV DESCRIPTION
Indicates the number or letter used for structural identification [JH C.9.3.2., p. 29].
inside <num>
AKN4EU – Volume II – PART 1 & 2
30/03/2020 Page 120 of 124
part
COV DESCRIPTION
Indicates the highest level of higher subdivisions of an act [JPG 15.4.] or of an annex.
<part>
place and date
COV DESCRIPTION
Indicates the date of signature for acts adopted by ordinary legislative procedure, the budget and budget decisions adopted by the European Parliament and the Council [JPG 8.6. (4)] or the date of signature of other acts as well as the place.
<conclusions>/<p>
CONTEXT: <act> or <bill>
<preface>/<block name = "placeAndDate">
CONTEXT: <documentCollection name ="PROP_ACT">
point
COV DESCRIPTION
Indicates each element of an enumeration under a paragraph or a subparagraph (this enumeration being generally preceded by an introductory phrase) or the basic unit generally used for the provisions of an annex
<list>/<point>
<blocklist>/<item>
<level>
CONTEXT: <doc name="ANNEX">
preamble
COV DESCRIPTION
Part of an act after the title of the act including the citations, the recitals and the solemn forms preceding the enacting terms.
<preamble>
procedure identifier
COV DESCRIPTION
Unique reference number for the interinstitutional procedures.
Code or full wording indication of the stage of a procedure.
<inline name = "procedureStage">
proposal for a decision
COV DESCRIPTION
Version of a decision as issued by the proposing
entity or the consideration of its adoption by the
acting entity.
<documentCollection name="PROP_ACT">
Inside, it exists a <bill name="DEC.">
AKN4EU – Volume II – PART 1 & 2
30/03/2020 Page 121 of 124
proposal for a directive
COV DESCRIPTION
Version of a directive as issued by the proposing
entity or the consideration of its adoption by the
acting entity.
<documentCollection name="PROP_ACT">
Inside, it exists a <bill name="DIR">
proposal for a regulation
COV DESCRIPTION
Version of a regulation as issued by the proposing
entity or the consideration of its adoption by the
acting entity.
<documentCollection name="PROP_ACT">
Inside, it exists a <bill name="REG">
proposing entity
COV DESCRIPTION
Name of the proponent institution.
<coverPage>/<container name="logo">
quotation (changed)
COV DESCRIPTION
Quoted passage of words of third parties reported in the text.
<embeddedText>
<embeddedStructure>
recital
COV DESCRIPTION
Recitals set out concise reasons for the chief provisions of the enacting terms [JPG 10.]
<recital>
reference
COV DESCRIPTION
Identifier assigned to a document by an entity.
<block name="reference">/<docNumber> The reference of the current document
<container name="crossReferences">/<ref> The reference of the documents referenced
regulation
COV DESCRIPTION
Legal act of the European Union specified in Article 288 TFEU.
<act name="REG">
row
COV DESCRIPTION
Represents, in a table, a set of related data horizontally.
<tr>
AKN4EU – Volume II – PART 1 & 2
30/03/2020 Page 122 of 124
row header
COV DESCRIPTION
Table cell used to indicate the subject of a row.
<th> for any cell considered as a 'header'
scientific formula
COV DESCRIPTION
Indicates a complex technical or scientific expression.
<foreign> when the scientific formula is represented in MathML
<inline name=" mathTex "> when the scientific formula is in Latex
section
COV DESCRIPTION
Indicates the lowest level of higher subdivisions (JPG 15.4).
<section>
CONTEXT: <body> of <act> or <bill> or <mainBody> of <doc name = "ANNEX">
<tblock>
CONTEXT: <mainbody> of <doc name = "EXPL_MEMORANDUM">
signatory
COV DESCRIPTION
Information concerning the signing authority/person.
<block name = "signatory">
signature
COV DESCRIPTION
Includes the place and date of the signature of an act as well as the information about the signatory.
<conclusions>
subject
COV DESCRIPTION
Terms reflecting the essential topic of the subdivision of text they precede.
<heading>
<inline name = "num">
CONTEXT: <doc name ="ANNEX">/<preface>/ <container name="headerOfAnnex">
subparagraph
COV DESCRIPTION
Indicates the first level of an unnumbered subdivision of a numbered paragraph, point or indent, where there are at least two of such elements of subdivision. A single subparagraph is consequently not marked-up.
<subparagraph>
CONTEXT: <paragraph>
<alinea>
CONTEXT: <point> or <indent>
<list>
when it contains <point> or <indent >
<subdivision>
when it contains complex structure on <img> or <table>
AKN4EU – Volume II – PART 1 & 2
30/03/2020 Page 123 of 124
sub-section
COV DESCRIPTION
Indicates, in exceptional cases and in long and highly structured texts, the division of a section.
<subsection (deprecated)>
table
COV DESCRIPTION
Indicates an arrangement of data in rows and columns, possibly preceded by a heading.
<table> if it is not preceded by a heading
<subdivision> with @refersTo attribute attribute pointing to the <TLCConcept> with the @href attribute= "http://publications.europa.eu/resource/subdivision/TABLE">
text of the amendment
COV DESCRIPTION
Text to be inserted in the act to be amended in accordance with an amending instruction referring to insertion, addition or replacement.
<quotedStructure>
<quotedText>
text to be amended
COV DESCRIPTION
Text in the act to be amended.
to be defined
title
COV DESCRIPTION
Indicates in long and highly structured texts the grouping of higher subdivisions [JPG 15.4., p. 28].
<title>
title of the document
COV DESCRIPTION
The title of the document comprises all the information in the heading of the document which serves to identify it (JPG 7.1).
<longTitle>
CONTEXT: <preface>
type of document
COV DESCRIPTION
Indication of the type of document.
<docType>
NB: Not totally mapped to Common Vocabulary : when the document is a proposal for an act, use <docStage> for this indication.
AKN4EU – Volume II – PART 1 & 2
30/03/2020 Page 124 of 124
unnumbered paragraph
COV DESCRIPTION
Indicates the sole element or a non-independent element of an article [JPG 15.4. (table)] or exceptionally an element of an annex.