STANAG 4817 / AEP-105 · 0.3.0-rc4 (SD-3 RC4)
Concepts

Encodings

One model, three wire formats — how JSON Schema, XSD/XML and OMG IDL encode the same HIBW message set.

AEP-105 defines one logical model and renders it into several concrete wire formats. The same Track or TaskAdmin exists in each; only the serialization differs. This is what makes the standard interoperable — systems that speak different encodings still agree on the meaning of every field.

ArtifactVolumeWire formatUse it to
*_schema_xsdIIXML SchemaValidate / define XML HIBW messages.
*_idlII / IIIOMG IDLGenerate types for DDS and language bindings.
*_schema_jsonIIIJSON Schema (2019-09)Validate / define JSON HIBW messages.
*_schema_protobufIIIProtocol BuffersCompact binary encoding.

In 0.3.0-rc4 there is no standalone .proto artifact — Protobuf is generated from the IDL. The API does this for you and serves the result (a .proto tree, compiled descriptor set, and union map) plus a JSON ⟷ protobuf codec; see Protobuf.

The same message, two ways

The worked examples ship every message in both JSON and XML. For instance, a NODE_DESCRIPTION:

{
  "header": {
    "message_type": "MessageTypeEnum_NODE_DESCRIPTION",
    "source": "a895f8f5-46b0-5603-bdf0-b270a2867c09",
    "version": "0.3.0",
    "time_sent": "2025-03-18T12:05:00+00:00"
  },
  "body": {
    "identifier": "73efad3c-8336-597c-a3f3-f6ae5b3b3f8e",
    "timestamp": "2025-03-18T12:05:00+00:00",
    "endurance": "PT3H"
  }
}
<message>
  <header>
    <message_type>MessageTypeEnum_NODE_DESCRIPTION</message_type>
    <source>a895f8f5-46b0-5603-bdf0-b270a2867c09</source>
    <version>0.3.0</version>
    <time_sent>2025-03-18T12:05:00+00:00</time_sent>
  </header>
  <body>
    <identifier>73efad3c-8336-597c-a3f3-f6ae5b3b3f8e</identifier>
    <timestamp>2025-03-18T12:05:00+00:00</timestamp>
    <endurance>PT3H</endurance>
  </body>
</message>

Constraints travel with the model

The IDL carries JSON-Schema-style constraints as custom annotations (declared in module ext) so a single source model can drive every encoding consistently:

@unit("deg")
@min(-90)
@max(90)
typedef float LatitudeValue;

@ext::pattern_xsd("[A-Z]{3}")
@ext::pattern_ecma262("^[A-Z]{3}$")
@ext::min_length(3)
@ext::max_length(3)
typedef string<3> CountryCode;

These annotations (@min, @max, @unit, @ext::min_length, @ext::pattern_*, @ext::min_items, …) become minimum/maximum/pattern keywords in JSON Schema, xs:restriction facets in XSD, and documented bounds in the generated bindings.

The unclassified filter profile

RC4 adds a filter profile (*_hibw_filter_unclass_*) — a reduced model that strips classified fields. Use it when a link or domain must carry only unclassified data. It is published as both IDL and JSON Schema; see Artifacts.

On this page