曝光臺 注意防騙 網曝天貓店富美金盛家居專營店坑蒙拐騙欺詐消費者

1. Document Status
Edition 1.1 of this document was published as a Proposed Issue because the usage rules contained in
the document needed to be confirmed by implementation. At the time of the publication, the most advanced
AIXM implementation was through the European EAD Database (EAD) system-to-system interface
(ESI).
The current edition has been updated based on feedback gathered from AIXM stakeholders since 2002.
Note that the edition number has "jumped" from 1.1 to 4.5; beginning with this version, the Primer edition
number will match the version number of the AIXM to which it applies. Eventual revisions that refer
to the same AIXM version will get a suffix indicating the revision number.
1Cambridge International Dictionary of English (http://dictionary.cambridge.org)
Edition Number: 4.5 xi
AIXM PRIMER
AIXM PRIMER
Chapter 1. Introduction
AIXM specifies an encoding rule that may be used for neutral aeronautical data interchange, based on
the Extensible Markup Language (XML1). XML is a text format and the values of all data types have
to be character encoded. The basic units of an XML document are XML elements. An element may have
attributes and content. XML documents have a hierarchical structure.
The central component of the AIXM specification is the XML Schema (XSD). XML Schemas define a
number of complex types, simple types and element declarations, which define the allowable structure
and data instances of an XML document. As indicated in the W3C Recommendation2 : "the purpose of
a schema is to define a class of XML documents, and so the term 'instance document’ is often used to
describe an XML document that conforms to a particular schema. In fact, neither instances nor schemas
need to exist as documents per se - they may exist as streams of bytes sent between applications, as
fields in a database record, etc.". Within the scope of this document, XML documents/files that conform
to the AIXM XML Schema will be referred to as AIXM messages.
In addition to a short presentation of the AIXM XML Schema capabilities, this document also introduces
a set of usage rules. Ideally, an AIXM message that is valid against the Schema should be accepted by
the receiving system without errors. However, a few operational constraints that need to be imposed on
AIXM messages cannot be expressed using XML Schemas. This is particularly true for AIXM-Update
messages, which allow previously exchanged data to be brought up to date without the need for reissuing
a complete new data set. The possibility to use XSLT stylesheets in order to check compliance of an
AIXM-XML message with some of these rules will be investigated.
Another aspect of AIXM discussed in this document is its relationship to the AICM, the conceptual
model from which the AIXM schema was derived.
1The XML Recommendation 1.0 was published by the World Wide Web Consortium. It is available at http://www.w3c.org/XML
2See “Basic Concepts” at “http://www.w3c.org/TR/xmlschema-0/#PO”
Edition Number: 4.5 1
AIXM PRIMER
AIXM PRIMER
Chapter 2. AIXM and the AICM
2.1. Purpose of this Chapter
The purpose of this chapter is to explain the relationship between AIXM (the exchange model) and
AICM (the conceptual model), and the similarities and differences between the two. The AICM is an
entity-relationship model based on ICAO and industry standards, recommended practices, and data
concepts from published aeronautical information products. It defines entities in terms of their properties
and the relationships between them. It also describes data value domains (i.e. ranges) and data validation
rules.
As explained in the Introduction, AIXM is an XML Schema encoding for exchanging aeronautical data.
It was programmatically generated from the AICM entity-relationship data model, using a number of
ad-hoc conversion rules. The following sections detail the reasons for and consequences of those rules.
It must be stressed that AIXM is only one particular implementation of the AICM - other exchange
formats and implementations are possible.
2.2. Unique Identifiers
Generally, in order to utilise any dataset it is usually (though not always) necessary to be able to separately
identify its constituent parts. Specifically, AIXM requires this ability to express relationships between
features and to identify features that are the target of an update message. Unique identifiers associated
with each feature instance are used to achieve this. By introducing unique identifiers AIXM differs from
the AICM, because the conceptual model does not specify any.
Broadly speaking there are two alternatives when implementing a mechanism for uniquely identifying
objects in a database, and the same is true for data formats such as AIXM: "surrogate" (artificial) or
　
中國航空網 m.k6050.com
航空翻譯 www.aviation.cn
本文鏈接地址：AIXM_Primer_4.5(3)