Skip to topic | Skip to bottom
Home

Tesi
Tesi.IsaArchitecturer1.11 - 23 Oct 2008 - 22:49 - DevidMarcantonitopic end

Start of topic | Skip to actions

ISA Architecture

Verifica della modularità di ISA. Studio di un meccanismo per il supporto di formati esterni embedded. Integrazione di convertitori esisteni, quali quelli per i formati grafici vettoriali e per la matematica.

Tesi assegnata a DevidMarcantoni

Prime attività

  • Studio del codice Java dell'applicazione ISA per capire come vengono implementate le conversioni da IML verso i vari formati e viceversa
  • Reperimento codice già esistente per le conversioni di formati esterni embedded (ad ora la conversione DrawingML? to SVG)
  • Ideare un modo per integrare tali convertitori all'interno di ISA cercando di lasciare all'utente maggiore libertà possibile sul formato di rappresentazione degli oggetti esterni

Creazione sistema di conversione di oggetti esterni (prima implementazione)

Dopo aver studiato il convertitore DrawingML? to SVG ho deciso di utilizzarlo come "cavia" per implementare un meccanismo generale di conversione di oggetti esterni da integrare in ISA. Nel fare ciò ho cercato di mantenere lo schema di realizzazione usato nelle altre parti del progetto (come digester) e di rendere il tutto piu malleabile possibile mediante l'utilizzo di file di configurazione. L'idea generale è quella di avere un package chiamato FO_Processor (foreign object processor) che si occupa della gestione di formati embedded , in tale package ci sono funzioni in grado di estrapolare dal contenuto di un documento tali oggetti, di risolvere il formato di destinazione (mediante la consultazione di file di config) e di scegliere quindi il processore che esegue la conversione appropriata. Al momento tutto questo avviene in 2 punti in ISA:
  • dopo la generazione dell'IML (all'interno del cossiddetto FG_Processor), in cui si può scegliere di "mantenere" il formato esterno di input o di convertirlo in qualcos'altro.
  • dopo la conversione del documento nel formato di destinazione (all'interno del cossiddetto Pic_Processor), in questo caso gli oggetti embedded saranno destinati al formato di output scelto nel file di config.

La spiegazione dettagliata della struttura adottata è nella relazione in allegato.

Il DOCX come formato di input/output e modifica del punto di intervento del sistema di conversione in ISA

Pur non facendo parte di questo modulo, un momento molto importante per la programmazione del motore di conversione "Foreign Objects" è stato quando è stato inserito il formato DOCX come possibile input e output nel sistema ISA. Questa inclusione, prodotta da me e Paolo sulla base di un lavoro precedente di un tesista, mi ha permesso da un lato di provare le conversioni su file "veri" (prima usavo IML dummy in cui inserivo codice DrawingML? importato da Word) e dall'altro di capire che il punto nel codice dove venivano processati gli oggetti esterni non era corretto. Mi sono reso conto che il FO_Processor deve essere una entità a parte ed essere sganciata dai vari processori già esistenti. Non ha senso per esempio inserirla all'interno del FG_Processor quando questo non è sempre richiamato, ma lo è solo in presenza di determinati formati di input (in caso di input IML FG_Processor non andrà mai in esecuzione). Inoltre sono arrivato alla conclusione che il Pic_Processor deve essere usato per produrre l'output finale nel formato appropriato che non è detto sia semplice testo ma può essere anche uno zip (come docx) o qualcos'altro. Per questo, prendendo sempre l'esempio di docx, non ha senso una volta formato lo zip di tornare indietro per processare gli oggetti embedded. Quindi ho deciso di far si che tali oggetti vengono processati prima dell'attivazione del Pic_Processor stesso.

Ulteriori convertitori

Arrivato a questo punto, non restava che testare il buon funzionamento del sistema includendo anche gli altri convertitori a mia disposizione:
  • VML -> SVG (bidirezione)
  • SVG -> DrawingML?
  • OMML -> MathML (bidirezionale)
In questo modo si ha un perfetto mapping tra formati aperti (SVG per le immagini e MathMl? per le formule) e proprietari di Word (DrawingMl? e VML per le immagini e OMML per la matematica). Tra i vari test presi in considerazione, sicuramente il più indicativo è quello che, dato in input a ISAPress un file DOCX contenente vari oggetti embedded nei formati sopra descritti, permette di avere in output il DOCX stesso passando però per IML per quanto riguarda il testo del documento e per SVG e MathML per quanto riguarda invece i foreign objects. Il risultato del test si può ritenere più che soddisfacente per quanto riguarda DrawingML? e OMML, purtroppo la conversione VML->SVG presente diversi problemi a mio avviso non imputabili al sistema ma dovuti al convertitore stesso.

Spiegazione dettagliata del lavoro svolto

Il punto di partenza
ISA è un sistema in grado di eseguire conversioni tra formati dato differenti, passando attraverso un formato intermedio (IML). Il processo è quindi FORMATO DI INPUT -> IML -> FORMATO DI OUTPUT. Dal punto di vista procedurale il funzionamento di ISA è mostrato nello schema seguente:

Isa_Classic.jpg

Nella parte sinistra della figura viene processato il documento di input, mentre nella destra viene processato il template che consente di costruire lo stylesheet appropriato per quel documento. L'applicazione del XSLT al file in ingresso produrrà il formato di destinazione. Per lo scopo di questa tesi interessa solamente la prima parte, le cui fasi più significative sono:

  • ReadDocument Il sistema riceve in input il file da convertire e, nel caso di formati non testuali (ex odf e docx che sono archivi zip), ne produce una rappresentazione di tipo stringa.
  • ISA_Core Questa è la fase in cui viene prodotto il formato generico.A seconda del formato del file di input verrà istanziato il processore appropriato che produrrà la rappresentazione IML del documento iniziale.
  • FG_PROCESSOR A seconda dell'output desiderato può essere necessario eseguire delle modifiche all'IML in modo da renderlo conforme con eventuali spercifiche. Queste variazioni vengono eseguite all'interno di questo modulo. Un esempio è: se l'output è diretto al Mulino, i "p" consecutivi di tipo "glossa" vengono racchiusi in un "div".
  • PIC_PROCESSOR Questa fase viene eseguita quando già si ha la rappresentazione stringa del file nel formato di output desiderato. Consente sia di eseguire dei raffinamenti al documento convertito che, quando necessario, costruire il documento finale in modo non testuale (ex nel caso di docx creare il pacchetto zip).

Un caso d'uso può essere quello di voler convertire un documento scritto con Word2007 (docx) con gli stili appropriati in DocBook? per il Mulino. In questo frangente ISA si comporta in questa maniera:

  • la ReadDocument? importa il file docx e produce una rappresentazione XML unica dei vari componenti del pacchetto (con dei tag appositi che i identificano files e cartelle)
  • ISA_Core applica uno stylesheet che consente di trasformare questo XML simil-DOCX in IML rispettando i vari pattern
  • FG_Processor sempre attraverso un XSLT raffina l'IML in modo che questo segua le specifiche del Mulino (glosse, box etc...)
  • Dal ramo destro della figura giunge lo stylesheet da applicare all'IML (il famoso IML->DocBook che avevo realizzato nella tesi precedente)
  • Il PIC_Processor in questo caso non esegue nessuna operazione significativa.

La gestione degli oggetti esterni
Fatta questa introduzione sul funzionamento delle varie parti che compongono ISA, il passo successivo e' quello di definire il lavoro finora svolto in questa tesi. Diversi editor di testo (tra cui Word e OpenOffice) permettono di inserire nei documenti degli oggetti esterni per alcune rappresentazioni (ex grafica vettoriale o formule matematiche).Tali oggetti vengono immessi con dei propri formati all'interno del codice vero e proprio. Il problema era che ISA non gestiva tali inclusioni e lo stesso IML, nella sua semplicità, non possedeva costrutti per formalizzare tali oggetti. L'idea di questo lavoro era quello di integrare all'interno di ISA un "sottomotore" di conversione per questi formati sfruttando dei convertitori già esistenti realizzati da dei tesisti e completamente indipendenti da ISA. Inoltre ideare un nuovo costrutto IML in grado di segnalare la presenza di oggetti "particolari".

Le scelte implementative
Da un punto di vista implementativo, è stato scelto di costruire per i formati esterni delle conversioni 1 a 1 (senza adottare un passaggio interemedio con un linguaggio simil-IML per tali oggetti) e di fornire la possibilità di scegliere, attraverso un file di configurazione, quale di questi formati adottare per l'IML intermedio. Quindi, assumendo SVG come formalismo per le immagini in IML, qualunque oggetto embedded (di genere immagine) nel documento di input verrà trasformato in SVG nella trasformazione verso il fomato generico, e, successivamente, verrà applicata la trasformazione SVG->"oggetto esterno di output" al momento della trasformazione finale. Questa doppia conversione non è sempre necessaria, infatti è possibile definire il file di configurazione in modo che l'IML non abbia un proprio formato di default per tali oggetti, ma erediti quello del file in input. In questo modo verrà eseguita solamente la seconda trasformazione. Come si vede dallo schema seguente, ISA è stato integrato con un nuovo modulo (FO_Processor) che si occupa proprio di andare a scovare questi "foreign_objects" e convertirli nel modo desiderato. Si noti che tale processo viene eseguito due volte, uno dopo la generazione del formato generico e un'altra dopo aver ottenuto il formato di output.

ISA_new.jpg

Per far si che questi oggetti siano identificati dal flusso normale del documento è stato ideato un nuovo elemento "div" con class "foreign-object" e type "format-identifier" che al suo interno contiene il codice nel formato esterno e nell'attributo type una stringa per identificare tale formato. Questi particolari div dovranno quindi essere considerati neutri e non processati dai convertitori classici, mentre il FO_Processor, nel passo successivo, si occupa proprio di andare a cercarli all'interno del codice XML, estrapolarli e convertirli utilizzando il processo di conversione adatto. Nell'esempio successivo sarà più chiaro il funzionamento del sistema.

Caso d'uso

In questa parte è presentato un esempio sul funzionamento interno di ISA con il nuovo modulo FO_Processor. Consiste nella trasformazione di un file DOCX (contentente un immagine vettoriale (drawingML) e una formula matematica (OMML)) in se stesso passando però attraverso IML, SVG (per l'immagine) e MathML (per l'espressione).

docx.JPG

Il codice all'interno del pacchetto docx che sarà processato è il seguente:

<w:document>
   ...
    <w:t>primo paragrafo</w:t>
   ...
    <w:drawing>
        ...Frammento drawingMl
    </w:drawing>
     ...
    <w:t>secondo paragrafo</w:t>
   ...
   <m:oMathPara>
     ....frammento OMML...
   </m:oMathPara>

</w:document>

Dopo il passaggio attraverso la readDocument, ISA_CORE e FG_Processor (non modificati dalla versione precedente di ISA) si otterrà:

<iml>
   ...
   <p>primo paragrafo</p>
   ...
   <div class="foreign_object" type="image/drawingml+xml">
     ...frammento drawingML...
   </div>
   ...
   <p>secondo paragrafo</p>
   ...
   <div class="foreign_object" type="application/omml+xml">
     ...frammento OMML...
   </div>

</iml>

A questo punto entra in gioco la prima istanza di FO_Processor, che ricerca i div che rappresentano oggetti embedded ed esegue la conversione. La scelta del convertitore avviene dopo la consultazione di un file di configurazione simile al seguente:

<fo_config>
   <mime_types>
      <draw>
         <format name="svg" mime_type="image/svg+xml"/>
         <format name="drawingml" mime_type="image/drawingml+xml"/>
         <format name="vml" mime_type="image/vml+xml"/>
      </draw>
      <math>
         <format name="mathml" mime_type="application/mathml+xml"/> 
         <format name="omml" mime_type="application/omml+xml"/> 
      </math>
   </mime_types>
   <input_formats>
      <iml>
         <draw type="svg"/>
         <math type="mathml"/>
      </iml>
   </input_formats>
   <output_formats>
      <isa_press_iml>
         <draw type="svg"/>
         <math type="mathml"/>
      </isa_press_iml>
      <isa_press_docbook>
         <draw type="svg"/>
         <math type="mathml"/>
      </isa_press_docbook>
      <isa_press_docx_mulino>
         <draw type="drawingml"/>
         <math type="omml"/>
      </isa_press_docx_mulino>
   </output_formats>
</fo_config>

Si prenda in esame il primo dei due "div":

  • Per prima cosa il sistema, leggendo il type del div, si accorge, consultando i nodi figli di mime_types, che siamo in presenza di un frammento drawingML e di conseguenza di un'immagine.
  • Successivamente controlla se siamo nella prima istanza di FO_Processor (IML) o nella seconda (formato di output). Siccome siamo ancora nella prima fase va nel ramo input_formats e verifica che formato si desidera per rappresentare le immagini in IML (in questo caso SVG => draw typ="svg").

Deciso ciò, il sistema istanzia di processore DrawingML?->SVG presente nel sistema passandogli in input il frammento in esame e sostituendolo poi nel codice col corrispondente frammento svg. Stessa cosa viene fatta con il codice OMML, che viene sostituito dal corrispondente MathML.

Quindi, dopo la prima applicazione di FO_Processor, si ha questa situazione:

<iml>
   ...
   <p>primo paragrafo</p>
   ...
   <div class="foreign_object" type="image/svg+xml">
     ...frammento svg...
   </div>
   ...
   <p>secondo paragrafo</p>
   ...
   <div class="foreign_object" type="application/mathml+xml">
     ...frammento MathMl...
   </div>

</iml>

A questo punto, avendo raggiunto il formato intermedio completo, non resta che passare al documento di output. Si è deciso di "tornare" nuovamente a docx. Quindi verrà applicato all'IML precedente lo stylesheet per passare al formato XML di docx (in un unica stringa, lo zip sarà formato alla fine nel Pic_Processor), ottenendo un risultato del genere (da notare che gli XSLT a questo livello debbono ignorare i foreign objects):

<w:document>
   ...
    <w:t>primo paragrafo</w:t>
   ...
    <div class="foreign_object" type="image/svg+xml">
        ...Frammento svg...
    </div>
     ...
    <w:t>secondo paragrafo</w:t>
   ...
   <div class="foreign_object" type="application/mathml+xml">
        ...Frammento MathMl...
    </div>

</w:document>

Ecco qua che viene instanziato per la seconda volta il FO_Processor, con il compito ancora una volta di convertire il contenuto dei vari div "esterni" consultando il file di configurazione, sapendo stavolta però di trovarsi nella seconda fase. Perciò si va a guardare il ramo output_formats selezionando il formato di output corrente e si osserva che isa_press_docx_mulino desidera drawingML per le immagini e OMML per la matematica. Siccome siamo in presenza di SVG e MathMl? il sistema dovrà istanziare i converitori SVG->DrawingMl e MathML->OMML per ottenere un docx corretto.

Fatto ciò nel Pic_Processor verrà creato il pacchetto zip e si avrà un file docx che, aperto con Word, avrà un aspetto uguale (diciamo simile) all'originale.

Considerazioni

Al momento i formati gestiti dal sistema sono:

  • Grafica vettoriale DrawingML? VML SVG
  • Formule Matematiche OMML MathML

In particolare in ISA vi sono i seguenti convertitori:

  • DrawingML? -> SVG
  • SVG -> DrawingML?
  • VML -> SVG
  • SVG -> VML
  • OMML -> MathML
  • MathML -> OMML

Tali convertitori erano stati implementati in precedenza da diversi tesisti in lavori indipendenti dal processo ISA, sono allora stati modificati/aggiustati per poter essere conformi al motore di conversione.

Grazie al sistema sopra descritto, inserire nuovi formati dati e nuovi convertitori non presenta particolari difficoltà, è sufficente includere le relative informazioni nel file di configurazione e integrare i processori creati seguendo le opportune specifiche.

Putroppo la conversione VML->SVG non funziona come dovrebbe per problemi dovuti al convertitore stesso e non al sistema di gestione degli oggetti esterni.
to top

I Attachment sort Action Size Date Who Comment
ISA.doc manage 120.5 K 16 May 2008 - 18:24 DevidMarcantoni Relazione sul funzionamento di ISA
ISA_foreign_Objects.docx manage 19.7 K 24 Jun 2008 - 11:54 DevidMarcantoni  

You are here: Tesi > ArgomentiDiTesi > IsaArchitecture

to top

Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Fabio's Wiki? Send feedback