Il trattamento degli allegati da parte del server eXtraWay ha due aspetti.
Il primo consiste nella loro gestione: collocazione su file system, spostamento da una posizione ad un'altra, rimozione, destinazione a storage area di diverso livello e così via.
Il secondo consiste nel compierne l'opportuno utilizzo in fase di indicizzazione dei contenuti e/o nel riconoscere gli allegati effettivi da quelli derivati¹⁾.

Quanto detto si è sino ad ora attuato avvalendosi di un particolare name space e di elementi ed attributi riferiti a tale namespace aventi caratteristiche fisse su cui il server potesse fare affidamento. Lo stesso risultato si può ottenere avvalendosi di Processing Instruction che assolvono allo stesso compito ed hanno il vantaggio di non avere effetti diretti o indiretti sull'eventuale DTD che regola il contenuto di un'Unità Informativa XML.
In ultimo, era stata introdotta tempo fa la possibilità di indicare gli allegati in elementi/attributi liberi limitandosi a dichiarare quali essi fossero²⁾. Questo sistema ha però una carenza: impedisce di definire che tipo di derivazioni compiere dall'allegato in esame e come trattare il risultato.

Per completare lo scenario descritto si suggerisce l'implementazione di quanto segue:

• Gli allegati saranno comunque identificati in una delle modalità sino ad ora supportate: con un percorso assoluto o relativo ovvero tramite un identificativo logico (un ID rappresentato da un numero seguito da un'estensione).
• La trasformazione che si desidera effettuare per questi allegati deve sempre fare riferimento all'identificatore di cui al punto precedente ed altrettanto varrà per l'esito della conversione, così da costituire un legame che possa essere mantenuto e gestito nel tempo (ad esempio rimuovendo gli allegati derivati di un allegato all'atto dalla sua rimozione).
• Per ottenere la conversione di un file è necessario esplicitare che tipo di conversione si desidera ottenere e che tipo di trattamento il server deve compiere ad operazione completata. In pratica, l'unico dato realmente utile al server è sapere se l'esito della conversione sia da indicizzare o meno.
• A conversione avvenuta, la richiesta di conversione va rimossa ed il suo posto va altresì preso dall'esito della stessa, a sua volta rappresentato da una Processing Instruction

Condizione necessaria e sufficiente perché il server eXtraWay abbia un comportamento corretto nei confronti di quanto presente nella Processing Instruction è che essa sia conformata in modo equivalente ad un elemento XML auto-chiuso caratterizzato da uno o più attributi. Questa caratteristica vale sia per la P.I. di richiesta conversione che per quella che identifica la conversione già avvenuta.

Il procedimento avrà quindi il seguente comportamento:

• L'applicazione appone nel record XML, nella posizione ritenuta più consona ai propri scopi, una P.I. conformata come indicato avente come label la stringa 'xw-toderive'.
  In tale P.I. devono essere presenti uno o pià pseudo-attributi. Essi sono:
  
  • name: al pari dell'attributo name dell'elemento xw:file e del corrispondente pseudo-attributo della P.I. xw-file, esso identifica l'allegato. Obbligatorio;
  • index: anche in questo caso il senso di questo pseudo-attributo è analogo a quello degli elementi descritti. Se presente e con valore pari a 'yes', indica al server che l'esito della conversione dev'essere sottoposto ad indicizzazione. Facoltativo;
  • Uno o più ulteriori pseudo-attributi necessari al sistema di conversione per sapere come operare. Tra essi possono apparire (valori suggeriti)
    • content_type (Questo potremmo quasi considerarlo obbligatorio)
    • label
    • …
• Il server riconosce la richiesta di conversione e passa l'intero contenuto della medesima ad un processo “near on line” del server stesso che provvederà a richiedere ad un servizio opportuno la conversione richiesta passando ad esso tutti i parametri trovati nella P.I.;
• Ottenuto il risultato della conversione, il server modifica il documento come segue:
  • Identifica la P.I. xw-toderive cui corrisponde la conversione effettuata.
  • Rimuove la P.I. appena identificata e la sostituisce³⁾ con un'equivalente P.I. che conterrà:
    • name: identificatore del nuovo allegato derivato da quello orignario. Obbligatorio;
    • der_from: identificatore dell'allegato originario. Obbligatorio;
    • index: ereditato dalla P.I. xw-toderive. Indicherà se compiere o meno l'indicizzazione. Facoltativo;
    • Tutti gli altri pseudo-attributi sottoposti alla richiesta di conversione. In questo modo si saprà sempre come questo file è stato derivato (con quali parametri etc. etc.) e si avrà ad esempio cognizione del sul content_type e così via.

Non sono stati imposti limiti o vincoli sugli pseudo-attributi proprio per garantire il massimo grado di libertà nella loro definizione. Su suppone però che una parte di essi sia necessaria al processo di conversione per sapere in quali modalità operare ed una parte avrà invece scopi applicativi tesi ad identificare il ruolo di ogni allegato derivato, il perché esso sia stato elaborato e quindi come farne uso applicativamente.

Visto che al momento in cui si scrive il servizio di conversione che possa operare secondo le modalità indicate ancora non esiste, i dettagli sugli pseudo-attributi necessari alla conversione verranno concordati in seguito, se pure è ragionevole ritenere che il content_type (o altro equivalente) dovrà necessariamente esistere.