Other rules execution aspects
- POROSNICU Eduard
NounConcept versus AIXM XML DOM
AIXM SBVR rules use NounConcepts that correspond to nodes in the AIXM XML (elements and attributes). These nodes are defined by the AIXM XML Schema, which in turn is generated from the AIXM UML classes and properties by applying the XML Schema Mapping rules.
NounConcept - first token
The following AIXM XML elements may appear as the first token of a NounConcept:
AIXM feature - appear in the AIXM Basic Message immediately below hasMember elements. Examples: AirportHeliport, Airspace, Runway, etc.
AIXM feature Timeslice - appear as second level descendants of AIXM features. Examples: AirportHeliportTimeSlice, AirspaceTimeSlice, RunwayTimeSlice, etc.
AIXM objects at any composition level - appear as second or lower level descendant of ...TimeSlice elements. Examples: TimePeriod, TimeInstant, AirspaceVolume, VerticalStructurePart, etc.
AIXM data set - this is a particular case, used for rules that prohibit the use of a certain element value anywhere in the data set, such the rules that limit the values of the @srsName. Using the “data set” as entry not significantly reduces the number of rules that need to be written and verified, as compared to specifying this rule for each and every AIXM element that might have this attribute. The AIXM data set is always used as unique token in a NounConcept.
NounConcept - same instance or different instances
If two elementary (or more) elementary conditions are formulated with the same node token, then it is considered that it is the same node instance in the XML object model that is concerned, unless there is an explicit "[1]", "[2]", etc. suffix after the noun. When such suffixes are used, then it is considered that they indicate different node instances.
For example, considering the (fictitious) rule: It is prohibited that AirspaceVolume has maximumLimit value and AirspaceVolume has maximumLimitReference value other-than 'SFC'. In this rule the AirspaceVolume node that appears in the two elementary conditions is the same XML node.
Entry node
The development of services and software used for verifying AIXM business rules on an AIXM data set is in general expected to use object-oriented programming languages. In such languages, each rule is likely to correspond to functions launched from objects instances. Each rule may be seen as having an "entry node", which is the AIXM XML node (XML element or attribute) that triggers the execution of the rule. If that node does not exist in an AIXM data set, the rule is never executed on that specific data set. This entry node is always the NounConcept used in the first elementary condition of the rule.
Warning concerning verifications triggered only "by data updates"
The "entry node" concept might have additional consequences when verifying data updates against a reference data set. In order to simplify the implementation, developers might decide to trigger the verification of a rule only if the data update includes entry nodes that satisfy the first elementary condition. This means that the existing data will not trigger the rule verification and some data might pass the validation without detecting a non-conformance.
The following (fictitious) rule provides an example: "It is prohibited that Runway.timeSlice[1] has RunwayTimeSlice.type as 'RWY' and Runway.timeSlice[2] has RunwayTimeSlice.type as 'FATO' ". If the data set update does not include a RunwayTimeSlice with type='RWY', this rule will not be "triggered" and the data will not be verified against it. This might miss a change of a Runway type from 'FATO' into 'RWY'. Therefore, for such implementations, some rules need to be written in both directions in order to ensure that all data is verified. A complementary rule needs to be included in the profile of such implementations: "It is prohibited that Runway.timeSlice[1] has RunwayTimeSlice.type as 'FATO' and Runway.timeSlice[2] has RunwayTimeSlice.type as 'RWY' ".
This particular situation does not concern the validation of ICAO Data Sets or any other self-contained data sets.
NounConcept examples
The following table contains some theoretical examples of entry nodes and NounConcept formulated with AIXM XML nodes.
Rule example | Entry node | Remarks |
|---|---|---|
It is obligatory that AirspaceTimeSlice has name value | <aixm:AirspaceTimeSlice> | If there is no <aixm:AirspaceTimeSlice> element in the AIXM data set, then this rule is never executed |
It is prohibited that ElevatedPoint has verticalAccuracy value and ElevatedPoint has elevation value and verticalAccuracy@uom value not-equal-to elevation@uom value | <aixm:ElevatedPoint> | This element is deep in the AIXM XML structure. It may appear as descendant of numerous top AIXM features, such as AirportHeliport, RunwayCentrelinePoint, Navaid, etc. The rule needs to be verified on each instance of the ElevatedPoint and its descendant nodes. |
It is prohibited that AirportHeliport[1].timeSlice.AirportHeliportTimeSlice.designator value equal-to AirportHeliportTimeSlice[2].timeSlice.AirportHeliportTimeSlice.designator value | <aixm:AirportHeliport> | Any <aixm:AirportHeliport> triggers the execution of this rule. Because the rule references to two different AirportHeliport ([1] and [2]), this means that:
|
It is prohibited that AirportHeliport has timeSlice[1] | <aixm:AirportHeliport> | Any <aixm:AirportHeliport> triggers the execution of this rule. Because the rule references to two different AirportHeliport timeSlices ([1] and [2]), this means that:
|
It is prohibited that RunwayTimeSlice has associatedAirportHeliport value and not associatedAirportHeliport@xlink:href value references-to exactly one AirportHeliport | <aixm:RunwayTimeSlice> | This rule is triggered by any <aixm:RunwayTimeSlice> element,. The first elementary condition verifies if the associatedAirportHeliport element has a value for its xlink:href attribute node. If not, the rule execution should stop here because the next step is very costly in terms of performance. The next elementary condition tries to resolve the link by looking at all <aixm:AirportHeliport> instances in order to verify if there exists exactly one that has a corresponding gml:identifier or gml:id value. See the supported formats for xlink:href: Feature identification and reference. |
Order of evaluation of the elementary conditions
The structure of the SBVR rules (see Rule syntax - (old)#Generalrulestructure) does not give any priority to any of the elementary conditions. They can be verified in any order. Therefore, the implementers could decide on a particular order in which the elementary conditions could be verified in order to save time and calculation effort.
For example, if a rule is of the form "It is obligatory that A and B", then if either A or B is False, the result is False. Thus, the execution order should give priority to testing first the elementary condition that requires less effort and execution time. If that is False, the second elementary condition does not even need to be tested.
The computation time/effort for evaluating each elementary condition will probably depend significantly on the technology and strategy applied in the development of the evaluation routines. Therefore, for the moment, it is not considered possible to give general guidance on which elementary conditions should be tested first. The only thing that can be said is that it is quite likely that the most expensive elementary conditions are the ones that involve navigating through the whole data set in search for a reference/referencing element. Thus, any elementary condition that uses references-to/is-referenced-by verb concepts is probably to be tested at the end, if still necessary.
Comparison with empty elements
Several elementary conditions (C3, C8, etc.) involve a comparison (equal-to, higher-than, etc.) between an AIXM element/attribute value and another value, which could also be another element/attribute. As AIXM elements or attributes could be empty, it is necessary to have a common approach on the result of such comparisons. As all AIXM Business rules are defined as a combination of elementary conditions and logical operators. If the result of an elementary condition was "undefined", then practically the result of the rule verification could be "undefined" (depending on the logical operators used).
In fact, the AIXM SBVR grammar specifies a quantification (existential, at-most-one) for each comparison keyword. Therefore, the following table indicates the result of applying each of the comparison that can be used (according to the list of SBVR keywords):
1st operand | 2nd operand | comparison operator | result |
|---|---|---|---|
NIL (empty or absent) | value (list of values) or NIL | equal-to equal-to-one-of higher-than higher-or-equal-to lower-than lower-or-equal-to contains-substring intersects | False |
NIL (empty or absent) | value (list of values) or NIL | other-than other-than-one-of | True |
Examples:
if the elementary condition is "lowerLimit@uom value other-than ('FT', 'M')"
if lowerLimit@uom = 'FT' → False (because it is not different from one of the members of the list)
if lowerLimit@uom = 'KM' → True (because it is different from one of the members of the list)
if lowerLimit@uom is empty or not present (its value is NIL) → True (because it is neither FT nor M)
if an elementary condition is "lowerLimit value higher-than upperLimit value", then if either one or both elements are empty, then the result is False.
This convention for comparison operators has a significant impact on the structure of the rules. It is not necessary to test in the same rule if the elements that are compared actually have a value.
About multi-occurring descendants
The data on which this rule is formulated is schematically presented in the following diagram. An ObstacleArea may reference many VerticalStructure (each is considered an obstacle for that area).
The rule that we need to verify links the ObstacleArea.type with the verticalAccuracy value(s) of the referenced VerticalStructure(s). Please pay attention to the plurals!
Currently, the rule (template) is formulated as follows:
It is prohibited that ObstacleAreaTimeSlice has type value as '${area}'
and ObstacleAreaTimeSlice.obstacle@xlink:href references-to VerticalStructure
and VerticalStructure has-descendant verticalAccuracy@uom value as '${uom}'
and VerticalStructure has-descendant verticalAccuracy value higher-than '${val}'
With an instance table such as:
The difficulty in this rule is the “hidden plurals” - the rule formulation does not indicate that obstacle or verticalAccuracy (and its @uom) may be multi-occurring:
Each ObstacleArea may have many obstacle children (they can be in the thousands!);
Each VerticalStructure may have between zero and more descendant verticalAcuracy (usually one, but could be up to 30-40 of them);
The rule practically needs to be verified on each combination of obstacle – referenced VerticalStructure – one of its verticalAccuracy (value and @uom value) descendants.