At the time of this project, aeronautical data was available for most European States structured according to AIXM 4.5, from the EAD database. The set of Business Rules defined by AIXM 4.5 was used in order to validate the data provided to the EAD and in the national database systems.
In 2010, the data provider systems started to gradually move towards AIXM 5.x, which is much richer and supports digital NOTAM applications. There was consequently a need for a set of AIXM 5.x business rules to help validate AIXM 5.x data.
As opposed to the previous versions, AIXM 5.x does no longer specify mandatory properties or associations for a feature. The reasons are both technical (to enable the encoding of “Delta” TimeSlices) and the desire for increased flexibility.
Many applications have different needs with regard to the minimal list of feature properties. Therefore, such structural business rules needed to be captured as AIXM 5.x business rules.
As of mid-august 2010, the Business Rules Database contained around 2.100 business rules. All these rules have been produced using mainly two types of sources:
- Existing rules contained in several documents like “AIXM 4.5 Rules” and “NDBX Business Rules for AIXM 5.0” have been adapted to AIXM 5.1 and translated in SBVR and/or Schematron.
- ICAO Annexes 10,11,14,15, PANS-OPS and several AIXM concepts like Temporality, PropertiesWithSchedule, Activation/Usage and GML Profile also inspired a number of brand new rules.
AIXM 5.1 (Aeronautical Information Exchange Model) is designed to enable the management and distribution of Aeronautical Information in digital format. It is currently the most complex model available in the world, with more than 900 classes, including referential data.
By taking advantages of existing and emerging information engineering standards and supporting current and future system requirements, this version is a quantum leap compared to previous versions.
AIXM 5.1 major tenets are an exhaustive temporality model and an alignment with ISO standards for geospatial information, including the use of the Geography Markup Language (GML).Maven, Excel, XML, GML, Schematron.
Description of Business Rules
Each rule in the database, depending upon its degree of maturity, may contain a plain English version, an SBVR version and/or a Schematron version.
The plain English version is usually the original text of the rule. It gives the spirit of the rule without technical details like references to a data model. Such a rule is understandable by domain experts but it can, to some extent, be ambiguous or fuzzy, or at least, insufficiently detailed to be implemented in a computerized system.
The SBVR-compliant version of a rule is a formalized translation of the plain English text of the rule. It is written according to a set of formal specifications (defined in “AIXM Business Rules SBVR Specifications”) established to limit the possible ambiguity and fuzziness of natural languages.
For instance, the number of possible constructs is only a small subset of what is possible in plain English. An SBVR-compliant rule is also much more detailed. It usually refers explicitly to formal or abstract data structures rather than real life objects or concepts. SBVR-compliant rules are better candidates for automation.
The Schematron version of a rule is its implementation targeted to validation of a set of data by a computer. Schematron is one of the possible languages to implement business rules and it has been selected as a proof of concept to demonstrate the automation of business rules. The Schematron rules have been tested on sample data sets using ARC-Web, a tool provided by EUROCONTROL and enhanced by the project team.
Comparison of languages for writing business rules:
Semantics of Business Vocabulary and Business Rules (SBVR)
The SBVR is an adopted standard of the Object Management Group (OMG) intended to be the basis for formal and detailed natural language declarative description of a complex entity, such as a business. SBVR is intended to formalize complex compliance rules, such as operational rules for an enterprise, security policy, standard compliance, or regulatory compliance rules. Such formal vocabularies and rules can be interpreted and used by computer systems. SBVR is an integral part of the OMG’s Model Driven Architecture (MDA)
In other words, SBVR is a specification of how to define your own notation for writing Business Rules.
In markup languages, Schematron is a rule-based validation language for making assertions about the presence or absence of patterns in XML trees. It is a structural schema language expressed in XML using a small number of elements and XPath.
In a typical implementation, the Schematron schema XML is processed into normal XSLT code for deployment anywhere that XSLT can be used.
Schematron is capable of expressing constraints in ways that XDR and DTD cannot. For example, it can require that the content of an element be controlled by one of its siblings.
Or it can request or require that the root element, regardless of what element that is, must have specific attributes. Schematron can also specify required relationships between multiple XML files.
Constraints and content rules may be associated with "plain-English" validation error messages. This may be preferred by some users who might otherwise have to cross-reference numeric error codes to understand what they mean. [Wikipedia]
XML Schema vs. Schematron
An XML Schema allows defining a custom grammar and a vocabulary for XML files of a specific domain. It can be used to verify that a given XML file is valid and well-formed. However, it cannot check if the file content is meaning from a domain or business perspective.
Thus, speaking about validation of XML data, some simple business rules may be implemented through an XML Schema. However, XML Schema has its limitations and more complex business rules are out of scope. That’s where Schematron has a role: the language is powerful enough to express very complex rules even if, in this case, the resulting code can also be very complex.
Special Rules Types
Two concepts, namely Generic Rules and Templates, helped drastically to increase the team productivity and the number of rules created while allowing the lowest maintenance costs of the rules sets.
Generic rules: rules that apply in more than one context, thus a mean to reduce the number of rules. For instance, rules on ElevatedPoints apply each time a feature has an ElevatedPoint. Using generic rules avoid writing one rule for each feature where the ElevatedPoint occurs.
Templates: parameterized rules used to speed up rule writing. A template allows replacing several rules having the same structure by one rule model plus a list of parameter sets. Each parameter set applied to the template allows generating one instance or actual rule.
For instance, GML Profile could be implemented by about 100 rules. But it can also be implemented by one template and the list of 100 attributes contained in the profile. This is faster and more compact.
A sample of Business Rules as visible in the BRM:
Business Rules Manager
The existing business rules were gathered in a Microsoft Excel worksheet. The Business Rules Manager (BRM) is a tool developed to handle rules more efficiently and more conveniently, considering the high number of rules as well as the length of some of them.
The BRM allows storing business rules, editing existing rules, retrieving rules according to various convenient filtering criteria, as well as exporting selected rules in a predefined Excel format specified by EUROCONTROL.
The produced Excel sheet generated by the BRM features a macro used to export rules to ARC-Web database in XML format.
Export from BRM to Excel:
AIXM Rules Checker Web (ARC-Web) provided by Eurocontrol is used to apply Schematron Business Rules to AIXM XML data files. We, at pulsar, adapted ARC-Web to support AIXM 5.1 together with several extensions of Schematron itself.