Previous situation

The initial approach for the AIXM 5.x business rules was based on SBVR as rule language and on the AIXM UML model as business vocabulary. This proved to add unnecessary challenges for the production of data verification code. The AIXM XML files have a structure that is declared through an AIXM XML Schema (XSD), which has a more complex structure than the AIXM UML model. The AIXM XSD is generated automatically from the AIXM UML model, applying the rules documented in the XML Schema Mapping. Thus, it was assumed that developers of AIXM validation tools will know how to interpret the AIXM UML model classes and properties used in the rules, so that the validation code works correctly at the level of the XML files.

What is new

BNF grammar and use of the AIXM XML as business vocabulary

The objective of the "new SBVR syntax" is to maximise the potential for automatic generation of data set validation code from the AIXM Business Rules. This is achieved through the following changes in the AIXM Business Rules approach:

a strict AIXM business rules grammar, expressed in Backus Naur Form (BNF);
use of the AIXM XML elements and attributes as vocabulary (SBVR noun-concepts) instead of the classes/properties/associations from the UML model;
use of a reduced list of verb-concepts (has, has-descendant, references-to, etc.), which are also the main criteria for the de-composition of the rules into elementary conditions
continue using the SBVR as an intermediate vocabulary layer, mainly for syntax-highlighting and human readability purpose. However, the BNF grammar is defined for stripped-out rules (without the SBVR metadata).

The result of this revised approach is the new AIXM Business Rules Language. which comprises:

a grammar specified in BNF notation: Rule syntax - BNF notation
a vocabulary that uses the SBVR notation and the AIXM XML elements and attributes: Rule vocabulary - using SBVR and AIXM XML elements

Use of FeatureTimeSlice

Most AIXM Business Rules refer to data that is part of a specific TimeSlice. Thus, with the new approach, the elementary conditions will frequently use the FeatureTimeSlice instead of directly the Feature name. For example:

“RunwayTimeSlice has type..." instead of “Runway has type...”.

Some rules might still start from the Feature level and include the timeslice element in the rule, for example when necessary to compare two timeslices of the same feature.

Use of namespaces

All elements in the AIXM XSD belong to a namespace. For most, this is the AIXM namespace. Then, there are elements in the GML namespace, xlink namespace, etc.

The namespace needs to be made explicit in the AIXM Business Rules in order to ensure that the right property is used in an automatic rule-to-code translator. However, in order to reduce the size of the noun-concepts, the following editorial conventions will apply:

all noun-concepts that are in the AIXM namespace appear without any prefix (for example: AirportHeliport, AirportHeliport.type, etc.)
noun-concepts that are in a different namespace will appear with a prefix that indicates that namespace
- gml: for elements in the GML namespace (for example AirportHeliport.gml:identifier, etc.)
- xlink: for elements in the xLink namespace (for example Runway.relatedAirport.xlink:href, etc.)
- event: for elements in the Event extension namespace (see Event Extension).
- etc.

Browser not supported