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

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 examples

Keep 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.json

Or 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-formats

3. 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.xml

4. 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.idl

The 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.

Next steps

On this page