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.
| Artifact | Volume | Wire format | Use it to |
|---|---|---|---|
*_schema_xsd | II | XML Schema | Validate / define XML HIBW messages. |
*_idl | II / III | OMG IDL | Generate types for DDS and language bindings. |
*_schema_json | III | JSON Schema (2019-09) | Validate / define JSON HIBW messages. |
*_schema_protobuf | III | Protocol Buffers | Compact 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.
Autonomy & Doctrine
How autonomy (ALFUS), Rules of Engagement, Courses of Action, and tasking logic relate to STANAG 4817 — what the standard carries, and what it deliberately leaves to policy and the system.
Protobuf
The Protobuf (Volume III) binary encoding of the HIBW model, and how it maps from the IDL.