Syntax & Architecture of DAXP

Under active development

The core strength of the DAXP (Data & Attribute eXchange Protocol) lies in its syntax. Unlike heavy, nested text formats like JSON or XML, DAXP approaches data serialization from a hardware-friendly, low-level perspective. It combines the efficiency of a tag-value protocol with the expressive power of pointers and state modifiers.

This article provides an in-depth technical breakdown of DAXP’s atomic tokens, syntax rules, and its single-pass streaming architecture.

1. The Anatomy of a DAXP Triplet

While traditional protocols speak of "key-value pairs," DAXP introduces the concept of the Triplet. Every data token in a DAXP stream is an Triplet unit consisting of strict components: [Tag][Operator][Operand], terminated by a structural separator (| or SOH).

<TAG><OPERATOR><OPERAND><SEPARATOR>

The syntax enforces a deterministic state machine. The parser reads bytes linearly, flipping its internal state instantly when it hits an operator, and resetting when it hits a separator.

2. Detailed Breakdown of Structural Elements
A. The Tag (Semantic Identifier)

A DAXP Tag is a purely numerical identifier (e.g., 5001, 8002) or a specialized system token (e.g., $:4, FIX:51).
No Text Overhead: Instead of wasting network bandwidth transmitting strings like "firstName" or "transactionTimestamp" millions of times, DAXP compresses these concepts into small integers.
Contextual Decoupling: The Tag does not hold a hardcoded data type in the stream. Its validation rules, data type (String, Integer, DateTime), and human-readable label are managed externally by the Dynamic Dictionary (DD).
System Identifiers ($:): Structural tags reserved for protocol orchestration (e.g., $:4 for Block ID, $:5 for Block Type).

B. The Operator (The State Selector)

The operator is a single-byte ASCII character that instantly dictates the parsing mode for the following operand. This is what makes DAXP uniquely capable of writing complex memory states directly into a stream.
B.1. The Value Assignment Operator (=)

Switches the parser into Raw Value Mode. Everything following this symbol until the next separator is treated as literal data.

Grammar Rule: Once = is triggered, any occurrence of other operators (@ or #) inside the operand is treated as a literal character, completely neutralizing injection attacks.
Example: 8002=Kowalski#N (The value parsed into memory is literally the string "Kowalski#N").

B.2. The Block Reference Operator (@)

Switches the parser into Pointer Mapping Mode. The operand is interpreted as an index or array of indices pointing to other blocks within the same message.

Object Graph Resolution: This allows flat representations of deeply nested, recursive, or circular object structures.
Example: 5089@8;9;10 (Tag 5089 is a collection holding references to Blocks 8, 9, and 10).

B.3. The Semantic Operation / State Directive Operator (^)

Switches the parser into State Modification Mode. The operand is interpreted as a precise lifecycle command for the system memory manager, rather than data.

^N (Force Null): Explicitly de-allocates the field reference, setting it to a true system null.
^E (Initialize Empty): Commands the application to instantiate an empty container (e.g., an empty String "" or an empty ArrayList).
^D (System Default): Bypasses assignment entirely, allowing the application field to preserve or roll back to its native constructor default value.

C. The Operand / Value (The Payload)

The operand is the variable-length byte sequence terminated by the separator. Its internal interpretation depends strictly on the operator that preceded it:

Following =, it is a Literal (e.g., 456, ENUM_VALUE1, Test String).
Following @, it is an Address Token or an array of tokens separated by semicolons (e.g., 2, 16;17;14;15).
Following ^, it is a Single-Byte Command Flag (e.g., N, E, D).

3. Streaming Grammar and DFA State Transitions

Because of this rigid triplet design, a DAXP parser is implemented as a highly optimized Deterministic Finite Automaton (DFA). It reads the raw byte stream sequentially, changing states with minimal CPU branch mispredictions.

[START / |] ──> STATE: READ_TAG (Accumulate bytes)
│
├──> Detect '=' ──> STATE: READ_VALUE (Until '|')
├──> Detect '@' ──> STATE: READ_POINTER (Until '|')
└──> Detect '^' ──> STATE: READ_DIRECTIVE (Until '|')

The Rules of the Stream:

The Reset: Encountering a separator (| or SOH) forces the parser to emit the completed triplet to the active entity block and reset the state back to READ_TAG.
First-Match Operator Win: In READ_TAG mode, the very first operator encountered locks the processing mode for that triplet.
Escapeless Design: Because the state transitions are bound to the structural grammar, values do not need heavy escaping logic. If a user inputs text containing @, =, or #, DAXP streams it safely without parsing overhead, making it immune to structural injection vulnerabilities.

4. Architectural Advantages of DAXP Syntax

Language-Agnostic Expression: The syntax maps seamlessly to Java Memory References, C++ Pointers, or Relational Database Foreign Keys. A pointer array like @16;17 is interpreted by Java as a List<Object>, and by a database engine as a set of child rows.
Support for Composite Keys: DAXP can declare complex entity structures easily. For example, setting a composite primary key pointing to a whole distinct entity block is as simple as writing $:10@4 in the block metadata header.
Future-Proof Extensibility: Because the core syntax is limited to processing the tags and switching states on operators, you can add new data types, custom tags, or new # action commands without changing a single line of code in the core streaming byte-splitter.