AIXM 5.2 Migration: Why a Namespace Change Is Not Enough

AIXM 5.2 migration requires more than changing the version in an XML namespace. Aeronautical data must conform to the target schema, preserve the meaning of changed properties and remain usable by its intended consumers. An adapter accepting a document answers only part of that question. It does not, by itself, prove a valid conversion from AIXM 5.1.1 or complete support for every 5.2 feature and extension.

The Aeronautical Information Exchange Model (AIXM) provides a structured model for aeronautical information. This article examines version migration through the published SynapseCommand AIXM 5.2 ingest adapter, separating specification changes, implementation coverage and the evidence an integration team should request.

At a glance

The date comes from the official AIXM 5.2 XML Schema publication. SynapseCommand's current interoperability catalogue states the adapter's direction, evidence level and implementation limits. Neither an official specification release nor an adapter badge establishes that a particular data chain has migrated successfully.

A newer specification does not migrate the whole data chain

The AIXM 5.2 overview describes changes for satellite navigation, runway information and other aeronautical requirements. It also advises progressive implementation according to operational needs. Its implementation guidance still identifies several data-set coding specifications and Digital NOTAM as based on 5.1.1.

That creates a practical transition problem. A provider may publish one data set in a newer version while another interface remains on an earlier profile. A consuming application may accept the newer schema but still depend on a field that changed or disappeared. An extension has its own compatibility requirements, which cannot be inferred from the core version number.

The AIXM Change Control Board maintains the specification and associated material. Its publication process is distinct from an organisation's deployment decision. Integrators should therefore record the actual version, schema resources, extensions and required properties at each interface.

Temporal interpretation is another independent concern. The preceding AIXM 5.1.1 time-slice analysis explains why translating a feature assertion does not establish its current state. The question here is narrower: what must change in a version-specific data contract before the consumer can interpret the new representation correctly?

Concrete changes that a namespace edit cannot handle

The published AIXM 5.2 adapter source records a structural comparison of the schema groups it implements. The examples below concern that bounded subset, not the complete catalogue of changes in the standard.

A migration review should classify each relevant difference as an addition, removal, type change, structural change or change in meaning. It should then identify what the receiving application actually requires. A field that is irrelevant to one consumer may be essential to another.

The same review must cover cardinality: whether a property can occur once or multiple times. Selecting the first organisation in a repeated association is an application decision, not a neutral XML conversion. If a consumer supports only one value, the limitation needs an explicit treatment rather than an accidental truncation.

Shared reader, separate version contracts

SynapseCommand's two AIXM adapters share reader infrastructure, but the 5.2 implementation supplies a separate profile. Its namespace binding, property groups and repeatable-element definitions are version-specific. The shared codec carries those distinct version definitions rather than treating the input as an interchangeable tree of similarly named fields.

The 5.2 adapter tests include explicit cross-version rejection. A 5.1.1 document is refused by the 5.2 adapter at the root namespace, and the 5.1.1 adapter refuses the converse. The suite also specifies checks in which 5.2 fixture namespaces are rewritten to 5.1.1 and the resulting documents fail the older schema.

These tests illustrate a useful engineering property: version handling is observable. They do not constitute a general-purpose conversion service. Both adapters ingest their respective versions; neither supplies an AIXM output path for completing a source-to-source migration.

The architecture overview places these translations within a common canonical layer. A common output model can simplify consumption, but it does not make differences in the source models disappear. The reader must retain the distinctions that matter, and the consumer must know which ones it can use.

Preserved data is not automatically usable data

The AIXM 5.2 manifest distinguishes typed readings from structured residual content. Its bounded feature set covers Airspace, AirportHeliport, Runway, RunwayDirection, Navaid and VerticalStructure. Even within those classes, a property may be preserved without receiving a dedicated typed interpretation.

For example, the implementation retains an AirspaceVolume's new name and location in its source representation rather than widening the shared volume-reading contract. The location is not treated as a replacement for the airspace's drawable projection. A downstream application that needs the new property must account for where it is carried.

Three questions should therefore remain separate: did the data survive, was its meaning interpreted, and does the receiving application use it? A preservation ledger helps with the first question and with tracing mappings. It cannot supply a missing application rule merely by reporting that a source value remains present.

Geometry boundaries remain relevant during migration. The adapter supports specified forms and coordinate-reference systems; it does not provide unrestricted geometry transformation. A new schema version also does not establish a datum conversion or turn a retained composite volume into a single drawable canonical area.

The canonical data model documentation is useful here because the consumer's contract is expressed in the records it receives, including their provenance and residual content. Review those outputs as well as the original XML.

Digital NOTAM is a separate compatibility question

The official 5.2 implementation guidance does not imply that existing Digital NOTAM specifications have moved with the core model. Likewise, the published SynapseCommand 5.2 adapter declares no Digital NOTAM scenario profile and produces no typed `dnotam` block.

Its manifest describes how a 5.1.1 Event member encountered inside a 5.2 document is identified and carried as residual content rather than interpreted as a supported event. Retention in that form is not Digital NOTAM support. A consumer expecting scenario-level findings cannot obtain them merely because the source extension was not discarded.

That limitation should appear explicitly in a migration plan. Where a workflow depends on the earlier adapter's pinned Digital NOTAM subset, the decision is about the exact core-version and extension combination. It is not an instruction to relabel the Event namespace or assume that a newer core model includes every earlier capability.

Three gates for a migration decision

A useful review separates three gates. This is an editorial framework for organising evidence, not an official AIXM certification scheme.

**First, check document validity.** Use the intended schema and its required dependencies. The official 5.1.1 schema distribution and the 5.2 distribution provide distinct resources. Record the exact files used in validation, not only a version label. The 5.2 specification page also distinguishes the data model, schema and associated usage guidance; schema validity does not settle every usage rule.

**Second, check translation coverage.** Establish which properties become typed canonical fields, which remain residual and which inputs the implementation refuses. Review representative changes, repeated properties and boundary cases. Confirm what happens to content that the consumer requires but the adapter does not interpret.

**Third, check consumer acceptance.** Verify that the receiving application still fulfils its agreed purpose using the delivered records. This includes version routing, missing or changed fields, unresolved content and the behaviour when validation is unavailable or fails. Keep the deployed system's acceptance evidence separate from adapter fixtures.

The separation matters because the repository deliberately includes schema-invalid counterexamples that its structural reader can still ingest. A removed 5.1.1 property, for example, can survive in residual content while the document fails the 5.2 schema. Parsing success and preservation are not substitutes for the first gate.

A synthetic review of an airport data update

Consider a synthetic delivery labelled AIXM 5.2. It contains an AirportHeliport record with two responsible-organisation associations, a time-zone value and the older `fieldElevationAccuracy` element. Assume that the remaining document is readable by the adapter. This is an illustrative review scenario, not a real airport feed or a newly executed test.

A namespace-only check would miss the obsolete property. A structural translation could preserve it in residual content, leaving a plausible-looking output record. The schema gate should still reject that property under the pinned 5.2 schema. The correct response is to establish the intended mapping with the provider, not silently delete the evidence or assign a fabricated replacement value.

The two organisation associations need a separate consumer review. Even after the invalid property is corrected, an application expecting a single organisation may not handle the new record as intended. The new time-zone field likewise needs an agreed use; its presence does not automatically change how every timestamp in the application should be interpreted.

This example shows why the three gates should produce distinct results. A document can be structurally readable but schema-invalid. A schema-valid translation can still leave a consumer requirement unmet. Preserving those outcomes helps a team locate the problem rather than hiding it behind one “import succeeded” message.

What to ask for at handover

The baseline reviewed here is synapse-cdm 3.3.0. Its AIXM 5.2 manifest declares L3 provenance evidence and a path-bound ledger. It does not declare L4: with no egress implementation, a reverse AIXM round trip is inapplicable. Normative schema checks require their validation dependencies and pinned resources; missing evidence must remain blocked rather than counted as a pass.

Teams can inspect the open integration package and keep its trust and assurance scope explicit when assessing integration compatibility. This article reviewed published code and evidence descriptions, without running a new test campaign or asserting aviation certification. A sound migration decision identifies both what the new records make possible and what the receiving system has actually demonstrated.