The eAIP DTD 1.0.3 is the current stable release. This means that it can be used to produce an eAIP or to develop software based on it without the risk of loosing pace with the eAIP DTD development.
Obviously, a stable release does not mean that the DTD will never be changed. Subsequent eAIP development will result in new versions being published:
major updates, which greatly transforms the structure of an eAIP document, will receive major version numbers: 2.0, 3.0, etc.
changes in the content model that keep the general structure but invalidate previous eAIP will receive minor version numbers: 1.1, 1.2, etc.
small changes, which do not invalidate a previous minor version, will have sub-minor version numbers such as 1.0.4, 1.0.5, etc.
At the time of the writing, there were no plans for such changes. Any future changes will be implemented only after consultation with the eAIP Specification stakeholders.
Compliance with the EUROCONTROL eAIP Specification 1.0.3 may be claimed for eAIP instances that:
are valid against the eAIP DTD 1.0.3 and
follow the additional rules;
A software product may be declared compliant with the EUROCONTROL eAIP 1.0.3 Specification if it can handle/produce/edit/etc. compliant eAIP documents.
To formally validate an eAIP means to validate it against the official DTD published on EUROCONTROL's Web site, at the address defined in the Location section and then to check the eAIP for additional rules compliance.
MakeAIP is a batch script provided within the eAIP package. It allows to check compliance to both the eAIP DTD and the additional rules. Please refer to the MakeAIP Documentation for more details. If MakeAIP is properly configured, typing MakeAIP validator will check compliance to the DTD and report any error; then it will automatically run MakeAIP schematron, which is described below. The Validator will not explicitly report compliance.
Note that MakeAIP validates an eAIP against the DTD declared in the eAIP itself, which is generally a local copy of the DTD.
Most XML editing software are able to validate an eAIP against its DTD, but not against the additional rules. Therefore, the eAIP package includes an interactive tool, based on Schematron, which is able to list additional rules validation errors. To use it, follow these 2 steps:
Run MakeAIP schematron
Open or reload the file ../../tools/Validator/schematron-frame.html
This tool shows the list of errors in the upper part of the browser window and the whole XML source of your eAIP in the bottom part. When you click on an error, the bottom part is scrolled to the place where the error occurs. Each error is presented with a link to the eAIP Specification, precisely to the rule related to the error.
To see how such a report looks like, please see the eAIP Specimen's additional rules validation report. When downloading the eAIP package, it is necessary to generate that report for the first time: open a command-prompt window, change directory to where the eAIP package is installed and type MakeAIP schematron. The eAIP Specimen contains a lot of errors with respect to the additional rules; most of them are there to check the validation process.
As the baseline, the eAIP should be published in three formats: XML, HTML (for browsing) and PDF (for printing). The compliance can be formally checked only for the XML format.
Through the use of the Extensible Markup Language (XML), the eAIP data content is completely separated from presentation, which, in turn, may be tailored to every target media. While the capability to fine-tune the eAIP presentation for every media (paper, CD-ROM, Web, etc.) is an advantage for the users, it is also a challenge for the producers. They must ensure the consistency between the different formats. Most likely, the reference format is XML. However, depending on the legislation in force in the issuing State and/or the user's State, it might be that another format (for example PDF or the paper document) is declared as the reference format. This is important in case of discrepancies between the different formats. The producer shall clearly state which of the different formats (XML, HTML, PDF, etc.) should be considered as prevailing in case of discrepancies.
The eAIP Specification is composed of a DTD and "additional rules".
The stylesheets used for converting XML into HTML, which complement the specification, are not imposed. However, the eAIP user community expects uniformity in the layout and navigation structure of all eAIP implementations. This can be achieved through a consistent application of the EUROCONTROL eAIP stylesheets.
The official location of the eAIP DTD is http://www.eurocontrol.int/ais/eaip/dtd/[version number]/eAIP.dtd. For example, the DTD version 1.0.3 is located at http://www.eurocontrol.int/ais/eaip/dtd/1.0.3/eAIP.dtd. This URL is only useful to software tools which need to access the official DTD: it is not convenient for downloading the DTD, as it is composed of some 35 files. The DTD is part of the eAIP package, which is available for download on the eAIP Web site. The DTD is not easy to read, even for XML developers, because it makes use of XHTML Modularisation. The DTD documentation is much more accessible.
The eAIP DTD defines a number of 245 XML elements. They are listed below, grouped by category.
The root elements are e:eAIP for an AIP document, e:eSUP for a Supplement document and e:eAIC for a Circular. All other elements are descendants of these three roots in the element hierarchy.
Table 3.1. eAIP structure overview
| eAIP | GEN | GEN-0 | GEN-0.1, GEN-0.2, GEN-0.3, GEN-0.4, GEN-0.5, GEN-0.6 |
| GEN-1 | GEN-1.1, GEN-1.2, GEN-1.3, GEN-1.4, GEN-1.5, GEN-1.6, GEN-1.7 | ||
| GEN-2 | GEN-2.1, GEN-2.2, GEN-2.3, GEN-2.4, GEN-2.5, GEN-2.6, GEN-2.7 | ||
| GEN-3 | GEN-3.1, GEN-3.2, GEN-3.3, GEN-3.4, GEN-3.5,GEN-3.6 | ||
| GEN-4 | GEN-4.1, GEN-4.2 | ||
| ENR | ENR-0 | ENR-0.1, ENR-0.2, ENR-0.3, ENR-0.4, ENR-0.5, ENR-0.6 | |
| ENR-1 | ENR-1.1, ENR-1.2, ENR-1.3, ENR-1.4, ENR-1.5, ENR-1.6, ENR-1.7, ENR-1.8, ENR-1.9, ENR-1.10, ENR-1.11, ENR-1.12, ENR-1.13, ENR-1.14 | ||
| ENR-2 | ENR-2.1, ENR-2.2 | ||
| ENR-3 | ENR-3.1, ENR-3.2, ENR-3.3, ENR-3.4, ENR-3.5, ENR-3.6 | ||
| ENR-4 | ENR-4.1, ENR-4.2, ENR-4.3, ENR-4.4 | ||
| ENR-5 | ENR-5.1, ENR-5.2, ENR-5.3, ENR-5.4, ENR-5.5, ENR-5.6 | ||
| ENR-6 | — | ||
| AD | AD-0 | AD-0.1, AD-0.2, AD-0.3, AD-0.4, AD-0.5, AD-0.6 | |
| AD-1 | AD-1.1, AD-1.2, AD-1.3, AD-1.4 | ||
| AD-2, Aerodrome | AD-2.1, AD-2.2, AD-2.3, AD-2.4, AD-2.5, AD-2.6, AD-2.7, AD-2.8, AD-2.9, AD-2.10, AD-2.11, AD-2.12, AD-2.13, AD-2.14, AD-2.15, AD-2.16, AD-2.17, AD-2.18, AD-2.19, AD-2.20, AD-2.21, AD-2.22, AD-2.23, AD-2.24 | ||
| AD-3, Heliport | AD-3.1, AD-3.2, AD-3.3, AD-3.4, AD-3.5, AD-3.6, AD-3.7, AD-3.8, AD-3.9, AD-3.10, AD-3.11, AD-3.12, AD-3.13, AD-3.14, AD-3.15, AD-3.16, AD-3.17, AD-3.18, AD-3.19, AD-3.20, AD-3.21, AD-3.22, AD-3.23 |
Affects, Amendment, Deleted, eAIP-reference, Inserted, See-supplement (deprecated), Supplement.
Abbreviations: Abbreviation, Abbreviation-description, Abbreviation-details, Abbreviation-ident.
Locations: Location, Location-definition, Location-ident, Location-name, Location-table.
Routes: Route, Route-designator, Route-remark, Route-RNP.
Segment: Route-segment, Route-segment-airspace-class, Route-segment-ATC, Route-segment-COP, Route-segment-length, Route-segment-lower, Route-segment-lower-override, Route-segment-minimum, Route-segment-remark, Route-segment-remark-reference, Route-segment-RNP, Route-segment-upper, Route-segment-width, Route-segment-mag-track, Route-segment-reverse-mag-track, Route-segment-reverse-true-track, Route-segment-true-track, Route-segment-usage, Route-segment-usage-reference, Route-segment-usage-direction, Route-segment-usage-level-type.
Significant point: Significant-point-ATC, Significant-point-description, Significant-point-reference, Significant-point-remark, Significant-point-remark-reference, Navaid-indication, Navaid-indication-distance, Navaid-indication-radial.
Navaids: Navaid, Navaid-declination, Navaid-elevation, Navaid-frequency, Navaid-hours, Navaid-ident, Navaid-magnetic-variation, Navaid-name, Navaid-remarks, Navaid-table, Navaid-type.
Designated points: Designated-point, Designated-point-ident, Designated-point-table, SID-STAR.
Addresses: Address, Address-part. Graphics: Figure, Graphic-file. Misc. block: Generated, NIL, Sub-section, Title. Misc. inline: Date-time, Latitude, Longitude.
The following elements are taken from the W3C XHTML Modularisation Recommendation specification. They are functionally equivalent to their corresponding elements in the HTML 4.01 Recommendation, with the exception that most deprecated HTML attributes are not used in the eAIP DTD.
Block elements: div, p.
In-line elements: a, br, cite, em, span, strong.
List elements: li, ol, ul.
Table elements: caption, col, colgroup, table, tbody, td, tfoot, th, thead, tr.
The current list of additional rules is based on the experience gathered through the eAIP Pilot Implementations. In future, this list is expected to be extended. All the rules listed below are implemented in the eAIP Validator, which can be found in the tools directory of the eAIP package.
There are two sets of rules:
Mandatory Rules are part of the eAIP Specification and must be followed;
Optional Rules are not part of the eAIP Specification; they are only recommendations.
The eAIP "language" is composed of a vocabulary (elements, attributes, lists of values), which is entirely defined in the DTD, and a grammar, which is split between the DTD and the additional rules. This grammar split is due to limitations of the DTD technology, which does not allow to express all the necessary constraints. As many constraints as technically possible have been put in DTD. In future, it might be decided to replace the DTD with an XML Schema. Even than, some additional rules might be needed, due to the inherent limitations of any schema language.
The eAIP Specification defines the additional rules in plain English. An implementation of these rules, in Schematron language, is provided in the eAIP package, in the file ..\..\tools\Validator\eAIP-schematron.xml, which is located in the tools/Validator directory in the eAIP package. Schematron is another XML grammar language, like DTD and XML Schema. It is undergoing ISO standardization to become "ISO/IEC 19757 - DSDL Document Schema Definition Language - Part 3: Rule-based validation - Schematron". A Schematron grammar is written in XML and is able to express certain rules that DTDs and XML Schemas can't. For more information about Schematron, please refer to the Schematron home page.
Route segments within the same route may not have mixed true track and magnetic track.
A Route sequence of Significant-point-reference and Route-segment elements must begin and end with a Significant-point-reference
The first non-deleted element following a non-deleted Route-segment must be a Significant-point-reference. The same assertion may be made about non-inserted ones, but we should expect the eAIP to be valid before the amendment anyway.
The first (if any) non-deleted element following a non-deleted Significant-point-reference must be a Route-segment. The same assertion may be made about non-inserted ones, but we should expect the eAIP to be valid before the amendment anyway.
If there are 2 Graphic-file elements inside a Figure element, their Updated attribute must be Inserted for one and Deleted for the other one.
Elements, whose Updated attribute has a value different than "No", must have an id and an Updated-ref attributes
Amendments may not be nested. This means that any element whose Updated attribute is different than "No" may not have a descendant whose Updated attribute is different than "No".
If a NIL element has following sibling(s), it must have its Updated attribute set to Inserted or Deleted and they must have it set to the opposite.
An element whose Toc attribute is set to "Yes" must have an id attribute.
The Type attribute of Graphic-file elements must contain a "known" MIME type. The list of known MIME types is given in XML format in the file mime-types.xml (in directory tools/Validator in the eAIP package). All eAIP software implementation must be able to handle these MIME types.
If the xlink:show attribute on e:Graphic-file is set to "replace" or "new", then attribute Page-name must not be empty.
Internal links (x:a elements with a href attribute value beginning with "#") must point to an existing element. That is, the value after the "#" character must be the id of an element in the same eAIP document.
Internal references must refer to an existing element, depending on the referrer:
An Abbreviation must refer to an Abbreviation-description;
A Location must refer to a Location-definition
A Significant-point-reference must refer to a Navaid or a Designated-point
A Significant-point-remark-reference must refer to a Significant-point-remark
A Route-segment-usage-reference must refer to a Route-segment-usage
A Route-segment-remark-reference must refer to a Route-segment-remark
An Aerodrome must refer to a Location-definition
A Heliport must refer to a Location-definition
The Updated-ref attribute must refer to an Amendment
Legal values are: "Request", "Compulsory" and "No-report" and they must be expressed inside a single text node. These values can be inside child elements (typically e:Deleted and e:Inserted), but no other text is allowed. Text inside e:Deleted elements is not considered for this rule (as it must have been valid before the amendment).
Legal values are: "Forwards" and "Backwards". These values can be inside child elements (typically e:Deleted and e:Inserted), but no other text is allowed. Text inside e:Deleted elements is not considered for this rule (as it must have been valid before the amendment).
Legal values are: "Odd" and "Even". These values can be inside child elements (typically e:Deleted and e:Inserted), but no other text is allowed. Text inside e:Deleted elements is not considered for this rule (as it must have been valid before the amendment).
Location-name must not be empty.
Location-ident must exist and not be empty if its parent Location-definition's Type attribute is set to "ICAO".
If a route segment has at least one child Route-segment-usage-reference of value "Forwards" (respectively, "Backwards"), then the route segment should have a Route-segment-true-track (resp. Route-segment-reverse-true-track) or a Route-segment-mag-track (resp. Route-segment-reverse-mag-track) element.
It is a good idea to set the id attribute on an element whose Number attribute is not empty (Number creates a reference for humans but not for computers)
The following element and attribute are deprecated and will be removed from the eAIP DTD in the future. Please refer to the eAIP DTD documentation for more details.
e:Location's Type attribute
Elements eAIC and eSUP may omit their Effective-date attribute, but it is not recommended.
The a element's href attribute is not mandatory, but it should be provided in order for this element to be meaningful. Note that, contrary to HTML, you should not define an anchor using the name attribute, but instead use an id attribute on the element you want to refer to.
The eAIP Specification includes XSLT and CSS style sheets, to format an eAIP in a standard way. These style sheets are not mandatory. EUROCONTROL recommends the use of these style sheets in order to promote a consistent visual eAIP format for users. There is a set of style sheets for HTML format and another set for PDF.
The style sheets are part of the eAIP package.
The following license applies to this EUROCONTROL work (including source
code, document type definitions, documents, or other related items):
Editorial note: this license is an instance of the BSD license template as
provided by the Open Source Initiative:
http://www.opensource.org/licenses/bsd-license.php
===========================================================================
Copyright (c) 2000-2004, EUROCONTROL
All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
* Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
* Neither the name of EUROCONTROL nor the names of its contributors
may be used to endorse or promote products derived from this software
without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.
===========================================================================
Additionally, parts of this work have their own copyright:
XHTML:
------
XHTML Modularization by the World Wide Web Consortium:
Copyright 1998-2001 W3C (MIT, INRIA, Keio), All Rights Reserved.
The full text of the "W3C SOFTWARE NOTICE AND LICENSE" is available at
http://www.w3.org/Consortium/Legal/copyright-software-19980720 and in the
file LICENCE_W3C.html. To comply with W3C's license (item 3), all changes
to XHTML Modularization files are detailed in the file xhtml-changes.txt in
the DTD directory.
Saxon:
------
The eAIP package includes the SAXON XSLT Processor from Michael Kay, but
only its binary jar file, extracted from the saxon.zip distribution,
version 6.5.3. The whole Saxon distribution, including documentation and
source code, is available at http://saxon.sourceforge.net/.
Saxon is subject to Conditions of Use, available at
http://saxon.sourceforge.net/saxon6.5.3/conditions.html and copied to
the file tools/saxon/LICENSE_Saxon.html.
Xerces:
-------
The eAIP package includes software developed by the Apache Software
Foundation (http://www.apache.org/), namely Xerces, an XML parser.
Its license is available in the file tools/xerces/License.
Schematron:
-----------
The eAIP package includes the Schematron 1.5 tools, which are copyrighted
by David Calisle, Oliver Becker, Rick Jelliffe and Academia Sinica
Computing Center, Taiwan. These tools were slightly modified by Benoit
Maisonny for the eAIP. The original versions are available at
http://www.ascc.net/xml/resource/schematron/.
The licence is located at the top of each file in the directory
tools/schematron.
OpenSSL:
--------
This product (the eAIP package) includes software developed by the OpenSSL
Project for use in the OpenSSL Toolkit. (http://www.openssl.org/)
Copyright (c) 1998-2003 The OpenSSL Project. All rights reserved.
The whole OpenSSL distribution, including documentation and source code,
is available at this Web site. Only the binaries are included in the eAIP
package.
Its license is available in the file tools/OpenSSL/License.
GnuPG:
------
The eAIP package includes the GnuPG software, which is Copyright 1998,
1999, 2000, 2001, 2002, 2003 Free Software Foundation, Inc. The whole
GnuPG distribution, including documentation and source code, is available
at http://www.gnupg.org/, and also on the eAIP Web site. Only the binaries
are included in the eAIP package.
Its license is available in the file tools/GnuPG/Copying.