曝光台 注意防骗
网曝天猫店富美金盛家居专营店坑蒙拐骗欺诈消费者
5.1.7. Aspects of Usage
5.1.7.1. Operational Rules
Ideally, an AIXM message that is valid against the Schema should be accepted by the receiving system
without errors. However, a number of constraints that need to be imposed on AIXM messages cannot
be expressed using an XML Schema. Such operational rules are specified further down.
For the purpose of applying the rules specified further down, all AIXM-Update messages issued by one
source for the same effective date will be regarded as one message. This message is resulting from the
concatenation of all the individual Groups under a single <AIXM-Update> element, taking into consideration
their publication order.
Edition Number: 4.5 19
AIXM PRIMER
XSLT stylesheets is a good candidate technology for the implementation of the compliance checks of
AIXM messages with some of these rules.
5.1.7.1.1. Order of Related Features
Rule: In AIXM-Update messages, data about a <New> feature must occur before any relationship
towards this new feature occurs.
This rule is applicable both within one AIXM-Update message and when considering all AIXM-Update
messages issued by one originator for the same effective date.
This operational rule is primarily intended to allow for the use of event-based parsers, such as SAX, instead
of object-based parsers such as DOM. The essential difference3 is that a DOM parser works by loading
the whole XML document into memory and constructing a DOM tree.
The problem with using DOM parsers is that AIXM-Update messages could be quite large and cause
errors related to insufficient memory available. The SAX API can provide faster and less costly processing
of XML data. However, they work only when you do not need to access all of the data in an XML document.
In order to eliminate the need to access the whole XML document in memory, a certain sequence of
features needs to be imposed in an AIXM-Update message. This is related to relationships. For example,
let's suppose that a new VOR/DME is created. As the collocation relationship is encoded in the <Dme>
element through the inclusion of the <VorUid>, the <New> element containing the <Vor> shall be
placed before the <New>element containing the <Dme>.
5.1.7.1.2. Natural Key Update
The use of natural keys in AIXM-Update messages together with the fact that a natural key may change,
requires a few rules to be followed in order to eliminate ambiguities.
Related features should not be re-sent.
Rule: A change in the natural key of a feature F1 does not require the originator to send also
<Changed> notifications for any other feature that has the natural key of F1 as descendant element.
For example, let's suppose that the natural key of an aerodrome/heliport changes. The natural key of the
aerodrome/heliport appears as <AhpUid> child element in all the features that are related to that aerodrome,
such as <Rwy>, <Twy>, <Ful>, etc. The question is, does the originator have to include all these
related features in the AIXM-Update message?
The rule indicates that, if the natural key of the <Ahp> feature instance has changed, it is not necessary
to re-send data about all the <Rwy>, <Twy>, <Ful>, etc. which are related to that aerodrome/heliport.
This rule is based on the assumption that most systems work internally with artificial unique identifiers.
For such systems, no change occurs in the related features if there is a change of the natural key of the
feature to which they are related. For example, no change occurs to the DME record if there is a change
of the natural key of the collocated VOR.
3for example, see http://www-3.ibm.com/software/ts/tpf/pubs/xml16/xdvs.htm
20 Edition Number: 4.5
AIXM PRIMER
Related elements should contain the new natural key.
Sometimes, it is necessary to include in AIXM-Update messages data about a feature, which is related
to another feature whose natural key has changed at the same effective date. The question is, which
natural key shall be included, the old one or the new one?
Rule: If a <Changed> notification for the natural key of a feature F1 was issued for an effective
date DT1, then any subsequent AIXM-Update message for the same or a later effective date, including
the current one, issued by the same originator, which contains a <New>, <Changed> or
<Withdrawn> notification about a feature F2 having the natural key of F1 as descendant, shall
contain the new values for the natural key of F1.
For example, the natural key of an aerodrome/heliport changes and let's suppose that the length of a
RWY located at that aerodrome/heliport changes as well at the same effective date. If the <Changed>
中国航空网 www.aero.cn
航空翻译 www.aviation.cn
本文链接地址：
AIXM_Primer_4.5(11)
