Conversione tra formati documentali aperti

Transcript

Indice
1.
INTRODUZIONE ................................................................................... 3
2.
LA CONVERSIONE TRA FORMATI .................................................... 6
2.1
La rappresentazione del testo ............................................................. 7
2.2
Il markup .......................................................................................... 9
2.3
Segmentazione dei documenti ......................................................... 12
2.4
Modelli generali di conversione....................................................... 15
2.4.1
Modello diretto ........................................................................ 15
2.4.2
Modello ad anello .................................................................... 16
2.4.3
Modello con formato intermedio .............................................. 17
2.5
3.
2.5.1
Microsoft Office e OpenXML .................................................. 19
2.5.2
OpenXML/ODF Translator 1.0 ................................................ 20
2.5.3
Microsoft Office Compatibility Pack ........................................ 21
2.5.4
OpenXML File Format Converter for Mac 0.1.1 (Beta) ............ 21
2.5.5
docXConverter 1.3 ................................................................... 22
CONVERSIONE DA OFFICE OPENXML........................................... 23
3.1
4.
Office OpenXML e convertitori ...................................................... 18
Office OpenXML ............................................................................ 23
3.1.1
Specifiche tecniche .................................................................. 23
3.1.2
Basi di WordprocessingML ...................................................... 25
3.2
IML ................................................................................................ 29
3.3
Si-ConForMi OpenXML ................................................................. 31
3.3.1
Uso di Si-ConForMi OXML .................................................... 33
3.3.2
Obiettivi raggiunti .................................................................... 34
3.3.3
Esempi di conversione ............................................................. 35
IMPLEMENTAZIONE DI “SI-CONFORMI OXML”........................... 40
1
5.
4.1
API in Java per XML ...................................................................... 40
4.2
Il motore di conversione (Java) ....................................................... 41
4.2.1
DocumentConverter.java ......................................................... 42
4.2.2
ZipCompressor.java ................................................................. 43
4.2.3
DocumentMapper.java ............................................................. 43
4.2.4
XmlParser.java ........................................................................ 44
4.2.5
MapParser.java ........................................................................ 44
4.2.6
RelParser.java .......................................................................... 44
4.2.7
XSLTransformer.java .............................................................. 44
4.2.8
ImlParser.java .......................................................................... 44
4.3
MappingML.................................................................................... 45
4.4
XSLT .............................................................................................. 46
4.4.1
Trasformazione OOXML(MappingML) – IML ........................ 46
4.4.2
Trasformazione IML-OOXML(MappingML) .......................... 47
4.5
Conversione OOXML – IML .......................................................... 47
4.6
Conversione IML - OOXML .......................................................... 49
4.7
Limiti dell‟implementazione ........................................................... 50
CONCLUSIONI.................................................................................... 51
Elenco delle figure ........................................................................................ 53
Bibliografia ................................................................................................... 54
Ringraziamenti.............................................................................................. 57
2
1. INTRODUZIONE
Lo scopo di questa tesi è dimostrare che la conversione dei formati
documentali è un problema che può essere risolto mediante la risoluzione dei
suoi sottoproblemi di conversione, raggiungendo in questo modo un risultato
più funzionale. In particolare viene proposto un approccio di conversione tra
documenti digitali basato su segmentazione, ossia su scomposizione e
conversione sistematica di sotto-componenti.
La conversione di un formato documentale è quindi un problema che può
essere frammentato in più parti, che sono l‟identificazione e la conversione
delle singole sotto-componenti che descrivono il documento, e la
scomposizione del processo di trasformazione verso il formato di arrivo
(utilizzando un formato intermedio per il mapping dei vari tipi di dati). Questo
sistema consente di ottenere un maggiore controllo sulla gestione della
conversione stessa, poiché permette di agire in maniera diretta sulle singole
componenti di interesse del documento. Inoltre, seguendo un modello di
conversione che passa attraverso un formato intermedio viene semplificata
notevolmente l‟architettura generale permettendo di creare un convertitore
versatile, ed aperto a nuovi sviluppi con la possibilità di gestire potenzialmente
un qualsiasi formato target.
L‟argomento di questa tesi è incentrato su di un progetto che prevede la
realizzazione di un convertitore bidirezionale tra formati documentali XML
aperti, in particolare da Office OpenXML, un formato che cerca di imporsi
come standard per la rappresentazione dei documenti, e un formato intermedio
che apre le porte alla portabilità e alla pluralità dei formati.
La conversione dei dati è sempre stato un problema cardine sin da quando
esiste la necessità dello scambio di informazioni tra applicazioni diverse. Tale
problema si è poi accentuato con la nascita ed il moltiplicarsi delle tipologie di
documenti, soprattutto con lo sviluppo di Internet e del World Wide Web nei
primi anni novanta. Internet ha infatti aumentato in modo esponenziale lo
scambio dei documenti e subito si è sentita la necessità di creare degli standard.
Uno dei più importanti per Internet è stato ovviamente l’HyperText Markup
Language (HTML) [W3C07] che grazie anche alla sua semplicità, ha ottenuto
una rapida diffusione. L‟altra faccia della medaglia si vide però quando
l‟HTML cominciò ad essere utilizzato più per l‟aspetto presentazionale che per
quello semantico. In aggiunta si scorsero ben presto i suoi limiti progettuali e
3
nacque la necessità di trovare soluzioni che permettessero di aumentare le
potenzialità grafiche cercando di separarle quanto più possibile dai contenuti.
Con la standardizzazione di Extensible Markup Language (XML) [W3C06] si
videro le potenzialità che questo meta-linguaggio di markup poteva offrire
anche come sostituto dell‟HTML nel ruolo di standard per il World Wide Web.
In particolare l‟XML porta con sé l‟innegabile vantaggio della creazione di
documenti auto-descrittivi che trasformati poi attraverso l‟uso di fogli di stile
permettono un maggior controllo sull‟aspetto presentazionale e una maggiore
indipendenza del contenuto a vantaggio di una maggiore leggibilità del codice.
Grazie a questa caratteristica e per come è stato progettato, l‟XML va al di là
del semplice obiettivo di sostituzione di un linguaggio, ma si presenta come la
soluzione per l‟interscambio dei dati.
XML è tuttora diventato il fondamento dei più moderni formati documentali.
E‟ utilizzato non solo per la descrizione di documenti di word processing
(formati come Open Document Format e Office OpenXML), ma per la
creazione di formati appartenenti a molteplici campi di applicazione, come la
grafica (Scalable Vector Graphics, Vector Markup Language) la musica
(MusicXML) e la matematica (Mathematical Markup Language).
Grazie a questa intercompatibilità e al supporto di una vera e propria famiglia
di linguaggi derivati che ne permettono la gestione e la trasformazione, XML
ha fornito un notevole contributo al settore della conversione dei dati.
La principale necessità degli utenti è quella infatti di poter passare da un
formato all‟altro in base alle proprie esigenze. Il più delle volte un documento
per essere processato ha bisogno di un software dedicato, e questo comporta
generalmente un problema per chi non dispone dell‟applicativo specifico.
Multinazionali del software, come ad esempio Microsoft ed Adobe, hanno
sempre cercato di mantenere una politica chiusa verso la compatibilità dei loro
formati con altre applicazioni, questo per cercare di vincolare in un qualche
modo le scelte degli utenti all‟uso dei loro programmi proprietari.
Un altro problema è quello della riutilizzabilità dei documenti, quando si ha la
necessità di recuperare un documento esistente per poterlo riadoperare in un
diverso ambito, oppure nel più semplice dei casi, per poter effettuare dei
cambiamenti sugli stili o la formattazione senza la necessità di dover apportare
manualmente le modifiche.
Per questi motivi la ricerca e lo sviluppo di software per la conversione dei dati
ha acquisito col tempo notevole importanza.
4
I software di conversione tuttora più diffusi sono quelli che operano in
modalità diretta da un formato all‟altro, ma purtroppo questi sono limitati
poiché non offrono quella versatilità di impiego desiderata, ed un utente ha
sempre l‟obbligo di dover cercare un programma specifico che attui la
conversione da lui richiesta.
Per questo si sente l‟esigenza di usufruire di convertitori di tipo universale che
operino la conversione verso un qualunque formato di destinazione. Come
discuteremo nel capitolo successivo per poter sviluppare un convertitore di
questo genere è però necessario rinunciare ad un modello di trasformazione
diretta a causa dei ragguardevoli costi di sviluppo e della sua architettura
complessa che sfavorisce il supporto di nuovi formati (uno svantaggio
abbastanza rilevante, dato dal fatto che l‟introduzione di nuovi formati sul Web
è un evento abbastanza frequente).
Per questo è fondamentale scomporre il processo di trasformazione in due fasi:
la prima che trasforma il documento da un formato sorgente ad un formato
intermedio, la seconda dal formato intermedio a quello target. Un convertitore
che segue questo tipo di modello è potenzialmente universale, vale a dire che
apportando i relativi aggiornamenti è possibile supportare con costi di sviluppo
limitati nuovi formati senza la necessità di dover modificare in modo rilevante
l‟architettura esistente.
Sviluppando poi un convertitore con un approccio basato sulla segmentazione
dei documenti, come nel caso del mio progetto, il processo di conversione di
un documento viene ulteriormente semplificato, poiché si suddivide nei relativi
processi di trasformazione delle sue sotto-componenti. Avendo un maggiore
controllo sulla gestione delle singole parti è possibile, oltre a migliorare la
qualità dell‟output nel formato finale, poter interscambiare tali componenti con
altre dello stesso tipo. Ciò rende possibile anche la modifica o la sostituzione di
una sola componente del documento originale ottenendo un documento
completamento diverso. Inoltre si aprono nuove opportunità che consistono
nella possibilità di utilizzare il convertitore anche per scopi diversi da quello
della conversione.
L‟esempio più calzante è quello del formatter, che ha il compito di cambiare gli
elementi di presentazione mantenendo lo stesso contenuto del documento di
partenza.
Nel successivo capitolo approfondiremo il tema della conversione tra i formati
cercando di analizzare il problema sin dalle sue origini.
5
2. LA CONVERSIONE TRA
FORMATI
Non ci sono parole per descrivere come la rivoluzione tecnologica portata da
Internet ha cambiato la nostra vita e di come può ancora evolvere. Da un‟idea
innovativa, un sogno , quello di poter condividere documentazione scientifica
in formato digitale, è nato nei primi anni novanta per mano del CERN
(Consiglio Europeo di Ricerca Nucleare) il World Wide Web. Allora non si
sarebbe mai immaginato che un progetto di questo tipo per quanto ambizioso
potesse essere, avrebbe acquisito l‟importanza e il successo odierno.
L‟opportunità di distribuire e reperire documenti, immagini, video, contenuti
multimediali e condividerli con il mondo in modo facile, veloce ed economico
è oggi divenuta una realtà per chiunque. Questa opportunità ci è stata data non
solo grazie all‟infrastruttura informatica mondiale, ma anche dall‟adozione di
formati come l‟HTML che ci permettono di descrivere i nostri dati in un
linguaggio di espressione comune, superando così le diversità delle piattaforme
e dei sistemi informativi.
La diffusione del Web e del suo sviluppo in molti settori di varia natura (che va
da quello della ricerca, a quello privato fino a quello commerciale) ha fatto sì
che venissero impiegati formati di memorizzazione dei dati sempre diversi per
venire incontro a differenti esigenze applicative. La molteplicità dei formati
che si possono trovare in rete hanno spesso bisogno di applicazioni dedicate in
grado di processarli, e questo comporta generalmente un problema per chi non
dispone del software necessario. Inoltre se si ha la necessità di modificare un
documento esistente oppure semplicemente riutilizzarlo in un diverso campo di
applicazione non è sempre possibile in maniera diretta.
Una soluzione idealizzata a questa difformità potrebbe essere quella di definire
un formato universale, cioè un formato standard di memorizzazione alla quale
tutti si dovrebbero attenere. Purtroppo la storia ci insegna che un consenso
globale è molto difficile da ottenere, specialmente quando si ha a che fare con
esigenze molto diverse. Ciò la rende una soluzione pressoché improponibile.
Per questi motivi nasce l‟esigenza di una conversione automatizzata dei dati fra
formati documentali.
Tuttavia la presenza meta-linguaggi in grado di generare linguaggi di markup
(argomento che affronteremo nella sezione successiva) fornisce un notevole
6
supporto al lavoro di conversione, in quanto agevola l‟identificazione della
struttura dei dati, in modo da rendere più facile la trasposizione fra formati. Fin
dapprima la nascita del Web diversi enti internazionali come ad esempio
l‟International Organization for Standardization (ISO) e l‟Institute of Electrical
and Electronics Engineers (IEEE) si muovono da sempre in questa direzione,
proponendo, concordando e ratificando nuovi standard nei diversi ambiti
cercando di agevolare la compatibilità delle tecnologie. Un traguardo
importante è stato raggiunto ad esempio da Standard Generalized Markup
Language (SGML, ISO 8879) [W3C95] dalla quale è derivato in seguito anche
l‟attuale HTML.
La vera rivoluzione però è stata rappresentata da XML, anch‟esso uno un metalinguaggo standard derivato da SGML ma con le caratteristiche necessarie per
diventare la base di tutti i più moderni formati documentali come Office
OpenXML [ECM06] e Open Document Format [OAS07].
In generale la conversione dei dati è un problema che ha soluzione tanto
complessa quanto sono strutturalmente differenti i formati da convertire. Per
capire meglio come affrontarlo in questo capitolo analizzeremo i principali
metodi di rappresentazione di un documento in formato elettronico, di come si
può scomporre un documento in varie parti fino ad arrivare ai modelli generali
di conversione. Infine parleremo di Office OpenXML e porteremo anche alcuni
esempi di convertitori che interessano il formato.
2.1
La rappresentazione del testo
Esistono vari metodi di riprodurre un documento cartaceo in formato
elettronico. I principali sono i seguenti [DDMR90]:
testo come bitmap: il documento è memorizzato in un file grafico ed è
descritto come griglia ortogonale di punti. La digitalizzazione di un
documento con uno scanner è l‟esempio più lampante per questo tipo di
rappresentazione. Un modello di questo tipo non permette alcun tipo di
accesso o modifica diretta al contenuto, esistono però tecnologie basate sul
riconoscimento del testo in grado di catturare dalle immagini sequenze
testuali e di interpretarle come sequenze di caratteri;
testo come stream di caratteri: è la forma più semplice per memorizzare un
flusso di testo. Essa prevede una semplice sequenza di caratteri con
l‟utilizzo di pochi caratteri separatori (come whitespaces e line breaks). E‟
la forma più comune di documento testuale non strutturato;
7
testo come stream di caratteri ed istruzioni di formattazione: è il modello
più utilizzato dai semplici editor di testo. Il modello prevede la
memorizzazione di stream di caratteri e di qualche istruzione per una
formattazione minimale. La strutturazione è comunque molto limitata in
quanto le informazioni presentazionali sono facoltative e strettamente
dipendenti dall‟applicazione di editing;
testo come stream di oggetti non gerarchici: questo tipo di modello è
utilizzato nella rappresentazione di documenti come Open XML. Essi
possiedono una struttura di elementi piatta e priva di gerarchia, con un
livello di annidamento degli elementi prestabilito. La categorizzazione del
ruolo degli elementi esiste ma è solo emulata con l‟assegnazione di attributi
di stile, utilizzati al solo scopo di definirne le caratteristiche presentazionali.
<w:p>
<w:pPr>
<w:pStyle w:val=”Titolo”/>
</w:pPr>
<w:r>
<w:t>Il titolo del mio documento</w:t>
</w:r>
</w:p>
<w:p>
<w:pPr>
<w:pStyle w:val=”Sottotitolo”/>
</w:pPr>
<w:r>
<w:t>Il sottotitolo del mio documento</w:t>
</w:r>
</w:p>
<w:p>
<w:pPr>
<w:pStyle w:val=”Normale”/>
</w:pPr>
<w:r>
<w:t>Contenuto del mio paragrafo</w:t>
</w:r>
</w:p>
testo come stream di oggetti gerarchici: è il modello definito come
Ordered Hiercal of Content Object (OHCO) il quale categorizza il
contenuto in elementi che sono totalmente indipendenti dalla loro
forma presentazionale.
8
<titolo>Il titolo del mio documento</titolo>
<sottotitolo>Il sottotitolo del mio
documento</sottotitolo>
<paragrafo>Contenuto del mio paragrafo</paragrafo>
I formati più diffusi sono basati sugli ultimi due modelli poiché il documento
ha una disposizione naturale alla suddivisione in parti ed oggetti. Tutt‟ora vi
sono però opinioni discordanti su quale sia la semantica che tali oggetti
debbano assumere. Gli sviluppatori del modello OHCO sono convinti che la
struttura gerarchica sia la forma migliore di espressione perché permette di
individuare e definire il ruolo degli elementi all‟interno del documento in modo
indipendente dalla presentazione [DDMR90] [DDMR96]. Altri (come ad
esempio gli sviluppatori di word processor) preferiscono disporre di una
struttura piatta, categorizzando gli elementi in base alla tipologia del contenuto
e a come devo apparire, poiché l‟aspetto è spesso quello che interessa
maggiormente all‟utente al momento della stampa.
Non esiste quindi un modello più corretto dell‟altro, esiste solo un approccio
migliore in base al contesto di utilizzo.
2.2
Il markup
Se volessimo ideare la forma di un documento come stream di testo dovremmo
innanzitutto pensare ad una struttura logica (che per noi abbia un significato
ben preciso) per esprimere le varie parti del nostro contenuto, in modo da
poterla interpretare all‟occorrenza; il primo istinto sarebbe quello di cercare di
descrivere le caratteristiche di ogni frammento del documento al fine di
esplicitare cosa sono, cosa devono rappresentare e come devono apparire.
L‟obiettivo sarebbe quindi “marcare” le varie parti del nostro contenuto per
definire che cosa per noi esse rappresentano.
In conclusione al termine del lavoro avremmo definito un nostro linguaggio di
markup. Markup è infatti definito in [CRD87] come ogni mezzo per rendere
esplicita una particolare interpretazione di un testo, ossia tutti quegli elementi
logici che ci permettono di agevolare la comprensione di un testo. Quindi
anche la punteggiatura è markup, in quanto non è testo ma ci serve per renderlo
più leggibile.
Vengono fatte varie classificazioni dei markup, fra le quali la diversificazione
fra binari (in linguaggio macchina) e human-readable (creato per poter essere
9
compreso da persone) e fra interni (markup inseriti all‟interno del contenuto
stesso) ed esterni (netta distinzione fra markup e contenuto). Un‟ulteriore
classificazione universalmente riconosciuta è quella effettuata da Coombs e
DeRose [CRD87] che distingue i markup in base alla loro funzionalità:
Markup Puntuazionale: aggiunge informazioni sintattiche al testo
(punteggiatura);
Markup Presentazionale: racchiude informazioni riguardanti la
presentazione del contenuto (come formattazione, stili ed effetti grafici);
Markup Procedurale: contiene una sequenza di comandi e procedure per il
sistema per la visualizzazione del contenuto;
Markup Descrittivo: identifica strutturalmente il contenuto assegnandogli un
ruolo all‟interno del documento;
Markup Referenziale: fa riferimento ad un‟entità esterna per fornire
significato o effetto grafico al contenuto;
Metamarkup: fornisce regole per l‟interpretazione del markup permettendo
di estendere e gestire markup;
L‟utilizzo dei markup descrittivi (soprattutto con l‟introduzione di SGML ed in
seguito XML) ha prevalso quello dei procedurali poiché col tempo hanno
dimostrato di possedere diverse caratteristiche qualitative. Ad esempio la
possibilità di definire il ruolo di un elemento all‟interno del documento senza la
necessità di ridefinire ad ogni occorrenza le sue proprietà di visualizzazione
(come invece esige la sintassi di un markup di tipo procedurale); questa è una
proprietà importante poiché ogni sistema di visualizzazione impone le proprie
regole sintattiche ed il markup descrittivo permette appunto di eludere la
problematica di creare codice incompatibile con altre piattaforme editoriali
(ovvero ogni sistema prevede una propria gestione presentazionale del markup
e del contenuto relativo associando gli elementi a categorie ben definite). Un
altro vantaggio di questo approccio è la possibilità di imporre dei vincoli sulla
correttezza di un documento (cioè avere la possibilità di definire regole sulla
struttura e sugli elementi a seconda del contesto specifico).
Il markup descrittivo è quindi una tecnica che predilige l‟identificazione della
struttura del documento, ed è utile anche dal punto di vista pratico dell‟editing:
per esempio l‟autore si può concentrare sulla stesura del testo e dei ruoli dei
frammenti, e magari preoccuparsi solo in seguito della gestione dei vari
elementi presenti e delle relative caratteristiche di formattazione; se il risultato
presentazionale non gli sarà gradito egli potrà scegliere di cambiare la forma in
10
modo semplice e veloce, anche nella circostanza che voglia riutilizzare la sua
opera in un diverso ambito.
Nel campo della conversione dei dati il markup descrittivo occupa un ruolo
estremamente importante perché proprio trasformando la struttura da esso
delineata possiamo convertire un formato in un altro. Infatti quando si cerca di
studiare un formato non si fa altro che analizzare il suo schema di markup.
Attualmente il principale strumento per la generazione di markup descrittivo è
XML, uno standard del World Wide Web Consortium (W3C). XML è un
metalinguaggio di markup derivato da SGML creato e progettato per lo
scambio e l‟interusabilità di documenti strutturati su Internet. I suoi punti
cardine sono:
Platform-independence: XML è uno standard aperto e chiunque può
realizzare strumenti che lo usino come formato di dati;
Documenti auto-descrittivi: permette la personalizzazione dei nomi degli
elementi, inoltre è possibile esplicitare regole di composizione fra le varie
parti dei documenti con la definizione di Document Type Definitions (DTD)
[W3C06];
Compatibilità con formati Web: la sua natura derivata da SGML lo rendono
facilmente convertibile con i moderni formati Web;
Generico: grazie ad una sintassi minima e rigorosa XML permette la
definizioni di linguaggi applicabili in un qualsiasi ambito;
Content-model misto: XML trova un punto di equilibrio tra i formati per
l‟interscambio dei dati e quelli per la strutturazione dei documenti di testo. I
content model misti (elementi che possono contenere sia testo che altri
elementi) permettono di inserire caratterizzazioni semantiche non solo per
interi elementi ma anche all‟interno di elementi di testo contenitori.
Strutturazione gerarchica degli elementi: mentre i precedenti documenti di
interscambio erano lineari XML ha permette strutture ad albero;
Navigabilità dei documenti: la sintassi rigorosa e la gerarchia garantita lo
rendono interfacciabile con varie tecnologie (DOM, XPATH) che ne
rendono semplice l‟analisi.
In supporto a questo formato è nata una vera famiglia di tecnologie fra cui una
delle più importanti è Extensible Stylesheet Language Trasformations (XSLT)
[W3C99b] che rende la trasformazione di documenti basati su XML
un‟operazione semplice ed efficace.
11
2.3
Segmentazione dei documenti
Un documento non è un‟entità indivisibile e può essere sezionata in più parti
che ne descrivono il contenuto nelle varie prospettive. Con il termine
segmentazione indichiamo quindi il processo di separazione di queste sue
componenti.
Questo principio è molto utile sia in fase di progettazione che di sviluppo di un
sistema di conversione. In primo luogo ci aiuta a definire meglio quali sono gli
obiettivi che si vogliono raggiungere in termini di qualità di trasformazione,
facendo una distinzione delle componenti logiche che si ha intenzione di
trasporre nel nuovo formato. In secondo luogo può ridurre la complessità del
lavoro in fase di sviluppo suddividendo le problematiche di conversione. Per
esempio se si utilizza un modello di conversione con formato intermedio
(argomento che affronteremo meglio in seguito) possiamo tentare di separare
fisicamente questi dati in modo da facilitare la loro trasposizione da un formato
all‟altro.
Andiamo ora ad analizzare come vengono classificate queste componenti. Il
classico modello di suddivisione che è generalmente riconosciuto in letteratura
è quello descritto da Glusko e Mcgrath [GM02], che identifica tre frammenti
principali:
Contenuto: l‟insieme di informazioni che il documento ha lo scopo di
trasmettere al lettore;
Componenti strutturali: l‟organizzazione del contenuto e della sua struttura;
Componenti presentazionali: la formattazione egli elementi che hanno lo
scopo di definire l‟aspetto grafico del documento;
Tuttavia si possono trovare molti casi in cui questa classificazione non è
sufficiente a categorizzare tutti i dati necessari. Se prendiamo come riferimento
il Web possiamo notare come le più moderne pagine HTML, i portali ed i
motori di ricerca variano i loro contenuti in modo del tutto dinamico
trasgredendo le vecchie concezioni di documento di tipo statico. Inoltre nel
modello precedente non trovano spazio tutte quelle varietà di informazioni
utilizzate per raccogliere, classificare ed indicizzare i documenti mettendoli in
relazioni con altre risorse dello stesso genere.
Per questo motivo nella tesi si prenderà come riferimento un modello di
classificazione più completo: il Pentaformato [DI07].
12
Figura 2.3-1: Il modello Pentaformato
Il Pentaformato è un modello di classificazione ideato dai ricercatori della
facoltà di Scienze Matematiche, Fisiche e Naturali di Bologna. Esso riconosce
la presenza di cinque dimensioni di informazione all‟interno del documento
che sono:
Contenuto: è rappresentato dal testo e dalle immagini (il modello per ora
tralascia i contenuti multimediali come audio e video);
Struttura: l‟insieme dei blocchi strutturati che esprimono l‟organizzazione
logica del contenuto. La struttura individua il ruolo degli elementi in
relazione al documento stesso;
Presentazione: l‟insieme delle caratteristiche visuali e tipografiche presenti
per massimizzare l‟impatto del documento sul lettore;
Behaviour: le informazioni che rendono il documento interattivo e dinamico
nell‟espressione del contenuto;
Metadati: l‟insieme di informazioni che descrivono il documento stesso e lo
mettono in relazione con risorse esterne;
Secondo questo modello qualsiasi documento può essere segmentato in queste
cinque parti. Le proprietà di tale generalizzazione sono:
Separazione logica: ogni dimensione contiene informazioni specifiche che
descrivono una prospettiva diversa del documento. Per separazione logica
non si intende necessariamente la separazione fisica dei dati, ma un concetto
astratto di categorizzazione delle informazioni;
13
Mutua connessione: ogni componente è interconnessa con le altre allo scopo
di interagire per la definizione del documento. Ognuna di queste è
indispensabile per descrivere il documento nella sua completezza;
Rilevanza basata sul contesto: non esiste gerarchia di queste dimensioni.
Ognuna di esse acquisisce una certa importanza in riferimento ad un
contesto specifico. Ad esempio la presentazione può risultare fondamentale
per un software per l‟editing di presentazioni multimediali, ma essere
totalmente trascurabile in un semplice applicativo per la correzione della
grammatica del testo;
Intercambiabilità basata sul contesto: ogni componente è indipendente,
ovvero è possibile la modifica di una singola dimensione senza che le altre
percepiscano gli effetti di tale cambiamento. Ciò rende possibile anche
l‟intercambiabilità di dimensioni dello stesso tipo. Per esempio un word
processor può contenere più stili di formattazione da applicare al documento
in modo interscambiabile, oppure una pagina HTML dinamica può
sostituire in modo regolare il suo contenuto;
Indipendenza dal linguaggio: ogni dimensione può essere espressa in
differenti linguaggi, tuttavia il significato delle informazioni contenute resta
invariato e può essere normalizzato;
Riassumendo questo modello permette di riconoscere le varie componenti di un
documento, di estrarle e di riformulare in base alle proprie necessità. I vantaggi
della sua applicazione in un sistema di conversione si possono riepilogare in:
Riduzione della complessità: il problema della conversione è scomposto nei
sotto-problemi di conversione delle singole componenti;
Adattabilità: ogni tipo di documento può essere adattato al modello
indipendentemente dalla piattaforma. In questo modo è possibile sviluppare
convertitori documentali di tipo universale;
Alta qualità dell’output: è possibile produrre documenti di alta qualità
potendo effettuare conversioni quasi complete (che non si limitano al solo
contenuto ed alla presentazione), ed alla possibilità di rimpiazzare le
componenti nel caso non si disponga delle informazioni necessarie;
14
2.4
Modelli generali di conversione
Ora che abbiamo analizzato come un documento può essere rappresentato in
forma digitale e le componenti in cui può essere scomposto possiamo
introdurre finalmente l‟argomento della conversione.
La conversione dei formati è un problema che può essere affrontato in diversi
modi. Se si vuole progettare un convertitore occorre prima effettuare uno
studio dei modelli di conversione esistenti per capire qual è la soluzione
migliore a seconda delle esigenze e degli obiettivi prefissati.
Una prima distinzione generica può essere effettuata sul tipo di approccio
utilizzato per la conversione [MBO93]:
string-oriented: il convertitore ha un approccio string-matching, ricerca un
particolare tag nello schema di partenza e lo rimpiazza con un altro
equivalente nello schema di destinazione;
structured-oriented: il convertitore oltre ad effettuare string-matching ha
anche il compito di modificare la struttura gerarchica dello schema;
I convertitori orientati alle stringhe sono utili nel caso si debbano effettuare
conversioni tra formati con poche regole di tipo strutturale e si debbano
effettuare principalmente semplici operazioni di traduzione da sintassi a
sintassi. Nelle conversioni più complicate dove occorre mutare non solo i nomi
dei tag ma anche la struttura interna vengono impiegati convertitori della
seconda tipologia.
I convertitori possono essere classificati in tre categorie principali che
riflettono il loro schema di conversione:
modello diretto (pairwise model) [DBW02] [MBO93]
modello ad anello (ring structure) [DBW02]
modello con formato intermedio (intermediate-form model) [DBW02]
[MBO93]
2.4.1 Modello diretto
Il modello di conversione diretto è sicuramente il più diffuso ed il più
utilizzato. Esso prevede due meccanismi di conversione (andata e ritorno) per
ogni coppia di formati di dati, cioè per
formati il costo di sviluppo è di
convertitori.
15
Figura 2.4-1: Modello diretto
Il pregio di questo modello è permettere la trasformazione da un formato
all‟altro in un solo passaggio di conversione ottenendo rapidamente un risultato
ottimale. I convertitori sono implementati ad hoc e non si subiscono alcuna
perdita di informazioni, oltretutto senza formati intermedi la conversione è
veloce ed efficiente. Tale architettura implica però non pochi svantaggi: il
costo di sviluppo è ingente, e per estendere il meccanismo al supporto di un
ulteriore formato è necessario implementare
convertitori (andata e ritorno
verso ogni formato presente nel sistema).
Riassumendo il modello è quello che offre i risultati migliori ma è quello che
ha anche il costo di sviluppo e di estendibilità più elevato.
2.4.2 Modello ad anello
Il modello ad anello è la più semplice e probabilmente la più obsoleta fra le
tecniche di conversione. Esso necessita dell‟utilizzo di
convertitori
monodirezionali per formati disposti astrattamente in un anello. L‟operazione
di conversione da un formato all‟altro avviene effettuando trasformazioni in
serie spostandosi lungo l‟anello nella direzione prestabilita fino a raggiungere il
corretto formato di destinazione.
16
Figura 2.4-2: Modello ad anello
Il vantaggio di questo modello è quello di essere il più economico poiché è
quello che richiede il minor numero di meccanismi di conversione, inoltre è
facilmente espandibile (richiede l‟aggiunta di solo 2 convertitori per il supporto
di un nuovo formato ). I difetti di questa struttura però sono più che evidenti:
nel caso medio si necessita di passaggi di conversione per poter ottenere il
formato desiderato e nel caso pessimo ben
. Questo implica scarsa
efficienza ed una consistente perdita di informazioni nella trasformazione. Se
poi nella catena di convertitori è presente un anello debole tutto il sistema è
compromesso.
2.4.3 Modello con formato intermedio
Il modello con formato intermedio si basa sul concetto di Superior Standard
[DBW02], cioè sull‟utilizzo di un formato generico che copre il ruolo di
intermediario nella conversione. Il sistema prevede l‟utilizzo di un formato
intermedio e
convertitori per formati.
In pratica le conversioni avvengono sostanzialmente in due passi: prima viene
trasformato il formato di partenza nel formato intermedio, il risultato viene poi
in seguito convertito nel formato di destinazione.
17
Figura 2.4-3: Modello con formato intermedio
Il modello con formato intermedio rappresenta senza dubbio la scelta migliore
in quanto mantiene pressoché ottime la qualità di conversione e le performance
ad un costo di implementazione più che sostenibile. Inoltre ha un basso costo di
estendibilità poiché necessita solamente dell‟integrazione di 2 convertitori
all‟introduzione di un nuovo formato.
Il principale obiettivo che ci si pone nella definizione del Superior Standard è
di trovare un formato che riduca al minimo la perdita di informazioni nella
conversione mantenendo allo stesso tempo una forma il più generale possibile.
Ci sono due tipi di approccio: quello minimalista e quello esaustivo [NP03]. Il
primo punta alla definizione di un formato basilare contenente la quantità di
strutture sintattiche essenziali ad effettuare la conversione. La seconda invece
mira alla costruzione di tutti i costrutti necessari per evitare ogni tipo di perdita
di informazione creando un formato complesso e difficile da gestire.
2.5
Office OpenXML e convertitori
Ora che abbiamo affrontato il problema della conversione dei dati
introduciamo il formato oggetto di questa tesi.
18
Office OpenXML (OOXML) [ECM06] è stato introdotto da Microsoft per la
sua suite Microsoft Office 2007 ed è uno standard ECMA. OOXML è una vera
e propria famiglia di formati (*.docx, *.pptx, *.xlsx) che permettono la
descrizione di una grande varietà di documenti (come relazioni, curriculum
vitae, libri, grafici, fogli di calcolo, presentazioni multimediali, ecc).
2.5.1 Microsoft Office e OpenXML
Microsoft Office fece la sua prima comparsa sugli scaffali nel 1989 sulla
piattaforma Macintosh seguita da una per Windows nel 1990. Il suo successo
fu inizialmente conseguito grazie ad una strategica scelta commerciale: Office
non era nient‟altro che un insieme di programmi già esistenti e venduti
separatamente e sbaragliò la concorrenza solo quando Microsoft cominciò a
distribuire un pacchetto unico, dando ai consumatori la possibilità di acquistare
l‟intero set di applicazioni ad un prezzo nettamente ridotto. La prima versione
del pacchetto Microsoft conteneva Word, Excel e PowerPoint con la possibilità
di avere Access e Schedule Plus acquistando la versione “Pro” della suite.
Da questa unione le applicazioni sono sostanzialmente cresciute in modo
congiunto condividendo tecnologie e caratteristiche come il correttore
grammaticale, l‟integrazione dei dati basata su Object Linking and Embedding
(OLE, utilizzato per trasferire i dati fra diverse applicazioni) ed il linguaggio
Visual Basic per lo scripting. Grazie a questa intercompatibilità fra le sue
applicazioni, la loro semplicità di utilizzo ed il pieno supporto da parte dei
sistemi operativi Windows, hanno permesso a Microsoft Office di raggiungere
una posizione di predominanza fra gli applicativi per la creazione di documenti
elettronici.
Col passare degli anni si ha assunto uno stato di dipendenza da tali software. In
questa condizione gli enti pubblici e privati hanno continuato a scambiare ed
archiviare i loro dati servendosi di formati proprietari Microsoft senza
preoccuparsi delle conseguenze che avrebbe comportato questo tipo di
decisione. Microsoft ha sempre tratto vantaggio da tale situazione ed ha sempre
mantenuto oscure le specifiche tecniche dei suoi formati binari in modo che
non potessero nascere applicativi in grado di interpretarli e di contrastare il suo
monopolio di mercato, vincolando così le future scelte dei suoi clienti.
Con l‟idea di OpenOffice.org [SM07] però qualcosa è cambiato, è nata
un‟alternativa. Il progetto ha risvegliato nella comunità Open Source il
desiderio di porre fine a questa situazione di stallo ed ha prodotto un nuovo
formato totalmente aperto e privo da ogni vincolo di licenza: Open Document.
19
Il formato OASIS Open Document Format for Office Applications (ODF) è
stato soggetto ad anni di continui e laboriosi sviluppi ed ha acquisito col tempo
notevole importanza fino a diventare standard OASIS.
Microsoft si è sentita in questo modo minacciata ed ha cercato di competere
con ODF usando le sue stesse armi. Così per la prima volta la multinazionale
del software viene incontro al mondo Open Source promuovendo un formato
aperto: Office OpenXML, il nuovo formato della suite Microsoft Office 2007.
La sua scelta si è basata essenzialmente sul fatto che un formato proprietario
non sarebbe mai potuto diventare uno standard internazionale.
E‟ nata così una vera e propria guerra dei formati che si è combattuta nella
corsa alla standardizzazione. ODF è divenuto standard ISO/IEC 26300 e
successivamente standard UNI. Microsoft OpenXML è diventato standard
ECMA 376 ed è tuttora in processo di standardizzazione ISO.
Si dice che questa guerra abbia avuto fine con il supporto da parte di Microsoft
e Novell del progetto Open Source OpenXML/ODF Translator [SO07] che ha
rappresentato la volontà delle società multinazionali di rendere interoperabili i
formati, rendendo plausibile una loro coesistenza .
Facciamo ora una breve panoramica dei convertitori per OpenXML
attualmente esistenti.
2.5.2 OpenXML/ODF Translator 1.0
E‟ un importante progetto Open Source nato per la interoperabilità fra le
applicazioni basate sul formato Microsoft OpenXML e lo standard ODF
(Open Document) 1.0. Questo pacchetto non è altro che un add-ins per le
applicazioni di Microsoft Office Word (documenti), Excel (fogli di calcolo)e
PowerPoint (presentazioni multimediali) e permette di aprire e salvare i file nei
rispettivi formati di OpenDocument (*.odt, *.ods e *.odp). Inoltre il
convertitore è dotato di un‟utility per la conversione a linea di comando.
Il convertitore segue un modello a conversione diretta, il motore è
implementato in .NET 2.0 ed è basato su trasformazioni XSLT. I processi di
trasformazione vengono preceduti da una fase di decompressione dei dati
(poiché i file XML che descrivono il documento sono compressi in un archivio
ZIP) e vengono successivamente mappati in un unico file. Dopo l‟applicazione
dei fogli di stile per passare poi al formato di destinazione viene effettuata
l‟operazione contraria, ovvero la suddivisione dei dati in più file XML che
verranno successivamente compressi in un archivio.
20
Figura 2.5-1: Lo schema di conversione di OpenXML/ODF Translator
Il software è compatibile con le versioni 2007/XP/2003 di Microsoft Office.
Inoltre l‟applicazione ha una controparte che può essere integrata nell‟ultima
versione Novell di OpenOffice.org e rende possibile la conversione verso i
formati Microsoft OpenXML. Dopo vari test di conversione effettuati da
diverse redazioni giornalistiche di informatica il plug-in risulta però essere più
inefficiente della versione per Microsoft Office causando vari errori
all‟apertura dei file convertiti nelle rispettive applicazioni e la perdita quasi
totale di stili e formattazione nei documenti.
Hanno contribuito alla realizzazione del progetto Celever Age (Francia e
Polonia), Aztecsoft (India) e DIaLOGIKa (Germania). Hanno collaborato
Microsoft (appoggio finanziario e co-coordinazione Tecnica e Architetturale) e
Novell (supporto in Linux ed integrazione con OpenOffice.org).
2.5.3 Microsoft Office Compatibility Pack
[MIC07a] E‟ un plug-in rilasciato dalla Microsoft per permettere agli utenti di
Microsoft Office 2000/XP/2003 di interagire con il formato OpenXML
aggiungendo i relativi filtri per le estensioni .
2.5.4 OpenXML File Format Converter for Mac 0.1.1 (Beta)
[MIC07b] E‟ un altro pacchetto freeware di Microsoft e permette la
conversione dal formato OpenXML (più in particolare il formato di Word
*.docx) al formato RTF (Rich Text Format). L‟applicativo è stato
appositamente creato per permettere agli utenti Mac che usufruiscono delle
versioni Microsoft Office 2004/v.X for Mac di aprire e convertire il nuovo
formato standard di Microsoft. Essendo una versione beta il software è tuttavia
ancora incompleto.
21
2.5.5 docXConverter 1.3
docXConverter [PAN07] è un software a pagamento rilasciato dalla Panergy e
permette la conversione ad RTF (Rich Text Format) del fomato di Microsoft
Word 2007 (*.docx). L‟applicativo è stato progettato per quegli utenti che
dispongono di documenti del nuovo formato e non sono in grado di leggerli. La
conversione ad RTF è completa e accurata e permette di ottenere quindi
documenti di alta qualità. Il pacchetto è disponibile sia per Windows che per
Mac OS X.
22
3. CONVERSIONE DA OFFICE
OPENXML
In questo capitolo verrà proposto un modello di soluzione al problema della
conversione da OpenXML, più in particolare da WordprocessingML. La mia
soluzione prevede l‟implementazione del processo di segmentazione basandosi
sul modello Pentaformato.
A questo punto è necessario introdurre come prossimo argomento il formato
sorgente oggetto della conversione.
3.1
Office OpenXML
Office OpenXML, di cui abbiamo già discusso nel capitolo precedente, è un
formato per la memorizzazione dei documenti elettronici sviluppato e
introdotto dalla Microsoft con la suite Microsoft Office 2007. Il formato è
standard ECMA 376 ed è tuttora in processo di standardizzazione ISO.
3.1.1 Specifiche tecniche
OpenXML è un formato basato su XML ed adotta un diverso linguaggio di
markup per ogni documento da delineare:
WordprocessingML: per documenti di word processing;
SpreadsheetML: per fogli di calcolo;
PresentationML: per presentazioni multimediali;
DataDiagramingML: per grafici e diagrammi;
FormTemplate: per moduli elettronici;
L‟obiettivo principale di Microsoft nella creazione di questo formato è stato
quello di cercare di massimizzare le performance, poiché l‟adozione di XML
(al posto del vecchio formato binario) ha notevolmente diminuito la velocità di
caricamento dei documenti nelle sue applicazioni. Per questo motivo sono state
prese diverse decisioni sintattiche anche a discapito della leggibilità del codice,
come:
Adottare nomi corti per gli elementi più ricorrenti;
Memorizzare i dati nei fogli di calcolo sottoforma di indici numerici;
23
Prediligere l‟utilizzo di tag per metadati anziché attributi (per permettere
l‟utilizzo di proprietà strutturate degli elementi);
Utilizzare un content-model non misto;
I file XML necessari alla descrizione del documento sono contenuti in un
archivio compresso ZIP conforme al modello Open Packaging Convention
(OPC) ideato da Microsoft. Il package in aggiunta può contenere molti altri tipi
di file binari (come immagini, audio, clip multimediali o altri documenti) che
possono essere allegati come parte del documento stesso. Secondo la
terminologia OPC ogni file contenuto nel pacchetto è definita come una parte.
Ogni parte può essere accompagnata dai relativi metadati.
Figura 3.1-1: Esempio di struttura di un pacchetto Word Office OpenXML
Ora analizziamo quali sono le parti principali di un documento di Word 2007
minimale:
[Content_Types].xml: descrive i file contenuti nel pacchetto, ovvero con
l‟utilizzo di MIME (Multipurpose Internet Mail Extensions) elenca le
estensioni dei file che si trovano al suo interno e ne definisce il tipo;
24
_rels/.rels: contiene le relazioni di [Content_Types].xml, ovvero un insieme
di URI che precisano la posizione delle altre parti principali all‟interno del
pacchetto (in un documento di word minimale è presente la relazione con il
file document.xml);
word/document.xml: contiene il body con il contenuto del documento, è la
parte più importante del pacchetto;
word/_rels/document.xml.rels: contiene le relazioni di document.xml, un
insieme di URI che specificano la posizione delle parti che lo aiutano a
descrivere meglio il contenuto del documento;
Per ulteriori informazioni sul contenuto di un pacchetto Office OpenXML
leggere le specifiche in [ECM06]. Ora che ci siamo fatti un‟idea di come è
fatto un pacchetto facciamo alcuni esempi dei principali costrutti che si
possono trovare in WordprocessingML.
3.1.2 Basi di WordprocessingML
Un documento WordprocessingML è composto da una collezione di storie.
Ogni storia rappresenta una distinta regione di testo all‟interno del documento.
Tutte le storie del documento (a parte alcuni casi molto particolari che non è
importante specificare) utilizzano un proprio set di proprietà stilistiche e
presentazionali . Queste proprietà includono informazione sul tipo di carattere,
definizione degli stili, definizioni di enumerazione ed altre impostazioni
generali.
Gli costrutti di base che possono costituire un semplice documento
WordprocessingML sono i seguenti:
document: la radice del documento il quale definisce la storia principale;
body: il contenitore che include la serie di blocchi che comprende la storia
principale;
p (paragraph): un paragrafo;
r (run): una regione di testo con un comune set di proprietà;
t (text): un ramo di testo;
Vediamo ora il più semplice esempio di documento espresso con questa
sintassi:
<w:document xmlns:w=”…”>
<w:body>
25
<w:p>
<w:r>
<w:t>Hello world!</w:t>
</w:r>
</w:p>
</w:body>
</w:document>
Come abbiamo accennato in precedenza ogni storia può possedere un comune
set di proprietà, che possono essere espresse all‟interno di un elemento
properties (il nome del tag è quello del blocco contesto con l‟aggiunta del
prefisso Pr, per esempio pPr per il blocco p). Nell‟esempio successivo viene
creato un paragrafo e gli viene assegnato lo stile presentazionale “Titolo”:
<w:p>
<w:pPr>
<w:pStyle w:val=”Titolo”/>
</w:pPr>
<w:r>
<w:t xml:space=”preserve”>Sono un </w:t>
</w:r>
<w:r>
<w:rPr>
<w:b/>
</w:rPr>
<w:t>Titolo</w:t>
</w:r>
</w:p>
Un‟osservazione importante è che WordprocessingML per ovviare al fatto che
non adotta content-model misto suddivide il contenuto dei paragrafi in
sottoelementi (run) in modo da poter definire delle sottocategorie di storie con
proprietà diverse. Lo svantaggio di questo approccio è la necessità di ridefinire,
per ogni elemento run che ha anche solo una proprietà diversa (dalla storia
corrente), l‟intero set di proprietà.
Cerchiamo ora di analizzare le principali strutture dati di un documento (liste e
tabelle) e come vengono rappresentate nel linguaggio.
Le definizione delle liste avviene in modo simile a quello degli stili definendo
all‟interno delle proprietà del paragrafo un elemento numPr (che sta appunto
ad indicare numbering properties). Vediamo un esempio di lista:
26
1. Primo Elemento
a. Elemento Annidato
2. Secondo Elemento
Il relativo codice in WordprocessingML:
<w:p>
<w:pPr>
<w:numPr>
<w:numId w:val=”1”/>
<w:ilvl w:val=”0”/>
</w:numPr>
</w:pPr>
<w:r>
<w:t>Primo Elemento</w:t>
</w:r>
</w:p>
<w:p>
<w:pPr>
<w:numPr>
</w:numPr>
</w:pPr>
<w:r>
<w:t>Elemento Annidato</w:t>
</w:r>
</w:p>
<w:p>
<w:pPr>
<w:numPr>
</w:numPr>
</w:pPr>
<w:r>
<w:t>Secondo Elemento</w:t>
</w:r>
</w:p>
Come si può notare dall‟esempio i paragrafi elenco possiedono un
identificatore di enumerazione numId. Il valore di tale identificatore
categorizza gli elementi come appartenenti ad una lista specifica. Inoltre nelle
proprietà di enumerazione è presente un tag ilvl il cui attributo indica il livello
27
di annidamento dell‟elemento lista. Questa organizzazione degli elenchi
permette così di definire altri blocchi indipendenti tra un elemento e l‟altro
delle liste (altri paragrafi, tabelle, ecc) rendendo più versatile la strutturazione
del documento.
Ora facciamo un esempio di tabella:
Cella numero 1
Cella numero 4
Cella numero 2
In WordprocessingML:
<w:tbl>
<w:tblPr>
...
</w:tblPr>
<w:tr>
<w:tc>
<w:p>
<w:r>
<w:t>Cella numero 1</w:t>
</w:r>
</w:p>
</w:tc>
<w:tc>
<w:p>
<w:r>
</w:r>
</w:p>
</w:tc>
<w:tc>
<w:tcPr>
<w:vMerge w:val=”restart”>
</w:tcPr>
<w:p>
<w:r>
</w:r>
</w:p>
<w:tc>
</w:tr>
<w:tr>
<w:tc>
<w:tcPr>
28
Cella numero 3
<w:gridSpan w:val=”2”/>
</w:tcPr>
<w:p>
<w:r>
</w:r>
</w:p>
</w:tc>
<w:tc>
<w:tcPr>
<w:vMerge/>
</w:tcPr>
</w:tc>
</w:tr>
</w:tbl>
Dal codice si può certamente notare un‟evidente somiglianza con il linguaggio
HTML. Il blocco tabella è definito dall‟elemento tbl (simile al tag table). Al
suo interno si possono trovare gli elementi tblPr (per le proprietà
presentazionali della tabella), tr (riga della tabella) ed annidato nell‟ultimo il
tag tc (cella della tabella). La struttura della griglia è equivalente a quella di
HTML anche per la gestione del merge orizzontale delle celle (la cella contesto
possiede una proprietà gridSpan equivalente a quella dell‟attributo colspan).
Diversa invece è la gestione del merge verticale, che implica la presenza nelle
righe sottostanti alla cella contesto di elementi vuoti tc (al posto delle celle
unificate) con proprietà di vMerge.
Ora che abbiano analizzato a grandi linee la struttura del formato e dei suoi
costrutti principali introduciamo il formato IML, una parte della soluzione
proposta da questa tesi per la conversione da Office OpenXML.
3.2
IML
Intermediate Markup Language (IML) è un linguaggio di markup ideato dai
ricercatori della facoltà di Scienze Matematiche, Fisiche e Naturali
dell‟università di Bologna. IML è un linguaggio di markup di tipo descrittivo e
si basa sui concetti di segmentazione dei documenti e normalizzazione delle
strutture.
Secondo il principio di segmentazione ogni documento è scomponibile in
cinque parti che descrivono il documento nelle varie prospettive: contenuto
(testo e immagini), struttura (organizzazione del contenuto), presentazione
29
(formattazione e caratteristiche grafiche), behaviour (comportamento dinamico
del documento) e metadati (informazioni per la gestione e per l‟indicizzazione
del documento). Ognuna di queste dimensioni varia in modo consistente da
documento a documento, ma la struttura assume spesso delle forme limitate e
piuttosto ricorrenti [DGV05].
L‟idea è quindi di associare queste strutture ricorrenti a schemi generalizzati in
grado di esprimere con costrutti specifici predefiniti il medesimo significato: i
design pattern. Per normalizzazione si intende quindi la possibilità di
descrivere, indipendentemente dal formato di memorizzazione, il contenuto
strutturato di qualunque documento con l‟utilizzo di design pattern.
In particolare i design pattern riconosciuti in IML sono:
Marker: è un elemento vuoto la cui importanza risiede nella posizione che
assume all‟interno documento e/o dal valore dei suoi attributi. I marker
possono essere distinti in milestone (la cui informazione signficativa
dipende esclusivamente dalla sua locazione, per esempio il tag br in HTML)
e marker con attributi (l‟informazione risiede anche negli attributi posseduti,
per esempio il tag img di HTML);
Atomo: un elemento che può contenere solo testo e non può essere
ulteriormente strutturato;
Blocco ed Inline: è una struttura a content-model misto utilizzata per
marcare blocchi di testo. Al suo interno può contenere elementi inline
ripetibili in un qualunque ordine che possiedono lo stesso content-model del
blocco;
Contenitore: è un elemento generico utilizzato per l‟organizzazione logica
della struttura del documento. Esso può contenere una sequenza di altri
elementi opzionali e ripetibili, ma non direttamente testo ed inline;
Tabella: è un elemento utilizzato per descrivere strutture tabellari e
sequenze di elementi raggruppati in modo omogeneo (come liste,
contenitori, ecc);
Record: una lista non-ordinata di elementi non ripetibili. Un record è
utilizzato per esprimere informazioni strutturate (spesso estratte da un
database), e sono generalmente insiemi di coppie nome-valore;
IML è un linguaggio sintatticamente molto semplice essendo un sottoinsieme
molto ristretto di XHTML. Il linguaggio mappa i pattern descritti in sintassi
XHTML, utilizzando attributi per esprimere proprietà aggiuntive. Il risultato è
quindi una sequenza di oggetti, ognuno dei quali specifica il pattern utilizzato
per la descrizione del contenuto (se è un blocco, un contenitore, ecc) e la classe
30
di appartenenza dell‟oggetto stesso (ovvero il tipo dell‟oggetto e le sue
proprietà aggiuntive).
In sostanza il linguaggio è basato sull‟utilizzo di pochi tag XHTML come p
(per i blocchi), span (per gli inline), table, ul, li e div (per le varie tabelle ed i
contenitori) e sull‟uso sistematico dell‟attributo @class per la diversificazione
dei ruoli (già parzialmente effettuata con l‟identificazione del pattern in uso).
Tuttavia difficilmente le eterogeneità dei dati che si possono trovare in un
documento (come ad esempio form, equazioni matematiche, ecc) sono sempre
adattabili ad un modello così semplice. Per questo motivo IML è stato ideato
per essere un linguaggio espandibile che può essere facilmente esteso al
supporto di domini specifici, aggiungendo nella sintassi gli elementi e gli
attributi necessari alla descrizione dei nuovi modelli, pur mantenendo invariata
la strutturazione dei design pattern.
La qualità principale di IML è quella di essere un linguaggio minimale e
generale, e di conseguenza estremamente semplice da gestire, caratteristica che
lo rende un potente formato intermedio per la conversione automatica di
formati documentali.
3.3
Si-ConForMi OpenXML
Il prototipo Simple Converter For Microsoft OpenXML (Si-ConForMi
OpenXML) è un convertitore bidirezionale che si basa sul modello di
conversione con formato intermedio. Esso si basa sul principio di
segmentazione dei documenti (in particolare il modello Pentaformato), ed è
stato creato per la conversione di contenuto e struttura di un documento di
word processing Office OpenXML verso altri formati documentali o viceversa.
Il formato intermedio utilizzato per il modello di conversione è IML, la cui
funzione è appunto quella di mappare il contenuto strutturato dei documenti
digitali.
Questa applicazione è stata progettata per essere espandibile (o parte di
un‟applicazione che utilizza lo stesso tipo di architettura) e per permettere la
realizzazione di un convertitore di formati documentali di tipo universale.
31
Figura 3.3-1: Il modello di conversione di Si-ConForMi OXML
I vantaggi di questo tipo di approccio si possono riassumere in:
scomposizione dei problemi di conversione: seguendo il principio di
segmentazione dei documenti è possibile scomporre il problema della
conversione nei sottoproblemi di conversione delle componenti . Se si deve
sviluppare un convertitore che effettui una trasformazione completa è
possibile utilizzare IML per il contenuto e la struttura, ed altri linguaggi
intermedi per trasporre le componenti rimanenti del documento;
espandibilità: non essendo un convertitore diretto ma con modello
intermedio un nuovo formato può essere integrato facilmente
nell‟architettura (è necessario lo sviluppo di due soli convertitori);
buona qualità e prestazioni: il modello di conversione intermedio mantiene
pressoché ottime qualità di conversione e efficienza (sono necessari solo
due passi di conversione per raggiungere il formato di destinazione
desiderato);
bassi costi di sviluppo: inizialmente il modello richiede l‟implementazione
di solo
meccanismi di conversione contro gli
del modello a
conversione diretta;
versatilità di impiego: il convertitore può essere adattato facilmente ad altri
impieghi differenti da quello della conversione tra formati documentali. Per
32
esempio il convertitore può essere utilizzato anche per estrarre da un
documento informazioni (content extractor) sul contenuto strutturato per poi
memorizzarle come campi separati in una base di dati, o darle in pasto ad un
classificatore che in base ai tag ottenuti categorizzano i contenuti. Un altro
ruolo applicativo potrebbe essere quello del formatter in cui il convertitore
permette di estrarre il contenuto di un documento per ripresentarlo con un
differente layout.
3.3.1 Uso di Si-ConForMi OXML
Si-ConForMi OXML è un‟applicazione Java che può essere invocata a linea di
comando.
Figura 3.3-2: Esempio di invocazione di Si-ConForMi OXML
Il pacchetto permette di convertire un documento di Word OpenXML nel
formato IML (o viceversa) e di salvare il risultato della trasformazione in un
file nella cartella corrente di lavoro dell‟utente. Il convertitore riceve in input
due argomenti:
[-oi|-io] (direzione di conversione): per specificare il tipo di conversione
che l‟applicazione deve effettuare (-oi per la conversione da OpenXML a
IML, -io per la conversione inversa da IML a OpenXML);
[filepath]: il percorso relativo o assoluto del file da convertire;
Il prerequisito per il corretto funzionamento dell‟applicativo è Runtime Java
Sun JRE 1.5.0 o successivi.
33
3.3.2 Obiettivi raggiunti
L‟applicativo supporta la conversione delle parti più importanti per la
comprensione di un documento di Word 2007. Esso riconosce e gestisce
correttamente nella conversione i seguenti elementi:
testo e paragrafi
grassetto, corsivo, apice e pedice
nomi degli stili di utilizzo
link ipertestuali
segnalibri
immagini (e oggetti immagine bitmap)
tabelle
liste con annidamenti
contenuto delle caselle di testo
note a piè pagina
sezioni del documento
sottodocumenti
oggetti documento Word 2007
lingua dei frammenti
Inoltre nella conversione di un file IML a OpenXML vengono assegnati ai
blocchi stili presentazionali predefiniti, in base al loro ruolo assunto nel
documento.
34
3.3.3 Esempi di conversione
Facciamo ora qualche esempio di trasformazione con Si-ConForMi OXML.
Convertiremo il seguente documento di WordprocessingML in IML:
Figura 3.3-3: Esempio di conversione (documento generico)
Il risultato della conversione è il seguente codice IML:
<?xml version="1.0" encoding="UTF-8"?>
<iml xmlns="http://www.cs.unibo.it/2006/iml">
<head/>
<body lang="it">
<div class="Section">
<h1 class="Title" lang="it">Questo è il titolo</h1>
<p lang="it" class="Subtitle">Questo è un
sottotitolo.</p>
<p lang="it" class="Normal">Prova con gli inline: <b
lang="it">grassetto</b>, <i lang="it">corsivo</i>, <b
lang="it"><i lang="it">grassetto con corsivo</i></b>, <sup
lang="it">apice</sup>, <sub lang="it">pedice</sub>.</p>
35
<p lang="it" class="Normal">Prova link: <a lang="it"
href="http://informatica.unibo.it"
class="Hyperlink">http://informatica.unibo.it</a> .</p>
<p lang="it" class="Normal">Prova immagine:</p>
<p lang="it" class="Normal"><img src="media/0_image1.gif"
class="Internal"/></p>
<p lang="it" class="Normal">Prova tabella:</p>
<table class="Table Grid">
<tr>
<td>
<p lang="it" class="Normal">Prima cella</p>
</td>
<td>
<p lang="it" class="Normal">Seconda cella</p>
</td>
<td rowspan="2">
<p lang="it" class="Normal">Terza cella</p>
</td>
</tr>
<tr>
<td colspan="2">
<p lang="it" class="Normal">Quarta cella</p>
</td>
</tr>
</table>
<p lang="it" class="Normal">Prova lista:</p>
<ul level="0" type="number" value="1">
<li>
<p lang="it" class="List Paragraph">Primo
elemento</p>
</li>
<li>
<p lang="it" class="List Paragraph">Secondo
elemento</p>
</li>
<li>
<li>
<p lang="it" class="List Paragraph">Elemento
annidato</p>
</li>
</ul>
</li>
<li>
<p lang="it" class="List Paragraph">Terzo
elemento</p>
36
</li>
</ul>
</div>
</body>
</iml>
Un altro esempio più particolare esplicita come Si-ConForMi OXML mappa le
liste contenenti altri blocchi estranei fra un elemento e l‟altro:
Figura 3.3-4: Esempio di conversione (caso particolare di lista)
Nel codice IML risultante si può osservare come il paragrafo fra gli elementi
della lista è considerato nella struttura parte della lista stessa:
<head/>
<body lang="it">
<p lang="it" class="Normal">Inizio della lista:</p>
<li>
<p lang="it" class="List Paragraph">Primo
elemento</p>
</li>
<li>
<p lang="it" class="List Paragraph">Secondo
elemento</p>
<p lang="it" class="Normal">Paragrafo in mezzo alla
lista.</p>
</li>
<li>
<p lang="it" class="List Paragraph">Terzo
elemento</p>
</li>
</ul>
</div>
37
</body>
</iml>
Un ultimo esempio mostra come avviene la conversione dei sottodocumenti:
Figura 3.3-5: Esempio di conversione (documento con sottodocumenti)
In IML vengono creati dei contenitori generici contenenti i sottodocumenti:
<head/>
<body lang="it">
<h1 class="heading 1" lang="it">Master Document</h1>
<p lang="it" class="Normal">Questo è il contenuto del
documento principale.</p>
</div>
<div class="Subdocument" lang="it">
<h1 class="heading 1" lang="it">Subdocument1</h1>
sottodocumento1.</p>
</div>
</div>
</div>
<div class="Subdocument" lang="it">
<h1 class="heading 1" lang="it">Subdocument2</h1>
38
sottodocumento2.</p>
</div>
</div>
</div>
</body>
</iml>
39
4. IMPLEMENTAZIONE DI “SICONFORMI OXML”
Il prototipo Si-ConForMi OXML è un‟applicazione sviluppata in linguaggio
Java ed è basata su trasformazioni XSLT. Queste scelte progettuali sono state
effettuate per i seguenti motivi:
Indipendenza dalla piattaforma: Java non è in alcun modo legato alla
piattaforma poiché è un linguaggio interpretato dalla Java Virtual Machine
presente nel sistema su cui è installato. Ciò rende l‟applicazione
indipendente dall‟architettura locale in cui viene eseguita;
Modularità del progetto: essendo Java un linguaggio ad oggetti è stato
possibile implementare varie classi per la risoluzione dei sottoproblemi di
implementazione. In caso di necessità sarà così possibile estendere,
modificare o sostituire singoli moduli senza il bisogno di effettuare un
refactoring completo. Inoltre i fogli di stile sono esterni al pacchetto, è
quindi possibile modificarli mantenendo inalterato il codice Java;
Maggiore semplicità di conversione: OpenXML è basato su XML, e questo
rende XSLT il linguaggio più naturale (e più semplice) per effettuare
trasformazioni complesse con il formato. Inoltre sono presenti delle librerie
scritte in Java che implementano DOM e SAX (vedi paragrafo seguente) e
altre API (JDOM, TrAX, JAXP), che permettono di interagire con file di tipo
XML e di effettuare su di essi trasformazioni con XSLT.
4.1
API in Java per XML
Come accennato esistono diverse API in Java per processare i file XML. E‟
necessario quindi, prima di addentrarci nella spiegazione del progetto,
presentare quelle che sono state utilizzate nella sua realizzazione:
Simple API for XML (SAX): è un parser utilizzato per la lettura di un file
XML. E‟ un modello basato su un insieme di funzioni che vengono invocate
al verificarsi di eventi specifici (event-handler model), ovvero al parsing dei
vari elementi costitutivi di un XML (elementi, testo, ecc). In pratica
implementando la classe interfaccia ContentHandler di SAX è possibile
personalizzare queste funzioni ed estrarre così le informazioni desiderate. I
vantaggi di SAX sono l‟utilizzo estremamente ridotto di memoria ed una
40
considerevole velocità di parsing. Purtroppo il parser può solo essere
utilizzato per la lettura e non permette la navigazione diretta del documento;
Document Object Model (DOM): è un‟interfaccia di programmazione per
file XML. DOM definisce la struttura logica di un documento XML in
modo da consentirne la navigazione, permettendo all‟utente la creazione, la
lettura e la modifica degli elementi. Il principale svantaggio di questa API è
che necessita della presenza in memoria dell‟intero documento di utilizzo,
causando delle grosse perdite di efficienza con file di grandi dimensioni.
Perciò è preferibile limitare il suo impiego alla scrittura dei file XML;
Trasformations API for XML (TrAX): è un‟interfaccia di programmazione
specifica per effettuare trasformazioni con XSLT;
4.2
Il motore di conversione (Java)
L‟obiettivo del motore di conversione, non è solo quello di applicare i fogli di
stile XSLT, ma è di risolvere tutta una serie di problematiche.
Per prima cosa il formato OpenXML è un archivio ZIP. Questo implica la
necessità di un sistema di compressione e decompressione dei dati, prima di
effettuare la conversione.
Sorgono poi alcune complicazioni dovute al fatto che ci sono diversi file
all‟interno del pacchetto OOXML, ed ognuno di essi ha un compito ben
preciso nella descrizione del documento. Al momento della trasformazione con
XSLT dovremo disporre di un unico file XML contenente tutte le informazioni
necessarie. Occorre quindi che il motore di conversione preveda il mapping
delle varie parti del pacchetto (ossia dei vari file inclusi) in un solo file, e
l‟operazione inversa (cioè la suddivisione delle informazioni nelle varie
componenti del pacchetto, per la conversione inversa da IML a OOXML).
Un altro problema è che al momento della decompressione dei dati non siamo a
conoscenza della tipologia di file dei quali disponiamo. Alcuni di essi
sappiamo che sono XML (per la loro posizione predefinita all‟interno del
pacchetto come spiegato nel capitolo precedente), ma altri possono essere file
binari, utili o inutili al nostro scopo, oppure ancora altri pacchetti OOXML che
vanno individuati e processati in maniera ricorsiva. E‟ necessario quindi un
processo attraverso cui il motore identifichi il tipo di file e la categoria di
appartenenza, in modo da poterli successivamente gestire.
41
Nelle prossime sezioni entreremo nel dettaglio degli oggetti costituenti il
motore di conversione. Esso è composto da 8 classi Java, ognuna delle quali
ha un ruolo ben preciso nel processo di trasformazione.
4.2.1 DocumentConverter.java
E‟ la classe principale poiché è quella che possiede il metodo main() ed i due
metodi per l‟avvio dei differenti processi di conversione. I metodi della classe
sono i seguenti:
main(): è il metodo principale per l‟invocazione a riga di comando. A
seconda degli argomenti passati all‟applicazione avrà lo scopo di richiamare
una funzione fra convertOXMLToIML () e convertIMLToOXML() per la
conversione del file specificato dall‟utente;
convertOXMLToIML(): è il metodo principale che innesca la procedura per
la conversione di un file OOXML a IML;
convertOXMLToIMLRecurrence(): è una funzione ricorsiva necessaria per
far fronte alla possibile presenza di sottodocumenti. Ha lo scopo di
estendere il processo di conversione a tutti i pacchetti di tipo OOXML legati
al documento in trasformazione;
filesSelector(): è una funzione molto importante per la conversione a IML.
Essa ha lo scopo di accedere con SAX ai file delle relazioni del pacchetto
OOXML ed individuare i file di interesse (file XML per la descrizione del
documento, immagini, sottodocumenti ed oggetti documento allegati). Il
metodo utilizza un‟istanza della classe RelParser come ContentHandler del
parser SAX;
copyImages(): è una funzione che crea una cartella “media” nella directory
corrente di lavorazione dell‟utente (dove si trova al termine della
conversione il file IML) e copia al suo interno le immagini allegate nel
documento di partenza, rendendole così accessibili all‟IML. Inoltre il nome
delle immagini viene modificato con un prefisso numerico (per evitare
conflitti di nome con le immagini dei sottodocumenti);
convertIMLToOXML(): è il metodo principale che innesca la procedura per
la conversione di un file IML a OOXML;
copyImagesTwo(): è la controparte del metodo copyImages(). La sua
funzione è quella di copiare le immagini nella cartella “word/media” del
pacchetto OOXML in costruzione;
42
delFiles(): è un metodo generico per la cancellazione di file presenti sul
disco rigido. E‟ necessario principalmente alla cancellazione dei file
temporanei al termine dei processi di conversione (ma anche nel caso si sia
verificato un errore di trasformazione);
4.2.2 ZipCompressor.java
E‟ la classe che si occupa delle operazioni di compressione e decompressione
dei file nel formato ZIP. Dispone dei seguenti metodi:
zip(): è una funzione utilizzata per la compressione di un elenco di file
in un archivio;
unzip(): è una funzione utilizzata per la decompressione di un archivio
nella cartella specificata;
4.2.3 DocumentMapper.java
La classe ha il compito di interagire con i file di mapping, ovvero dei file
specifici che descrivono le parti ed il contenuto di un pacchetto OOXML con il
linguaggio di markup MappingML (vedere paragrafo 4.3). La classe possiede i
seguenti metodi:
map(): è il metodo principale per la creazione di un file di mapping da un
elenco di file XML. Il file è creato con l‟ausilio di DOM;
fillDocmap(): è una funzione utile nel processo di creazione di un file di
mapping ed ha lo scopo di inserire gli elementi di MappingML necessari
alla descrizione del pacchetto;
existChild(): è un metodo di supporto per verificare l‟esistenza di un
elemento MappingML all‟interno del file di mapping in creazione;
writeDocmap(): è una funzione che serve per scrivere un file di mapping sul
file system una volta completata la sua creazione con DOM;
fillTagFile(): è utilizzato per copiare il contenuto di un file XML all‟interno
di un file di mapping nella posizione corretta. Una volta invocato il metodo
viene istanziata la classe XmlParser, viene utilizzata come ContentHandler
SAX ed al parsing dell‟XML verrà effettuata la copia;
unmap(): la funzione ha il compito di creare la struttura di file e cartelle
descritta in un file di mapping passato come parametro. In realtà la funzione
istanzierà la classe MapParser utilizzandola come ContentHandler SAX,
saranno poi i suoi metodi a svolgere il compito al parsing del file;
43
4.2.4 XmlParser.java
E‟ un implementazione della classe ContentHandler di SAX. I metodi della
classe hanno lo scopo di leggere e copiare al parsing l‟intero contenuto di un
file XML passato come parametro. Viene utilizzato DOM per la creazione e la
scrittura degli elementi.
4.2.5 MapParser.java
E‟ un implementazione della classe ContentHandler di SAX. Essa ha lo scopo
di riconoscere i vari elementi di MappingML presenti in un file di mapping e di
ricreare sul file system la stessa situazione descritta, copiando anche il
contenuto dei tag nei vari file XML creati. Il suo ruolo è in pratica quello di
ricreare i vari file di un pacchetto OOXML partendo da un solo file di
mapping.
4.2.6 RelParser.java
E‟ un implementazione della classe ContentHandler di SAX. Il suo scopo è
quello di accedere ai file delle relazioni di un pacchetto OOXML e restituire,
con l‟ausilio di vettori, un elenco dei file di interesse relazionati col documento
in analisi. Grazie al parsing SAX con RelParser possiamo individuare i file
XML da mappare, le immagini ed i sottodocumenti in modo da poterli
successivamente gestire.
4.2.7 XSLTransformer.java
La classe ha il compito di effettuare le trasformazioni XSLT con l‟ausilio
dell‟API TrAX. Essa possiede un solo metodo trasform() che applica un foglio
di stile ad un file XML, entrambi passati come parametri.
4.2.8 ImlParser.java
E‟ un‟altra implementazione della classe interfaccia ContentHandler di SAX.
La classe ha il compito di effettuare il parsing di un file IML e di individuare le
immagini presenti nel documento, in particolare quelle che sono classificate
come interne al documento (@class = „Internal‟), in modo da poterle
successivamente copiare all‟interno del pacchetto OOXML risultante.
44
4.3
MappingML
Mapping Markup Language (MappingML) è un linguaggio di markup molto
semplice e minimale ideato per questo progetto. Esso ha lo scopo di riflettere la
struttura fisica di un archivio (o pacchetto) generico contenente molteplici file
XML, e mappare così il loro contenuto.
Il linguaggio si basa sull‟utilizzo di tre elementi fondamentali:
PACKAGE: è la radice del documento e rappresenta l‟istanza di un
pacchetto. Esso è caratterizzato da due attributi obbligatori che sono @id
(identificatore univoco del pacchetto) e @name (il nome del pacchetto).
L‟elemento può contenere una sequenza di elementi facoltativi PACKAGE,
FOLDER e FILE ripetibili in un qualunque ordine;
FOLDER: l‟elemento rappresenta una directory di un package ed è
caratterizzato dall‟attributo @name (il nome della directory). FOLDER ha
lo stesso content-model di PACKAGE;
FILE: è l‟elemento foglia del linguaggio. E‟ caratterizzato dall‟attributo
@name (il nome del file) ed ha lo scopo di includere il contenuto del file
XML ad esso relativo. Ovviamente FILE non può contenere al suo interno
altri elementi di MappingML;
Un ulteriore vincolo sintattico è che gli elementi non possono avere dei fratelli
con l‟attributo @name con lo stesso valore, poiché non è possibile avere su un
file system un percorso corrispondente a più file o cartelle.
L‟impiego di MappingML in questo progetto è stato fondamentale per mappare
i file XML contenuti in un archivio OOXML in un solo file di mapping, in
modo così da poter effettuare trasformazioni XSLT. Vediamo un piccolo
esempio:
<map:package id=”0” name=”Documento.docx” xmlns:map=”…”>
<map:file name=”[Content_types].xml”>

</map:file>
<map:folder name=”_rels”>
<map:file name=”.rels”>

</map:file>
45
</map:folder>
<map:folder name=”word”>
<map:file name=”document.xml”>

</map:file>
<map:folder name=”_rels”>
<map:file name=”document.xml.rels”>

</map:file>
</map:folder>
</map:folder>
</map:package>
4.4
XSLT
I fogli di stile per le trasformazioni XSLT sono suddivisi in due categorie
principali corrispondenti alle direzioni di conversione di Si-ConForMi OXML.
4.4.1 Trasformazione OOXML(MappingML) – IML
I seguenti fogli di stile effettuano la trasformazione di un pacchetto Office
OpenXML (descritto con MappingML) ad IML. Ognuno dei file ha un certo
ruolo nella trasformazione e si occupa di un certo tipo di pattern o struttura:
OX-iMLconv.xsl: è il file principale che viene applicato alle trasformazioni
ed è quello che include tutti gli altri fogli di stile. Ha il compito di definire la
radice ed i contenitori principali del file IML;
Document.xsl: il suo ruolo è quella di suddividere il documento in vari
contenitori corrispondenti alle interruzioni di sezione;
Paragraph.xsl: contiene i template relativi a tutti gli elementi che sono
definiti mediante un tag paragrafo WordprocessingML. Ovvero vengono
gestiti i paragrafi e tutti i suoi sottoelementi relativi, le immagini ed i
sottodocumenti;
List.xsl: contiene i template relativi alla trasformazione delle liste;
Table.xsl: contiene i template relativi alla trasformazione delle tabelle;
Footnote.xsl: ha il ruolo di gestire le note a piè di pagina.
46
4.4.2 Trasformazione IML-OOXML(MappingML)
I fogli di stile elencati successivamente si occupano dell‟altro verso di
conversione, ovvero della trasformazione di un file IML in un pacchetto
OOXML (descritto con MappingML):
iML-OXconv.xsl: è il file principale che viene applicato alle trasformazioni
ed è quello che include tutti gli altri fogli di stile. Esso ha il ruolo di definire
la radice e gli elementi MappingML necessari per la descrizione del
pacchetto. Viene anche creato dinamicamente il contenuto dei file delle
relazioni, delle proprietà di enumerazione (numbering.xml) e delle note a
piè pagina (footnotes.xml). Invece il contenuto di altri file (come
[Content_types].xml e styles.xml) viene semplicemente copiato da altri file
di supporto ai fogli di stile;
Document.xsl: si occupa della creazione dei contenitori principali di
document.xml e possiede un template per la creazione di interruzioni di
sezione;
Paragraph.xsl: ha il ruolo di effettuare la conversione dei blocchi di testo e
degli elementi inline;
List.xsl: contiene i template relativi alla trasformazione delle liste;
Table.xsl: contiene i template relativi alla trasformazione delle tabelle;
DefaultFiles.xml: questo è un file di supporto a iML-OXconv.xsl, ed allega
un contenuto predefinito per i file [Content_types].xml e styles.xml;
NumberingSupport.xml: è un altro file di supporto al foglio di stile
principale e contiene informazioni utili per la creazione del file
numbering.xml.
4.5
Conversione OOXML – IML
I passi effettuati in una conversione da OOXML ad IML sono i seguenti:
1. Decompressione del pacchetto: un file OpenXML è un archivio compresso
ZIP e per avere accesso ai file del pacchetto è quindi necessaria una fase
iniziale di decompressione;
2. Selezione dei files: accedendo con SAX ai file delle relazioni è possibile fare
una selezione dei file necessari per il loro prossimo utilizzo. Per ogni
oggetto documento o sottodocumento esterno individuato si dovrà ripetere
il procedimento svolto fino ad ora (in modo ricorsivo ripartendo dalla
decompressione al punto 1). Tutto per disporre al termine del processo di
47
tutti i file decompressi dell‟albero di documenti, degli elenchi completi dei
file XML necessari per il mapping e delle immagini da rendere accessibili
all‟IML;
Figura 4.5-1: Conversione OOXML - IML
3. Creazione file di mapping: come spiegato nel punto precedente occorre
mappare i file XML che descrivono il documento in un solo file, per poterlo
così trasformare con XSLT. Il contenuto dei file viene letto con SAX e
scritto con DOM all‟interno del file di mapping;
48
4. Trasformazione in IML: una volta che si dispone di un unico file XML
contenente tutte le informazioni necessarie, esso viene utilizzato per la
trasformazione con XSLT (utilizzando l‟API di JAVA TrAX). Il risultato è
un file IML;
5. Copia files immagine: ultimo passo per completare la conversione è la copia
delle immagini del documento (individuate al punto 2) in una cartella
predefinita accessibile dal file IML;
4.6
Conversione IML - OOXML
La conversione da IML a OOXML avviene nella maniera inversa, solo che il
procedimento è relativamente più semplice poiché non si presenta il problema
della gestione di sottodocumenti. Le fasi di conversione sono le seguenti:
1. Selezione delle immagini: la prima fase di elaborazione necessaria è
l‟identificazione delle immagini che si devono includere nel pacchetto
finale. Viene quindi effettuato un parsing del file IML (con SAX) in cerca
delle immagine presenti classificate come interne al documento;
2. Creazione file di mapping: il file IML viene trasformato con XSLT e viene
convertito in un file MappingML, contenente una descrizione dettagliata di
come dovrà essere composto il pacchetto finale a livello fisico;
3. Creazione files del pacchetto: il file di mapping viene letto con SAX ed in
base agli elementi presenti vengono creati i file necessari alla creazione del
pacchetto OOXML. Nello stesso tempo con l‟ausilio di DOM vengono
riempiti i file con il loro contenuto relativo;
4. Copia files immagine: in questa fase vengono copiate le immagini che
dovranno essere incluse nel documento nella posizione corretta sul file
system dove risiedono gli altri file del pacchetto;
5. Compressione dei files: ultima fase della conversione è la compressione dei
files in un archivio ZIP;
49
Figura 4.6-1: Conversione IML - OOXML
4.7
Limiti dell’implementazione
Allo stato attuale i limiti dell‟implementazione di Si-ConForMi OXML
consistono nell‟impossibilità di specificare a linea di comando l‟utilizzo di
fogli di stile diversi da quelli predefiniti per le trasformazioni XSLT (occorre
quindi andare a modificare il codice Java) e la mancanza di parametri per
definire i percorsi del risultato delle conversioni e della cartella per i file
temporanei (in entrambi i casi viene utilizzata cartella corrente di lavorazione
dell‟utente).
50
5. CONCLUSIONI
Nel corso di questa tesi abbiamo affrontato il tema della conversione dei
documenti. Per prima cosa abbiamo cercato di studiare a fondo le origini del
problema, partendo dalle necessità che si sono venute a creare con Internet e la
digitalizzazione dei documenti fino all‟introduzione dei sistemi di conversione
tra formati documentali.
In seguito abbiamo poi analizzato i vari tipi di linguaggi di markup per cercare
di comprendere come un documento può essere rappresentato in forma
elettronica e, in particolare con il principio di segmentazione, può essere
scomposto nelle varie dimensioni che lo descrivono. In entrambi i casi abbiamo
potuto notare come i principali modelli descritti in letteratura hanno puntato
alla separazione dei dati per cercare di astrarre e frammentare il problema
della rappresentazione di un documento.
Successivamente abbiamo esaminato i vari schemi di conversione e abbiamo
potuto osservare che il modello che utilizza il formato intermedio scompone il
processo di trasformazione in due fasi al fine di rendere più agevole il
passaggio da un formato all‟altro, semplificando l‟architettura e risparmiando
in termini di costo di sviluppo.
Come ci hanno dimostrato in passato la politica, la matematica e anche
l‟informatica, anche in questo ambito si è potuto constatare che con un
approccio “divide et impera” (dal latino “dividi e domina”), scomponendo
ricorsivamente un problema nei relativi sottoproblemi, si ottiene una soluzione
vincente con innumerevoli vantaggi applicativi, come una miglior gestione
delle sottoparti ed una maggiore funzionalità complessiva.
Sfruttando questo criterio nella realizzazione del progetto e cercando di mettere
insieme questi principi (segmentazione dei documenti con il modello
Pentaformato e conversione con formato intermedio) ho sviluppato un
convertitore per OpenXML che opera in modo specifico su un sottoproblema
di conversione (relativo alla mappatura del contenuto strutturato di un
documento) rendendo possibile una migliore gestione della conversione stessa
da questo formato.
Questo non significa necessariamente che con questo approccio risolutivo si
possa ottenere sempre un convertitore qualitativamente superiore di quelli
esistenti creati ad hoc, ma permette sicuramente di raggiungere un risultato
maggiormente aperto e non vincolato dalle scelte progettuali. Si-ConForMi
51
OXML è tutt‟altro che limitato: è estendibile (sia in termini di qualità di
trasformazione che nel supporto di nuovi formati documentali) ed
estremamente versatile (può essere adattato a diversi impieghi, come
formattatore ed estrattore dati per database).
Questo approccio risolutivo è stato utilizzato per realizzare un convertitore per
Office OpenXML ma può essere anche adottato nella progettazione di
convertitori per domini specifici.
Gli sviluppi futuri di questo convertitore hanno come obiettivi principali:
il perfezionamento delle conversioni, cercando di includere gli elementi di
un documento WordprocessingML non ancora mappati in IML (come ad
esempio gli header, i footer ed i commenti);
il supporto alla conversione delle componenti del documento mancanti
(presentazione, behaviour e metadati), prime fra tutte le caratteristiche di
presentazione e formattazione. Per tale componente si potrebbe ad esempio
sviluppare un meccanismo di conversione parallelo adottando un ulteriore
formato intermedio per la mappatura. Un formato che potrebbe essere
impiegato è Cascading Style Sheets (CSS) [W3C99a], una raccomandazione
del W3C per la stesura delle regole di formattazione delle pagine HTML;
l’estensione del convertitore a nuovi formati, primo fra tutti lo standard
OpenDocument, che assieme ad Office OpenXML rappresentano i formati
più utilizzati per la descrizione di documenti di word processing.
52
Elenco delle figure
Figura 2.3-1: Il modello Pentaformato ........................................................... 13
Figura 2.4-1: Modello diretto......................................................................... 16
Figura 2.4-2: Modello ad anello ..................................................................... 17
Figura 2.4-3: Modello con formato intermedio .............................................. 18
Figura 2.5-1: Lo schema di conversione di OpenXML/ODF Translator ......... 21
Figura 3.1-1: Esempio di struttura di un pacchetto Word Office OpenXML ... 24
Figura 3.3-1: Il modello di conversione di Si-ConForMi OXML ................... 32
Figura 3.3-2: Esempio di invocazione di Si-ConForMi OXML ...................... 33
Figura 3.3-3: Esempio di conversione (documento generico) ......................... 35
Figura 3.3-4: Esempio di conversione (caso particolare di lista)..................... 37
Figura 3.3-5: Esempio di conversione (documento con sottodocumenti) ........ 38
Figura 4.5-1: Conversione OOXML - IML .................................................... 48
Figura 4.6-1: Conversione IML - OOXML .................................................... 50
53
Bibliografia
[AJ97]
A. Aiken, M. Jacoby, "Data Format Conversion Using Pointer
Tree Automata", Technical Report, UC Berkeley, 1997
[DDMR90]
S. J. DeRose, D. Durand, E. Mylonas and A. H. Renear, "What
is Text, Really?”, Journal of Computing in Higher Education,
1990
[DDMR96]
S. J. DeRose, D. Durand, E. Mylonas and A. H. Renear,
“Refining our Notion of What Text Really is: The Problem of
Overlapping Hierarchies”, Research in Humanities Computing,
1996
[CRD87]
J. H. Coombs, A. H. Renear, and S. J. DeRose, ”Markup systems
and the future of scholarly text processing. Commun.”,
November 1987
[DBW02]
L. M. Diaz, E. Wϋstner, P. Buxmann, “Inter-organizational
Document Exchange - Facing the convertion problem with
XML”, Proceedings of the ACM Symposium on Apllied
Computing (SAC 2002), Madrid, 2002
[DFFV06]
A. Di Iorio, A. A. Feliziani, L. Furini, F. Vitali, A cross-format
architecture for professional publishing, 2006
[DGV05]
A. Di Iorio, D. Gubellini, F. Vitali, “Desing Patterns for
descriptive substructures”, Proceedings of Extreme Markup
Languages, Montreal (Canada), Agosto 1-5, 2005
[DI07]
A. Di Iorio, “Pattern-based Segmentation of Digital Documents:
Model and Implementation”, Technical Report, 2007
[ECM06]
ECMA International, “Standard ECMA-376: Office OpenXML
File Formats”, 2006, http://www.ecmainternational.org/publications/standards/Ecma-376.htm
54
[GM02]
R. J. Glushko, T. McGrath, "Document Engineering for eBusiness", DocEng '02: Proceedings of the 2002 ACM
Symposium on Document Engineering - ACM Press, McLean
(Virginia, USA), 2002
[HA02]
E. R. Harold, Processing XML with Java – A Guide to SAX,
DOM, JDOM, JAXP and TrAX, Addison-Wesley, 2002,
http://www.ibiblio.org/xml/books/xmljava/
[MAR06]
D. Marcantoni, “Dalla struttura piatta alla struttura gerarchica:
modelli di conversione in un CMS”, Phd thesis, 2006
[MBO93]
S. A. Mamrak, J. Barnes, C. O‟Connels, “Benefits of Automatic
Data Translation”, IEEE Software, July 1993
[MIC07a]
Microsoft Corporation, Microsoft Office Compatibility Pack for
Word, Excel, and PowerPoint 2007 file formats, 2007,
http://office.microsoft.com/enus/products/HA101686761033.aspx
[MIC07b]
Microsoft Corporation, Microsoft Office OpenXML File
Format
Converter
for
Mac
0.1.1
(Beta),
2007,
http://www.microsoft.com/mac/downloads.aspx?pid=download
&location=/mac/download/Office2004/ConverterBeta.xml&seci
d=4&ssid=34&flgnosysreq=True
[NAN03]
P. Nanni, “Editing collaborativo: motore di conversione”, PhD
thesis, 2003
[OAS07]
OASIS, “OASIS Open Document Format for
Applications (OpenDocument)”, 2007,
http://www.oasisopen.org/committees/tc_home.php?wg_abbrev=office
[PAN07]
Panergy, docXConverter 1.3, 2007, http://www.panergysoftware.com/products/docxconverter/features.html
[SM07]
Sun Microsystems, OpenOffice.org, 2007,
http://www.openoffice.org
[SO07]
SourceForge, OpenXML/ODF Translator Add-ins for Office,
55
Office
2007, http://odf-converter.sourceforge.net
[W3C95]
W3C, Overview of SGML Resources, November 1995,
http://www.w3.org/MarkUp/SGML/
[W3C99a]
W3C, Cascading Style Sheets, level 1, January 1999,
http://www.w3.org/TR/REC-CSS1
[W3C99b]
W3C, XSL Transformations (XSLT) Version 1.0, November
1999, http://www.w3.org/TR/xslt
[W3C06]
W3C, Extensible Markup Language (XML) 1.0 (Fourth Edition),
16 August 2006, http://www.w3.org/TR/REC-xml/
[W3C07]
W3C, XHTML2 Working
http://www.w3.org/MarkUp/
56
Group
Home
Page,
2007,
Ringraziamenti
Sin da quando sono al mondo ho attraversato con la mia famiglia periodi molto
belli, ma anche brutti a volte, momenti in cui litigavamo e facevamo fatica a
sopportarci a vicenda. Una costante però è sempre stata quella di restare uniti,
di volerci bene l‟un l‟altro, cercando in ogni modo di superare quei piccoli e
grandi problemi che la quotidianità ci ha presentato. Con la mia famiglia
accanto ho potuto affrontare i più grandi ostacoli della mia vita, e sono arrivato
a concludere che quando in casa c‟è l‟amore nessuna difficoltà è insuperabile.
Per questo gli dedico questa tesi, sperando quando un domani dovrò “passare il
testimone“, di poter dare ai miei figli almeno la metà di quello che ho ricevuto.
Voglio ringraziare babbo per i sacrifici che ha fatto per me, per avermi dato
fiducia anche quando forse meno me la meritavo, e perché grazie alle sue
strigliate ho appreso quando era l‟ora di cominciare a lavorare sul serio.
A mamma per avermi sempre incoraggiato, coccolato in questi periodi di stress
(in realtà da sempre) e per aver continuamente cercato di darmi una mano nel
momento in cui ne avevo più bisogno.
A mio fratello Cesare (ma anche a sua moglie Serena!), che grazie ai suoi
buoni consigli mi ha guidato, e addirittura negli ultimi giorni di lavoro mi ha
aiutato a scrivere ed ultimare la tesi. Senza di lui non credo che ce l‟avrei fatta
in tempo.
Voglio ringraziare la mia ragazza Maria, perché da quando ci siamo conosciuti
ha saputo vedere oltre quel ragazzo pigro ed immaturo che mi ritrovo di essere
e grazie al suo affetto mi ha aiutato a tirare fuori il meglio di me.
Un grazie al prof. Fabio Vitali per la sua fiducia e disponibilità e perché mi ha
permesso di conoscere le tecnologie delle quali oggi sono affascinato, e che in
futuro potrebbero influenzarmi nella scelta di un lavoro. Un caloroso
ringraziamento anche ad Angelo Di Iorio, Paolo Marinelli ed Antonio Feliziani
che mi hanno seguito nella fase di sviluppo del progetto e di stesura della
dissertazione, in caso di necessità sono sempre stati presenti.
Un grandissimo omaggio al famoso DrillTeam (il mio gruppo di progetto
dell‟università), più precisamente a Piergiorgio Pallotti, Enrico Sasdelli e
Jacopo Zingoni. Dopo tante avventure e tanti esami affrontati insieme non
57
credo che avrei potuto trovare dei compagni di università migliori di loro. Il
nome del mio progetto è interamente dedicato al nostro stile.
A tutti i miei amici e tutti coloro che mi sono stati vicino in questi anni, che mi
hanno incoraggiato, che hanno creduto in me: grazie di cuore!
58

Conversione tra formati documentali aperti

Transcript

Documenti analoghi

separazione e divorzio in comune

Comunicato Stampa RETTIFICA RAPPORTO DI

Programma del corso

editoriale don Nico Dal Molin 6_2016

Project Specification `Un server per lo SMIL

conversione video

Omelia per san Giovanni 2014

Il convertitore analogico-digitale ADC0804

Scienza e fede per custodire il Creato