Differenze

Queste sono le differenze tra la revisione selezionata e la versione attuale della pagina.

--- documentazione_3di_riservata:extraway:attachment [2011/06/24 17:13] – rtirabassi
+++ documentazione_3di_riservata:extraway:attachment [Data sconosciuta] (versione attuale) – eliminata - modifica esterna (Data sconosciuta) 127.0.0.1
@@ Linea 1: / Linea 1: @@
-====== Trattamento degli allegati (Proposta di rinnovamento) ======
-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((Frutto di trasformazione degli allegati originari per mezzo di un servizio di conversione)).\\
-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((Via XPath)). 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((La sostituzione avviene sul posto, se possibile o nelle più immediate prossimità, come "ultimo figlio dell'elemento parent".)) 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__.
-Rispetto ai sistemi adottati sino ad ora, il legame tra //derivato// e //derivante// è mono direzionale (nel derivato si conosce l'//ID// del derivante) anziché essere bidirezionale. Le restanti informazioni sono disponibili esattamente come lo erano in passato, in quanto il fatto che una derivazione sia stata compiuta si evidenzia con la presenza del risultato (e non più della sola richiesta).\\
-In caso di fallimento della conversione (ad esempio perché il servizio di conversione non è in grado di ottenere un file di un certo tipo partendo dal tipo di allegato originario) la //P.I.// ''xw-toderive'' rimane del tutto invariata (anche se il comando di conversione non viene reiterato). In questo modo, ad esempio all'atto dell'aggiornamento del servizio di conversione, si può richiedere di tentare ex-novo tutte le conversioni sino a quel momento fallite((Il comando esiste già per gli ''xw:file'' e va solo esteso)).
-===== Esempio =====
-In un documento esiste da qualche parte un allegato 1.doc.\\ Volendo ottenere la conversione in PDF e l'estrazione del testo per fare gli indici si indicherà:\\
-<code>
-<?xw-toderive name="1.doc" content_type="application/pdf"?>
-<?xw-toderive name="1.doc" content_type="text/plain" index="yes"?>
-</code>
-Ad operazione completata, il server sostituisce le //P.I.// come segue:
-<code>
-<?xw-file name="2.pdf" der_from="1.doc" content_type="application/pdf"?>
-<?xw-file name="3.txt" der_from="1.doc" content_type="text/plain" index="yes"?>
-</code>