How does XOP/MTOM optimize binary attachment transmission in Axiom?

During serialization with MTOM optimization enabled, Axiom's writer detects OMText nodes flagged as binary/optimizable and, instead of writing their bytes inline as base64 text, replaces that node's position in the output with a small placeholder element, <xop:Include href="cid:some-content-id"/>, per the XOP specification.

The actual binary bytes are pulled out of the associated DataHandler and written as a separate part of a multipart/related MIME package, referenced by that same content-id, alongside the primary XML part (called the "root part" in MTOM terminology).

flowchart LR
  A[OMText flagged binary + optimized] --> B{Serializing with MTOM enabled?}
  B -- Yes --> C[Write xop:Include placeholder in XML]
  C --> D[Write raw bytes as separate MIME part]
  B -- No --> E[Fallback: inline base64-encoded text]

On the receiving side, an MTOM-aware builder (such as an appropriately configured StAX/SOAP model builder working over the multipart message) reverses this: it reads the incoming MIME parts, matches each xop:Include reference to its corresponding attachment by content-id, and reconstructs an OMText/DataHandler pair pointing at that attachment - so from the application's perspective, the received tree looks exactly like it would if the binary had simply been inline all along.

The net effect is that binary data never has to pass through a base64 encoding/decoding step on either side purely for the sake of fitting inside XML text content, and it never has to be inflated by roughly a third the way base64 encoding otherwise requires.