Getting Started
Unpack the release, validate a message, and generate language bindings from the AEP-105 0.3.0-rc4 artifacts.
This guide gets you from the release archives to a validated message and generated code. Everything here targets the 0.3.0-rc4 artifacts described on the Artifacts page.
1. Get the artifacts
All payload definitions ship as .zip archives in the release directory
(STANAG/Draft-3-RC4/). Unzip the ones you need into a scratch location:
# JSON Schema (Volume III) — validate / define JSON HIBW messages
unzip stanag_4817_aep_105_hibw_schema_json-0.3.0-rc4.zip -d schema_json
# OMG IDL (Volume II/III) — generate DDS / language bindings
unzip stanag_4817_aep_105_hibw_idl-0.3.0-rc4.zip -d idl
# Worked example messages (JSON + XML)
unzip stanag_4817_aep_105_hibw_examples-0.3.0-rc4.zip -d examplesKeep the release .zip files unmodified — they must match the upstream spec source. Always
unzip into a throwaway directory rather than editing artifacts in place.
2. Validate a JSON message
Every message is a CATL envelope: a header plus a typed body. The JSON Schemas
are JSON Schema draft 2019-09 and use file:///-style $refs, so point your
validator's base URI at the unzipped schema_json/ root. Using
check-jsonschema:
pipx install check-jsonschema
check-jsonschema \
--schemafile schema_json/catl/hibw/messages/node/NodeDescription.json \
examples/aep105/json/catl_1_node_description.jsonOr with ajv in Node (register the schema directory so the
file:/// references resolve):
npx ajv-cli validate \
-s schema_json/catl/hibw/messages/node/NodeDescription.json \
-r "schema_json/**/*.json" \
-d "examples/aep105/json/catl_1_node_description.json" \
--spec=draft2019 -c ajv-formats3. Validate an XML message
The XML examples are validated against the XSD schema (Volume II). With
xmllint:
xmllint --noout --schema <path-to>/catl.xsd examples/aep105/xml/catl_5_task_admin.xml4. Generate language bindings from IDL
The OMG IDL defines the same model for DDS and code generation. With a typical IDL compiler:
# Example: generate C++ with an IDL-to-language compiler
idl-compiler idl/stanag_4817_aep_105_hibw_idl-0.3.0-rc4.idlThe IDL uses a small set of custom annotations (under module ext) to carry JSON
Schema-style constraints — min, max, min_length, pattern_*, and so on — so
that a single model can drive JSON, XML and DDS. See
Encodings for how these map across the wire formats.
5. Need an unclassified-only profile?
RC4 ships a filter profile that restricts the model to unclassified fields
(*_hibw_filter_unclass_*). Use it when the link or domain must not carry
classified attributes. It is available in both IDL and JSON Schema form — see
Artifacts.