Der XML Activator-Verbraucher verarbeitet einen iPool und erstellt eine Ausgabedatei für die einzelnen Objekte, die angetroffen werden. Der Activator verarbeitet den iPool in Transaktionsstapeln von ungefähr 1.000 Objekten, und erstellt ein neues Unterverzeichnis für die einzelnen Stapel.

Die einzelnen Unterverzeichnisse werden entsprechend dem folgenden Format benannt: ll_%YY%MM%%DD_%HH%%MM%%SS_N. Hierbei ist YY das Jahr, MM der Monat, DD der Tag, HH die Stunde, MM die Minute und SS die Sekunde, in der der Aktivator gestartet wurde und N ist eine nach links aufgefüllte Nummer mit 6 Zeichen, die mit 000000 beginnt.

Jedes Unterverzeichnis enthält Dateien mit Namen N.xml,, wobei N eine nach links aufgefüllte Zahl mit drei Stellen ist.

Ein Prozess von Drittanbietern verarbeitet erwartungsgemäß alle Verzeichnisse und Dateien in einer nach Lexikographie oder Zeit der Änderung ausgerichteten Reihenfolge. Der Drittanbieterprozess verarbeitet nur Dateien namens *.xml. Das letzte noch in einer Transaktion befindliche Verzeichnis enthält *.tmp-Dateien, die nach Beendigung der Transaktion umbenannt werden. Der Drittanbieterprozess soll bei der Verarbeitung Verzeichnisse bereinigen, die nur *.xml-Dateien enthalten. Der Activator reinigt nur die *.tmp-Dateien fehlgeschlagener Transaktionen.

Die einzelnen Dateien werden im UTF-8 XML-Format erstellt und spiegeln den Inhalt einer iPool-Objektnachricht genau wieder. Eine iPool-Objektnachricht enthält einen Vorgang, der entweder AddORReplace oder Löschen angibt, eine URN, die einen eindeutigen Namen für das Objekt angibt und eine oder mehrere gemischte Metadaten- und Inhaltsbereiche. Die Metadatenattribute sind verschachtelte Schlüssel/Wert-Paare. Zum Großteil handelt es sich dabei um XML-Daten, mit Ausnahme der Daten, die von Modulen mit schlechtem Verhalten hinzugefügt wurden (meist Workflows). Die Inhaltsbereiche enthalten entweder Text- oder Binärdaten.

Die erstellte XML-Datei erhält möglichst viel der ursprünglichen Metadatenstruktur. Wenn ein Bereich von Metadatentext, die XML-Spezifikation verletzt, wird das näheste umschließende Tag als mit base64 codierten Daten gekennzeichnet. Der Drittanbieterprozess legt fest, wie die schlecht formatierten Metadaten verarbeitet werden.

Der Inhaltsbereich ist immer mit base64 codiert.

Die erstellten XML-Dateien haben jeweils das folgende Format:

  <?xml version="1.0"?>
    <xml_object>
        <operation>AddOrReplace or Delete</operation>
        <oturn encoding='base64'>base64 encoded urn</oturn>
        <metadata>
           <field1>....</field1>
           <field2 encoding='base64'>...</field2>
           <field3>...</field3>
           ...
           <fieldN encoding='base64'>...</fieldN>
        </metadata>
        <content encoding='base64'>
           Base64 encoded content.
        </content>
        <metadata>
           ...
        </metadata>
        <content>
        ...
        </content>
       ...
    </xml_object>