Skip to topic | Skip to bottom
Home

Tesi
Tesi.MetaTesir1.71 - 02 Dec 2008 - 23:57 - GiacomoBoccardotopic end

Start of topic | Skip to actions

Generazione automatica di template a partire da metamodelli

Autore: Giacomo Boccardo

Relatore: Chiar.mo Prof. Fabio Vitali

Correlatore: Dott. Angelo Di Iorio

Keywords: authoring, templating, metamodelli, XSLT, XML

Ultima revisione: 03/12/2008, 00:00:02

. .

1 Introduzione

L'obiettivo di questa tesi è generalizzare i meccanismi di meta-conversione di ISA (Immediate Site Activator, [Vit03]), in modo da produrre template XSLT a partire da un qualsiasi documento di templating opportunamente marcato. Correntemente, ISA consente di identificare aree attive in un documento HTML e di generare un foglio di trasformazione XSLT, il quale applica il layout di tale documento a contenuti differenti: questo è il meccanismo di meta-conversione, definito con tale vocabolo per sottolineare il fatto che la prima fase consiste nel produrre, grazie ad un meta-foglio di stile XSLT, il foglio di stile XSLT utilizzato successivamente per formattare i documenti dei contenuti.

ISA* è un'architettura nata come generalizzazione del progetto ISA, un'applicazione per la creazione di pagine Web che separa la produzione dei contenuti da quella dei layout, non necessitando di conoscenze di linguaggi di markup (XML, HTML, XHTML) o di stile (CSS, XSLT).

ISA* si applica a realtà molteplici quali:

  • ISADesign: inizialmente denominato ISA, è la versione originale appena citata;
  • ISAWiki: volto alla produzione di pagine Web nell'ottica del modello fornito dai wiki;
  • ISAPress: utilizzato per la creazione di documenti destinati alla stampa professionale;
  • ISALearning: realizzato per sviluppare prodotti nell'ambito dell'e-learning.

Nel caso di ISADesign, il contenuto delle pagine Web è prodotto per mezzo di un editor di larga diffusione, Microsoft Word, ed esportato in formato HTML; il layout, invece, può essere generato da un qualsiasi editor grafico in grado di effettuare lo slicing, ovvero tale da consentire di definire graficamente delle aree in un'immagine ed esportare il tutto in formato HTML sotto forma di tabella di layout. ISADesign, tramite un meta-foglio di stile XSLT, processa il documento HTML del layout trasformandolo in un ulteriore foglio di stile XSLT, il quale, applicato al documento del contenuto, produce la pagina Web finale. Questo meccanismo automatico non è presente nelle altre versioni di ISA*, nelle quali il documento XSLT che attua l'ultima trasformazione è scritto a mano.

Ma perché limitarsi al solo linguaggio HTML? L'utilizzo di XSLT consente, infatti, di lavorare con qualsiasi documento in formato XML, potendo così spaziare in ambiti differenti quali la stampa professionale o l'e-learning.

Il software, sviluppato parallelamente alla ricerca effettuata per questa tesi, d'ora in poi definito JMC ed illustrato nel Capitolo 3, rende possibile la funzionalità di estrazione del layout dal documento di templating. Inoltre, consente di trasformare i documenti dei contenuti in modo tale da essere adattati ai linguaggi di destinazione dei template: concretamente si può, ad esempio, creare un template che restituisca un documento XSL-FO, prendendo il contenuto da una pagina HTML, o viceversa.

Per meglio comprendere l'idea che sta alla base della tesi è opportuno soffermarsi sul concetto di template, evidenziando le motivazioni che portano ad adottare tale tecnologia e gli ambiti di utilizzo della stessa.

Nell'accezione più generale, il termine template, che si potrebbe tradurre in questo contesto con modello, identifica la struttura secondo la quale formattare dei dati. Per fare un paragone con qualcosa di più concreto e vicino alle esperienze comuni, si pensi alla classica carta intestata, che riporta generalmente i dati del possessore, quali nome, cognome, indirizzo e telefono: l'utente non deve ogni volta riscriverli, ma può limitarsi a riempire le parti variabili, risparmiando tempo ed evitando possibili errori.

L'utilizzo dei template è una tecnica ampiamente diffusa per attuare una separazione tra ambiti differenti di un'applicazione. Una rappresentazione incompleta di dati può essere vista come un template, le cui parti da completare sono definite in [Aßm03] con il termine slot.

Il processo che ha come obiettivo quello di riempire gli slot con i dati è definito istanziazione del template ed è portato a termine dal cosiddetto template engine. Tale processo è illustrato nella Figura 1.


Processo di istanziazione di un template

Figura 1 - Processo di istanziazione di un template


Il linguaggio risultante dalla trasformazione è definito linguaggio di destinazione (target language), mentre il linguaggio di template (template language) è una combinazione tra il linguaggio di destinazione e il cosiddetto binding language, il quale ha lo scopo di identificare gli slot nei quali il template engine deve inserire i dati.

Il sottoinsieme di direttive del binding language preposte a tale scopo è definito slot markup language e può essere progettato a diversi livelli di espressività: da un semplice linguaggio copyhole, che si limita ad identificare zone in cui inserire dati senza ulteriori fasi di elaborazione, ad uno più funzionale caratterizzato, ad esempio, da costrutti condizionali o dalla possibilità di iterazione sui dati.

La motivazione principale per la quale si utilizzano i template è parte della filosofia di un buon programmatore: separare nettamente la logica sottesa all'elaborazione dei dati dalla formattazione degli stessi, ovvero il contenuto dalla sua rappresentazione grafica.

Tale separazione porta ai benefici individuati in [Par04], i quali sono:

  • incapsulamento o modularità: la componente grafica è completamente confinata nei template e la logica funzionale nel modello dei dati, rendendo ciascuna entità completa e ben distinta dalle altre;
  • chiarezza: un template non è un programma che si manifesti solamente con la sua resa grafica, ma un file che i programmatori e i designer possano leggere in modo diretto;
  • divisione del lavoro: i designer grafici possono costruire i template di un sito parallelamente ai programmatori, riducendo il carico di lavoro dei programmatori stessi e i costi di comunicazione;
  • riutilizzo dei componenti: analogamente alla suddivisione compiuta dai programmatori di metodi troppo lunghi in una serie di metodi più brevi, chiari e specifici, i designer grafici possono suddividere i template in sotto-template (ad esempio: barre di navigazione, campi di ricerca, liste di dati, ecc.) in modo da poterli riutilizzare in contesti differenti;
  • modifiche singole: grazie alla fattorizzazione dei template, si evita, nel caso di modifiche da attuare agli stessi, di dover effettuare cambiamenti in diversi moduli, con il rischio di ottenere comportamenti inconsistenti nel loro funzionamento e nella loro interazione;
  • manutenzione: la revisione dell'aspetto grafico di un sito richiede la modifica di un template e non di un programma. Quest'ultima, generalmente, è più rischiosa rispetto ad un cambiamento effettuato in un template. Inoltre, la variazione di un template non richiede il riavvio del software, cosa che solitamente è necessaria per un programma di cui si debba ricompilare il codice;
  • skin intercambiabili: solo una netta divisione tra il modello dei dati e la rappresentazione grafica può consentire ad un designer grafico di modificare l'aspetto del sito in modo immediato, senza la necessità di riscriverne completamente il codice;
  • sicurezza: la separazione tra il modello dei dati e la rappresentazione grafica dello stesso garantisce un maggior livello di sicurezza, evitando che un utente malintenzionato possa accedere direttamente a funzioni del sistema.

Lo scopo di questa tesi consiste proprio nell'estrarre da documenti formattati, che costituiscono il prodotto finale dell'unione tra dati e rappresentazione grafica degli stessi, dei template che applichino il layout dei documenti originali, in modo tale da renderli riutilizzabili con dati differenti e, potenzialmente, appartenenti ad altri formati.

Ciò consente di non dover elaborare il template e testarne progressivamente la resa grafica fino a raggiungere quella desiderata, ma, piuttosto, di ricercare un documento già formattato ed adatto alle esigenze, marcarlo opportunamente e lasciare che sia JMC ad estrarre il template.

Come già accennato precedentemente, l'utilizzo dei template è auspicabile in tutti i processi di produzione in cui vi sia la necessità di avere una separazione tra differenti fasi di realizzazione di un prodotto finale.

Ciò avviene normalmente in qualsiasi ambito lavorativo in cui si debba creare un prodotto da riprodurre su vasta scala e/o per la cui creazione siano necessarie figure professionali differenti che debbano interagire. Per limitare gli sprechi di tempo nei vari passaggi che portano dalla progettazione alla realizzazione finale, consentendo a tutti, in una situazione ideale, di lavorare in parallelo, vi è la necessità di fornire ad ogni singolo agente del sistema strumenti che gli permettano di svolgere il proprio lavoro autonomamente, senza interazione con altri aspetti del progetto che non gli competono. Inoltre, l'integrazione delle varie parti deve risultare praticamente automatica e non richiedere un intervento significativo da parte di terze persone.

Per fare un esempio, si pensi alla realizzazione del sito Web di un quotidiano. Le figure professionali coinvolte possono essere più o meno numerose in base alle esigenze, così come più o meno differenziate nei ruoli che devono ricoprire. Volendo separare il più possibile le competenze, senza alcuna pretesa di esaustività, una possibile suddivisione potrebbe essere la seguente ( [FCA00] ):

  • Web Master: è il responsabile del sito ed ha il ruolo di mantenerlo attivo sia dal punto di vista delle relazioni con il fornitore di spazio Web e connettività, sia aggiornando le informazioni presenti sullo stesso e coordinando il lavoro degli altri agenti;
  • Architect Engineer: progetta ad alto livello l'intero sistema, la rete, gli applicativi e le policy di sicurezza coordinando, di fatto, il System Engineer e il Network Engineer;
  • System Engineer: ha il compito di integrare il software e l'hardware;
  • Network Engineer: crea e gestisce la rete ed i sistemi di sicurezza;
  • Web Programmer: realizza le applicazioni presenti sul sito;
  • Web Designer: cura gli aspetti grafici dell'interfaccia del sito;
  • Web Editor: si occupa di fornire un'impronta caratteristica al sito in relazione alle informazioni da presentare, creando opportuni layout;
  • Web Producer: sviluppa aree del sito spaziando verso nuovi servizi, talora non necessariamente attinenti al servizio (ad esempio, un forum o una chat);
  • Net Researcher: valuta siti concorrenti e studia soluzioni atte a fornire nuove opportunità per accattivarsi gli utenti;
  • Web Advertiser: studia l'impatto della pubblicità e mantiene contatti con i soggetti interessati alla promozione sul sito stesso;
  • Web Marketing Strategist: cura gli aspetti legati alla promozione del sito sia in ambito telematico, che con mezzi più tradizionali;
  • SEO Strategist: Search Engine Optimization Strategist, attua strategie per migliorare il posizionamento del sito nei motori di ricerca;
  • Giornalista: senza suddividere ulteriormente i ruoli, è la figura professionale che produce i contenuti effettivi del sito, siano essi semplice testo, immagini o documenti multimediali.

Come si può osservare, in questo scenario ipotetico, la realizzazione del sito richiede numerose competenze ed è impensabile che tutti possano condividere le medesime conoscenze. Se, tuttavia, ciò può accadere tra figure quali il Net Researcher e il Web Marketing Strategist, che potrebbero essere ricoperte da una stessa persona, lo stesso non si può dire, ad esempio, di un giornalista e di un Web Editor.

Astraendo, il processo di realizzazione di un sito Web professionale è generalmente caratterizzato da quattro stadi nettamente separati ( [Vit03] ):

  • progettazione dell'architettura: l'intera struttura del sito deve essere progettata in ogni sua parte, quanto ad organizzazione dei contenuti, interazione degli utenti ed usabilità;
  • progetto grafico: consiste nella realizzazione dei template che forniscono lo scheletro delle varie pagine, completi di decorazioni e contenuti comuni a più pagine (quali il logo, il menu di navigazione, ecc.); tale compito è solitamente affidato ad un grafico professionista;
  • progettazione del back-end: trattandosi di un sito professionale, ci si aspetta che le pagine finali siano create dinamicamente; ciò comporta spesso la necessità di progettare ed integrare nel Web server un database, compiti destinati a programmatori esperti;
  • creazione dei contenuti: nella produzione del contenuto si può spaziare da testo semplice a documenti formattati, da immagini a contenuti multimediali ben più complessi.

In questo scenario, normalmente, chi produce i contenuti ha due possibili alternative per portare a termine il proprio lavoro: fornire il testo ad un esperto del linguaggio dell'interfaccia, che deve occuparsi di copiarlo nelle aree opportune, spesso formattandolo nuovamente, o imparare ad utilizzare l'eventuale interfaccia che il sito Web fornisce per l'inserimento dei contenuti. In entrambe le situazioni vi è uno spreco di tempo: nel primo caso si avverte immediatamente come il passaggio sia da evitare, mentre nel secondo l'inefficienza è implicita nella necessità di chi produce i contenuti di imparare ad utilizzare uno strumento di cui non è a conoscenza e che non gli compete.

Un approccio differente, che si applica al caso della produzione di contenuti Web e che tiene in conto la separazione dei ruoli dello sviluppatore di contenuti e del progettista di layout, è appunto ISA, descritto nella Sezione 2.3.3. Per poter estendere le funzionalità di ISA, sono stati presi in esame altre tecnologie e software sviluppati per l'authoring multi-canale e, specificatamente, relativi agli ambiti della produzione di documenti per il Web e per la stampa cartacea. L'analisi degli stessi, comprensiva di pregi e difetti, è materia Capitolo 2.

La soluzione proposta e sviluppata nell'ambito di questa tesi, denominata JMC, si pone come obiettivo la proposizione di un modello che consenta, alle figure coinvolte nella creazione di un prodotto destinato ad un utente finale, di lavorare separatamente sulle diverse parti che lo compongono. In particolare, gli aspetti di interesse riguardano la generazione dei layout e la produzione dei contenuti. Inoltre, si vuole lasciare la libertà ai professionisti di utilizzare strumenti di loro conoscenza, che non richiedano competenze ulteriori.

Un possibile esempio, ampiamente discusso nel Capitolo 3, congiuntamente con la descrizione del modello di JMC, consiste nella produzione di un sito Web. I contenuti sono realizzati tramite un editor noto, quale Microsoft Word, opportunamente marcati secondo la sintassi di JMC tramite gli stili di formattazione del testo ed esportati in formato HTML. Parallelamente, il layout è sviluppato da un designer Web grazie ad un editor grafico, come può essere Adobe Photoshop e, tramite la funzionalità di slicing, esportato in formato HTML, dopo aver assegnato alle aree definite con lo slicing opportuni valori della sintassi di JMC.

Detta sintassi, introdotta nei due documenti esportati, consente a JMC di estrarre da quest'ultimo il layout identificato dall'utente e di applicarlo ai contenuti del primo, ottenendo come prodotto finale una pagina Web. In pratica, i valori con cui sono identificate le aree del layout, che devono avere come corrispondenti i nomi degli stili presenti nel documento dei contenuti, rendono possibile l'introduzione del testo nelle opportune aree del layout. Questa può essere considerata come la funzionalità basilare di JMC e la sintassi utilizzata nel documento di templating è definita embedded, in quanto sfrutta elementi ed attributi del linguaggio ospite, in questo caso HTML.

Per ottenere funzionalità avanzate è proposta una sintassi, definita full, che richiede l'inserimento nel documento di templating di elementi ed attributi propri di JMC, non appartenenti alla grammatica del linguaggio ospite. Tutto ciò necessita di conoscenze più specifiche del linguaggio XML. Più in particolare, la sintassi full, oltre a definire aree in cui inserire dei contenuti testuali, consente di introdurre, ad esempio, un costrutto condizionale o un elemento ripetibile, basati su condizioni definite tramite XPath, così come di definire trasformazioni particolari per elementi specifici.

Infine, è possibile definire corrispondenze tra elementi di linguaggi differenti, con il risultato di poter avere un documento di templating che formatti un documento di contenuti realizzato tramite un linguaggio differente: ad esempio, un layout HTML potrebbe accogliere il testo presente in un documento XSL-FO.

La descrizione dettagliata dei linguaggi embedded e full è riportata nel Capitolo 4, nel quale sono anche proposti alcuni editor per la creazione dei documenti di templating e dei contenuti, con riferimento particolare alla prima sintassi.

Nel medesimo capitolo è trattata l'implementazione di JMC, costituita da fogli e meta-fogli di stile XSLT, la cui esecuzione è gestita grazie ad Apache Ant. In particolare, sono illustrati i file principali ed è proposto un esempio di estrazione di un template da un documento di templating opportunamente marcato con la sintassi full.

A chiusura della tesi, il Capitolo 5 riassume l'iter che ha portato, dall'analisi del problema riguardante la separazione dei ruoli nell'ambito dell'authoring multi-canale, alla progettazione e realizzazione di JMC, passando attraverso la constatazione dei limiti delle soluzioni software esistenti.

2 Stato dell'arte

In questo capitolo si vogliono analizzare la letteratura e le soluzioni software concrete nell'ambito dell'authoring mono-canale e multi-canale, ovvero della creazione di contenuti destinati agli utenti finali, forniti tramite supporti differenti.

Per maggiore chiarezza, si è cercato di suddividere il tutto in base alle diverse aree di applicazione, focalizzando l'attenzione su strumenti per la creazione di pagine Web (Sezione 2.1), sulla produzione di documenti XSL-FO (Sezione 2.2) ed, infine, su soluzioni in grado di gestire formati differenti (Sezione 2.3).

2.1 Authoring finalizzato al Web

Lo sviluppo di Internet sta portando gli utenti a trasformarsi da semplici lettori a creatori di contenuti, così come i servizi offerti si moltiplicano ogni giorno in maniera incontrollata.

Se un utente privo di conoscenze informatiche e con poche pretese può limitarsi a scrivere semplici contenuti statici, lo stesso non si può dire in ambito professionale, dove è necessario avere strumenti adeguati a sviluppare un sito Web coerente in ogni sua parte, facilmente aggiornabile e manutenibile nel tempo.

2.1.1 MyXML

La separazione tra layout e contenuto è alla base della ricerca sviluppata da Clemens Kerer and Engin Kirda in [KK01] e ripresa dagli stessi, insieme a Mehdi Jazayeri e Roman Kurmanowytsch, in [KKJ01].

Per raggiungere tale obiettivo, sono stati identificati i linguaggi XML e XSL, i quali consentono rispettivamente di modellare contenuti privi di caratteristiche presentazionali e di definire layout per la formattazione di documenti XML. In tal modo è possibile restituire i contenuti formattati in base alle caratteristiche dei dispositivi che ne fanno richiesta.

I requisiti basilari che sono stati identificati per attuare una separazione tra layout, contenuto e logica funzionale (nel senso di business logic) sono:

  • la capacità di estrarre dati statici da una base di dati e strutturarli grazie ad XML;
  • la necessità di definire aree attive nei layout (denominate, in questo ambito, hook) alle quali possa essere associato il contenuto dinamico;
  • la capacità di definire template che supportino CGI ed SQL, per poter gestire database e logica funzionale.

Questi requisiti consentono, a chi lavora sul contenuto, di sviluppare la sua parte indipendentemente da chi lavora sul layout o sulla logica funzionale, sicché una modifica attuata in una delle tre componenti non richieda alcun intervento sulle altre.

Come già affermato, il contenuto è strutturato tramite il linguaggio XML ed il layout tramite fogli di stile XSL, mentre la logica funzionale può essere scritta in un qualsiasi linguaggio di programmazione. Il software sviluppato per gestire questa situazione, MyXML, sfrutta l'introduzione nel documento dei contenuti di elementi definiti appositamente allo scopo.

Il processo di conversione che porta alla formattazione del documento XML dei contenuti tramite trasformazioni XSLT è rappresentato nella Figura 2.


Funzionamento concettuale di MyXML

Figura 2 - Funzionamento concettuale di MyXML


Il documento di input, necessariamente in formato XML, viene decorato con informazioni di layout nella fase di pre-processing ed eventualmente vengono aggiunti componenti statici, quali header o footer, tramite un foglio di stile XSLT. Nella fase successiva entra in gioco il cuore vero o proprio di MyXML, che opera una distinzione in base al contenuto statico o dinamico presente nel documento: si considera dinamico se esiste almeno un elemento MyXML dinamico, quale, ad esempio, un'interrogazione di un database, statico se tutti gli elementi MyXML possono essere valutati direttamente, senza la necessità di ulteriori trasformazioni.

Nel caso di un documento statico vengono processati gli elementi presenti ed eventualmente si attua una fase di post-processing prima di restituire il documento finale. Se il documento è dinamico è necessario produrre del codice che gestisca gli elementi MyXML dinamici: il formato del codice prodotto è arbitrario, grazie ad un'interfaccia del sistema che va implementata per supportare il linguaggio desiderato. Correntemente, è gestita la creazione di codice Java.

Per mostrare un'applicazione pratica del sistema, si consideri il documento di input, contenente alcuni elementi MyXML, riportato nell'Esempio 1.


<?xml version="1.0" encoding="US-ASCII"?> 
<!DOCTYPE event_search> 
<event_search xmlns:myxml="http://www.infosys.tuwien.ac.at/ns/myxml"> 
    <myxml:sql> 
        <myxml:dbcommand> 
            SELECT title, date, description FROM VIF_EVENTS 
            WHERE id = ’<myxml:cgi>id</myxml:cgi>’; 
        </myxml:dbcommand> 
        <event> 
            <title><myxml:dbitem>title</myxml:dbitem></title> 
            <date><myxml:dbitem>date</myxml:dbitem></date> 
            <description> 
                <myxml:dbitem>description</myxml:dbitem> 
            </description> 
        </event> 
    </myxml:sql> 
</event_search>

Esempio 1 - Documento di input definito nel linguaggio di template MyXML


Gli elementi <myxml:sql> e <myxml:cgi> modellano l'input dell'utente tramite un parametro CGI ed una richiesta al database, mentre gli elementi <myxml:dbitem> restituiscono i dati ottenuti dal database. Tali valori sono elaborati nella fase di pre-processing.

Successivamente, un foglio XSL, come può essere quello riportato nell'Esempio 2, aggiunge le informazioni di layout al documento così ottenuto.


<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" 
        xmlns:myxml = "http://www.infosys.tuwien.ac.at/ns/myxml">
    <xsl:import href="myxml.xsl"/>
    <xsl:output method="html" indent="yes"/> 

    <xsl:template match="event_search"> 
        <html>
            <body>
                <xsl:apply-templates/>
            </body>
        </html> 
    </xsl:template>
    
    <xsl:template match="event"> 
        <h1><xsl:apply-templates select="title"/></h1> 
        <table>
            <xsl:apply-templates/>
        </table> 
    </xsl:template>
    
    <xsl:template match="date"> 
        <tr> 
            <td>Date:</td> 
            <td><xsl:apply-templates/></td> 
        </tr> 
    </xsl:template>
    
    <xsl:template match="description"> 
        <tr> 
            <td>Description:</td> 
            <td><xsl:apply-templates/></td> 
        </tr> 
    </xsl:template> 
</xsl:stylesheet>

Esempio 2 - Foglio XSLT per la definizione del layout


Il foglio di stile XSLT elabora il documento di input aggiungendo elementi statici, quali <html> o <body>, formatta il titolo e crea una tabella per le restanti informazioni. A questo punto, il layout è completo, ma mancano i dati, quindi il motore di MyXML determina se il documento sia statico o meno per procedere con la fase successiva. In questo caso il documento è chiaramente dinamico, poiché necessita dell'interrogazione di un database: il codice Java prodotto è riportato nell'Esempio 3.


public class event { 
    [...]   
    
    public void printHTML !PrintWriter pw) { 
        pw.println("<html>"); 
        pw.println(" <body>"); 
        printHTMLSQL0(pw); 
        pw.println(" </body>"); 
        pw.println("</html>"); 
    }
    
    public void printHTMLSQL0 !PrintWriter pw) { 
        try { 
            SQL0 = processSQLStatement( 
                "SELECT title, date, description FROM VIF_EVENTS WHERE id = ’ " + 
                getCGIParameter("id") + " ’; ", "some_user", "some_passwd", 
                "jdbc:mysql://www.festwochen.at:10000", "org.gjt.mm.mysql.Driver"); 
            while (SQL0.next()) { 
                pw.println(" <h1>" + SQL0.getString("title") + "</h1>"); 
                pw.println(" <table border=\"1\">"); 
                pw.println(SQL0.getString("title")); 
                pw.println(" <tr>"); 
                pw.println(" <td>Date:</td>"); 
                pw.println(" <td>" + SQL0.getString("date") + "</td>"); 
                pw.println(" </tr>"); 
                pw.println(" <tr>"); 
                pw.println(" <td>Description:</td>"); 
                pw.println(" <td>" + SQL0.getString("description") + "</td>"); 
                pw.println(" </tr>"); 
                pw.println(" </table>"); 
            } 
        } catch (SQLException se) { }
    } 
}

Esempio 3 - Codice Java generato da MyXML


Come si può aver intuito, per utilizzare tale classe è sufficiente istanziarla ed invocare il metodo printHTML(), compito che può essere svolto da un servlet. In questo modo, la logica funzionale è indipendente dal contenuto e dalle informazioni di layout presenti nella classe. Un possibile output finale, per una richiesta arbitraria al database, è riportata nell'Esempio 4.


<html> 
    <head> 
        <title>VIF - Macbeth</title> 
    </head> 
    <body> 
        <h1>Macbeth</h1> 
        <table> 
            <tr> 
                <td>Date:</td> 
                <td>07.03.2000</td> 
            </tr> 
            <tr> 
                <td>Description:</td> 
                <td>Shakespeare’s famous play.</td> 
            </tr> 
        </table> 
    </body> 
</html>

Esempio 4 - Pagina Web risultante


Dagli esempi mostrati si è potuto osservare come vi sia una separazione netta tra contenuti, layout e logica funzionale. Ciò consente di sviluppare siti Web flessibili e rendere i processi di aggiornamento e manutenzione semplici, potendo assegnare i compiti ai soli professionisti competenti, senza che vi siano sovrapposizioni di ruoli.

Pur essendo un meccanismo efficace, il suo punto debole è insito nella necessità di conoscere i linguaggi XML e XSLT per portare a termine anche i compiti più semplici.

2.1.2 Apache Cocoon

Software open source sviluppato dall'Apache Software Foundation, Apache Cocoon ( [Coc08] ) è un framework multi-piattaforma per la produzione di siti Internet nato con l'intento di separare le attività di sviluppo degli stessi grazie ad un modello basato su componenti ben differenziati.

La flessibilità garantita dall'utilizzo di XML consente di produrre, oltre naturalmente al linguaggio HTML, anche altri formati, quali PDF o WML.

Il processo di formattazione dei contenuti è gestito secondo il concetto della pipeline, ovvero una serie di fasi successive in cui l'input di ciascuna è l'output della precedente, fino a raggiungere il formato finale desiderato. Astrattamente, il flusso di esecuzione consiste nei seguenti passi:

  • accettare la richiesta da parte dell'utente;
  • stabilire la pipeline da usare per portare a termine la richiesta;
  • costruire la pipeline con i componenti preconfigurati;
  • eseguire la richiesta tramite la pipeline;
  • restituire l'output finale della pipeline nel formato richiesto dall'utente, eventualmente effettuando caching.

La dichiarazione dei componenti e delle pipeline avviene tramite il cosiddetto sitemap, ovvero un file XML avente come struttura quella riportata nell'Esempio 5.


<map:sitemap xmlns:map="http://apache.org/cocoon/sitemap/1.0">
    <map:components> <!-- Dichiarazione dei componenti -->
        <map:generators/>
        <map:readers/>
        <map:transformers/>
        <map:actions/>
        <map:serializers/>
        <map:matchers/>
        <map:selectors/>
    </map:components>
    <map:pipelines>
        <!-- Definizione delle pipeline -->
    </map:pipelines>
</map:sitemap>

Esempio 5 - Sitemap di Cocoon


Ciascun componente, a sua volta, è identificato da un opportuno elemento XML che fa riferimento alla classe Java che ne implementa le funzionalità. Un possibile esempio di pipeline per soddisfare la richiesta di pagine HTML create dinamicamente da documenti XML è quello mostrato nell'Esempio 6: è abbastanza intuitivo comprendere come il pattern "*.html" serva ad intercettare le richieste di pagine Web con tale estensione ed i successivi elementi indichino rispettivamente i file XML dei contenuti, il foglio di trasformazione XSLT da utilizzare ed il formato dell'output.


<map:sitemap xmlns:map="http://apache.org/cocoon/sitemap/1.0">
    <map:pipelines>
        <map:pipeline>
            <map:match pattern="*.html">
                <map:generate src="contenuti/{1}.xml"/>
                <map:transform src="stylesheets/xml2html.xsl"/>
                <map:serialize type="html"/>
            </map:match>
        </map:pipeline>
        [...]
    </map:pipelines>         
</map:sitemap>

Esempio 6 - Pipeline di Cocoon


Nel caso vi siano richieste di pagine dinamiche, è necessario utilizzare la tecnologia XSP (XML Server Pages), la quale, senza entrare nei particolari, consente di combinare codice Java e codice XML per creare contenuti dinamici da fornire, successivamente, alle opportune pipeline.

La creazione dei suddetti file, benché possa essere eventualmente mediata da editor, richiede la comprensione del funzionamento di un'architettura relativamente complessa, così come dei vari linguaggi utilizzati. Inoltre, l'ambiente di esecuzione più utilizzato per Cocoon è generalmente un Servlet container, quale Tomcat ( [Tom08] ). È dunque chiaro come l'utilizzo di Cocoon richieda conoscenze che vanno sicuramente al di là di quelle possedute da un designer di siti Internet.

2.1.3 Il modello dei CMS

I CMS (Content Management Systems), ovvero "sistemi di gestione dei contenuti", rappresentano una tipologia di sistemi software atti ad organizzare e semplificare creazione, modifica e pubblicazione di contenuti, generalmente destinati ad Internet. L'utilizzo classico riguarda siti di considerevoli dimensioni, aggiornati di frequente da un'utenza eterogenea, senza conoscenze tecniche specifiche.

Per rendersi conto della varietà delle soluzioni offerte, se ne possono comparare circa un migliaio presso il sito http://www.cmsmatrix.org/, tenendo comunque presente che quelli di più largo utilizzo sono dell'ordine di poche decine.

L'interazione richiesta dall'utente tipo avviene tramite un'interfaccia grafica, e, più precisamente, per mezzo di un'area di testo in cui inserire il contenuto. Eventualmente, un editor WYSIWYG può agevolare l'aggiunta di caratteristiche di formattazione o di contenuti multimediali, per cui non si rende necessario l'intervento di un'altra persona che si occupi di formattare i contenuti integrandoli nel layout esistente.

Tra i CMS più utilizzati si possono citare Drupal (http://drupal.org/), Joomla! (http://www.joomla.org/) e Wordpress (http://wordpress.org/), strumenti estremamente versatili e dotati di ogni genere di estensione. Nella Figura 3 è mostrato il form con cui avviene l'editing di un post in Wordpress: si noti, in particolare, la ricca barra degli strumenti che consente la formattazione dei contenuti.


Form per l'editing di un post in Wordpress

Figura 3 - Form per l'editing di un post in Wordpress


Se l'inserimento di contenuti è facilitato dall'interfaccia, lo stesso non si può dire per la creazione dei template che definiscono i layout. Benché per i CMS più diffusi vi siano talora centinaia di template distribuiti gratuitamente o a pagamento, una personalizzazione particolare di questi ultimi richiede conoscenze di HTML, del linguaggio di scripting utilizzato dalla piattaforma e nozioni riguardo l'interrogazione del database in cui vengono salvati i contenuti.

2.1.4 Il modello dei Wiki

I cosiddetti wiki sono siti Internet realizzati per poter essere aggiornati in modo collaborativo da comunità di utenti. Le differenze sostanziali rispetto ai CMS sono da ricercare nella necessità di sistemi di versionamento atti a prevenire attività di vandalismo nei confronti dei contenuti stessi. In altre parole, si deve avere la possibilità di ripristinare versioni precedenti dei dati con la conseguente necessità di disporre di meccanismi che consentano agli autori di avere privilegi differenti in base ai ruoli che svolgono. Inoltre, gli utenti devono solitamente imparare ad utilizzare una sintassi specifica per prodotti diversi. L'utilizzo più eclatante di un wiki è sicuramente Wikipedia (http://www.wikipedia.org/), enciclopedia universale che si basa sul software MediaWiki (http://www.mediawiki.org/), sviluppato in linguaggio PHP, e i cui dati sono salvati in un database MySQL. Nella Figura 4 è riportato il classico form di inserimento dei contenuti di MediaWiki: si può osservare una barra di strumenti minimale e si intravedono alcuni degli elementi della sintassi da utilizzare per la formattazione del testo.


Form per l'editing di una pagina di MediaWiki

Figura 4 - Form per l'editing di una pagina di MediaWiki


È evidente come il sistema di inserimento dei contenuti non sia adatto agli utenti casuali, poiché necessita di un discreto tempo di apprendimento, soprattutto per aggiornare pagine dal layout relativamente complesso. Analogamente ai CMS, la produzione di layout richiede conoscenze specifiche del prodotto.

2.2 Authoring finalizzato alla stampa

In questa sezione sono analizzate alcune soluzioni software che hanno come obiettivo quello di creare documenti XSL-FO che, generalmente, vengono convertiti in formati adatti alla stampa cartacea.

2.2.1 FOA

FOA (Formatting Object Authoring, [Gia02]) è uno strumento open source, reperibile presso http://foa.sourceforge.net/, che permette di applicare una formattazione avanzata a documenti XML. Gli stili creati possono essere riutilizzati, esportando delle librerie ed utilizzandole per generare il layout di altri documenti.

Il software sfrutta il linguaggio di markup XSL-FO, definito dal W3C in [XSL06], nato per la formattazione avanzata di documenti suddivisi in pagine. In base agli stili scelti, viene prodotto un foglio di stile XSLT che, applicato al documento XML sorgente, produce un documento XSL-FO, il quale può essere a sua volta trasformato in differenti formati di destinazione, come, ad esempio, un documento PDF.

La Figura 5 mostra il funzionamento concettuale di FOA, evidenziando la possibilità di attingere a più documenti XML e di utilizzare differenti insiemi di attributi per la formattazione.


FOA - Funzionamento concettuale

Figura 5 - FOA - Funzionamento concettuale


L'interfaccia grafica di FOA è costituita da sei componenti (vedi la Figura 6):

  • Page Manager: utilizzato per definire i layout delle pagine, impostando proprietà relative agli elementi FO, quali dimensioni e margini. Consente, inoltre, di specificare le regioni delle pagine definite nelle specifiche di FO, ovvero header, body, footer, left side e right side;
  • Page Sequence Manager: permette di definire sequenze di pagine, come da specifiche XSL-FO;
  • Attribute Set Manager: consente di specificare insiemi di attributi da applicare nella fase di formattazione;
  • XML Content Manager: fornisce una rappresentazione ad albero del contenuto dei documenti XML importati;
  • Brick Manager: utilizzato per gestire i cosiddetti brick, componenti descritti in seguito;
  • Content Sequence Manager: consente di associare porzioni di contenuto alle differenti regioni definite tramite il Page Manager. Si possono, dunque, collocare i brick definiti tramite il Brick Manager o nuovi contenuti, selezionando elementi da file XML differenti.


FOA - Interfaccia grafica

Figura 6 - FOA - Interfaccia grafica


Senza entrare qui nei dettagli del linguaggio di trasformazione, per fornire agli autori di documenti uno strumento che consenta loro di poter creare formattazioni più o meno complesse è stato creato un componente di trasformazione riutilizzabile definito brick. Ciascun brick è applica una formattazione ad un nodo ben preciso del documento XML, come un blocco di testo, una lista di voci, una tabella, e così via. Ogni brick è tradotto da FOA in codice XSLT che trasforma il contenuto XML in un insieme di Formatting Objects (FO).

Dal punto di vista dell'autore, il tutto si traduce nell'unico compito di collegare il contenuto XML ad uno stile, ovvero ad un insieme di attributi, tramite l'interfaccia grafica.

Nell'Esempio 7 è mostrata la struttura del codice relativo ad un brick semplice.


<xsl:template match="$path" foa:name="$label" foa:group="$group" foa:class="$class">
    <fo:$element foa:name="$label" foa:group="$group" xsl:use-attribute-sets="$label">
        <xsl:apply-templates />
    </fo:$element>
</xsl:template>

Esempio 7 - FOA - Un esempio basilare di brick


Si tratta di un template standard XSLT al quale sono stati aggiunti alcuni attributi, quali foa:name, foa:group e foa:class, che indicano, rispettivamente, l'etichetta, il gruppo ed il tipo di FO da creare nel processo di trasformazione. Le informazioni non strettamente legate al processo di trasformazione servono per ripristinare l'interfaccia grafica di FOA nel caso in cui venga riaperto il progetto; in particolare, è l'attributo foa:class a consentire l'associazione tra il brick e il FO, mostrando all'autore solo le proprietà che si applicano a quello specifico FO.


FOA - Interfaccia grafica e brick

Figura 7 - FOA - Interfaccia grafica e brick


La Figura 7 mostra la relazione tra l'interfaccia grafica ed il codice prodotto dalla creazione e dall'utilizzo di un brick.

In conclusione, FOA non è un editor WYSIWYG, ma permette tramite un sistema di preview di vedere l'output finale. Perciò è necessario procedere per tentativi fino ad ottenere il layout voluto. Inoltre, si è naturalmente vincolati all'uso dell'editor stesso per poter definire il layout, mentre JMC permette di utilizzare editor esterni, eventualmente già noti all'utente.

2.2.2 (V)CCSL

Nell'articolo [CC02] è proposto un approccio visivo per definire trasformazioni da XML a FO ed è discussa l'implementazione di un ambiente grafico che facilita la definizione del formato e della visualizzazione di documenti XML tramite una metafora contenuto-contenitore.

L'idea deriva da due osservazioni: la prima è che le trasformazioni da XML a FO non sono altro che un caso particolare dell'utilizzo del linguaggio XSLT; la seconda è che XSLT è un linguaggio formale difficile per gli utenti inesperti.

Tali motivazioni hanno portato a definire un linguaggio orientato allo stile di formattazione, denominato CCSL (Content Container Style Language), in cui sono formalizzati gli aspetti di formattazione e di modellazione e ad introdurre un linguaggio visivo, denominato VCCSL (Visual Content Container Style Language), il quale, tramite un'interfaccia grafica, consente di definire facilmente trasformazioni XSLT.

CCSL

CCSL è un linguaggio testuale basato su XSLT, XPath e FO, rispettivamente legati agli aspetti di formattazione, ricerca all'interno di file XML e definizione di stili di formattazione.


CCSL - Relazione tra CCSL e gli altri linguaggi

Figura 8 - CCSL - Relazione tra CCSL e gli altri linguaggi


Come si può osservare nella Figura 8, il contenuto è definito dal formalismo di XSD e XPath, mentre i contenitori da FO e XSLT. L'unione di questi costituisce il formalismo di CCSL che, in definitiva, è un insieme di regole XSLT, input di un motore XSLT che trasforma i documenti XML in documenti FO, i quali, a loro volta, possono essere convertiti in molteplici formati finali.

Contenuto

Il contenuto può essere definito alternativamente da una struttura XSD o da un documento XML, nel qual caso si considera una delle infinite definizioni XSD compatibili col documento XML.

Formalmente, un contenuto è definito da una tripla (C, T, N), dove:

  • C è un'espressione XPath che estrae i dati basandosi su una definizione XSD;
  • T indica il tipo di contenuto, che può essere semplice, se si tratta di un tipo primitivo (stringa, intero, booleano, ecc.), o composto, se comprende altre porzioni di contenuto;
  • N stabilisce la cardinalità del contenuto, che può essere singolare o plurale, rispettivamente se l'espressione XPath restituisce uno o più elementi.

Contenitore

Il contenitore è un'entità capace di accogliere al suo interno dei contenuti. Più precisamente, un contenitore è definito da una tripla (K, T, N), dove:

  • K è un'espressione FO che indica l'elemento che contiene direttamente il contenuto o un contenitore annidato, unitamente a specifiche di layout quali margini, bordi, caratteri, e così via, secondo la sintassi XSL;
  • T indica il tipo di contenitore, che può essere composto, se contiene, a sua volta, uno o più contenitori, o semplice se non ne contiene;
  • N stabilisce la cardinalità del contenitore, che può essere singolare o plurale, rispettivamente se il contenitore è presente una o più volte.

Relazioni tra contenuto e contenitore

Nelle sezioni che seguono C indica l'insieme dei contenuti e K quello dei contenitori, mentre le lettere c e k, eventualmente numerate, indicano elementi del rispettivo insieme.

Iterazione

Dato un contenitore k e un contenuto c, la relazione di iterazione può sussistere solo se entrambi sono di tipo plurale. L'Esempio 8 mostra come tale relazione si traduca incapsulando il contenitore in un'istruzione XSL for-each.


<xsl:for-each select="c">
    k
</xsl:for-each>

Esempio 8 - CCSL - Relazione di iterazione


Annidamento

Dato un contenitore k e un insieme di contenuti e contenitori x, vi può essere una relazione di annidamento solo se x è un contenuto e k un contenitore semplice o x è un contenitore e k un contenitore composto. In entrambi i casi il risultato è l'inclusione del contenuto o del contenitore all'interno di un elemento fo:block, come mostrato nell'Esempio 9.


x contenuto:
    <fo:block>
        <xsl:value-of select="x" />
    </fo:block>

x contenitore:
    <fo:block>
        x
    </fo:block>

Esempio 9 - CCSL - Relazione di annidamento


Precedenza

La relazione di precedenza è definita tra contenuti: un contenuto c1 è in relazione di precedenza rispetto ad un altro contenuto c2 se e solo se l'espressione XPath di c2 è relativa all'espressione XPath di c1. Tale relazione è conseguenza delle relazioni di annidamento ed iterazione, ed è legata al concetto di nodo contesto delle espressioni XPath.

Per comprendere meglio il senso, si osservi il frammento dell'Esempio 10.


<xsl:for-each select="//item">
    <fo:block>
        <xsl:value-of select="description" />
    </fo:block>    
</xsl:for-each>

Esempio 10 - CCSL - Relazione di precedenza


Si possono identificare gli elementi:

  • c1 = "//item";
  • c2 = "description";
  • k1 = "<fo:block></fo:block>".

Il contenuto c1 è composto e plurale ed è in relazione di precedenza rispetto a c2, contenuto semplice e singolare, ovvero c2 viene valutato nel contesto di c1. Il contenitore k1 è in relazione d'iterazione con il contenuto c1, perciò è plurale. Il contenuto c2 è in relazione di annidamento rispetto a k1, quindi k1 è un contenitore semplice.

VCCSL

VCCSL è un linguaggio visivo, basato su CCSL, nato dalla volontà di semplificare il processo di formattazione dei documenti XML. L'approccio adottato prevede fondamentalmente l'utilizzo di forme geometriche per definire contenitori, rappresentati da rettangoli, e contenuti, sotto forma di etichette testuali nelle quali sono inserite le espressioni XPath che identificano il contenuto. La Figura 9 mostra la traduzione delle componenti del linguaggio CCSL nel linguaggio VCCSL.


VCCSL - Mapping tra le notazioni CCSL e VCCSL

Figura 9 - VCCSL - Mapping tra le notazioni CCSL e VCCSL


La relazione tra contenuto e contenitore è resa tramite la collocazione reciproca degli oggetti. Per una migliore comprensione, si confrontino la Figura 10 con il relativo codice dell'Esempio 11.


VCCSL - Esempio di rappresentazione grafica

Figura 10 - VCCSL - Esempio di rappresentazione grafica



<xsl:template match="/">
    <xsl:for-each select="/todolist/item">
        <xsl:for-each select="author">
            <fo:block>
                <xsl:value-of select="current()" />
            </fo:block>    
        </xsl:for-each>
        <fo:block>
            <xsl:value-of select="description" />
        </fo:block>    
        <fo:block>
            <xsl:value-of select="end - start" />
        </fo:block>    
    </xsl:for-each>
</xsl:template>

Esempio 11 - VCCSL - Codice relativo alla Figura 10


Per mostrare il funzionamento del modello è stato sviluppato un prototipo, il quale tuttavia risulta essere irreperibile. La Figura 11 rappresenta l'unica immagine disponibile dell'editor ed è stata presa dall'articolo stesso da cui sono state dedotte le funzionalità descritte in questa sezione.


Editor VCCSL

Figura 11 - Editor VCCSL


Complessivamente, pur essendo interessante il modello proposto, si è fortemente vincolati ad un editor specifico per poter definire il layout, differentemente da JMC, come è già stato sottolineato ampiamente per altri prodotti.

2.3 Authoring multi-canale

In questa sezione si vogliono analizzare quelle soluzioni tecnologiche che consentono di gestire la produzione di documenti di formati differenti e che possono, quindi, essere impiegate in ambiti diversi. Inoltre, per loro stessa natura, propongono dei modelli generali, obiettivo da perseguire nell'ottica di questa tesi.

2.3.1 XSLT, il caso limite

XSLT (Extensible Stylesheet Language Transformations) è un linguaggio basato su XML sviluppato dal W3C, le cui specifiche costituiscono una parte sostanziale di XSL, definito in [XSL06]. L'origine stessa del linguaggio è da ricercarsi nella volontà di creare uno strumento tale da consentire la separazione del contenuto di un documento dalla sua presentazione grafica, nell'ottica della pubblicazione di dati su Internet. La sua versatilità, tuttavia, ha reso possibile il suo utilizzo in qualsiasi altro ambito in cui il documento risultante sia compatibile con un formato XML (vedi XSL-FO o SVG) o testo semplice. In termini pratici, un foglio di stile XSLT non è altro che un documento XML, pertanto tutte le caratteristiche lessicali di tale linguaggio sono automaticamente disponibili. Ciò rende estremamente semplice utilizzare un documento XSLT come input od output di una trasformazione, rendendo possibile la creazione di meta-fogli di stile, ovvero documenti XSLT che producono altri documenti XSLT secondo le esigenze dell'applicazione. Inoltre, risulta immediato inserire porzioni dell'output statico in formato XML all'interno del foglio di stile stesso: infatti, fogli di stile relativamente semplici possono essere costituiti semplicemente da un singolo template per il documento di output desiderato con l'aggiunta di alcune istruzioni per inserire le uniche parti variabili.

Il paradigma basilare di XSLT consiste nel pattern matching. Un documento XSLT è costituito da un insieme di template, ciascuno dei quali presenta una condizione (pattern) che, se verificata (match), attiva la trasformazione definita dal template stesso. Differentemente da altri linguaggi di elaborazione seriale di testo, XSLT non considera l'input in maniera sequenziale, ma piuttosto come un albero, pertanto, in generale, i template si applicano a nodi dell'albero. Per rendersi conto del funzionamento di XSLT, si consideri il codice XML di input dell'Esempio 12.


<books>
    <book>
        <title>Miliardi di Tappeti di Capelli</title>
        <author>Andreas Eschbach</author>
    </book>
    <book>
        <title>I Pilastri della Terra</title>
        <author>Ken Follett</author>
    </book>
</books>

Esempio 12 - Documento XML di input


Una semplice trasformazione che produce una pagina HTML minimale può essere quella generata dal foglio XSLT dell'Esempio 13.


<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="2.0">

    <xsl:output method="html" />
    
    <xsl:template match="books">
       <html>
           <head>
               <title>Libri</title>
           </head>
           <body>
               <table>
                   <thead>
                       <tr><td>Titolo</td><td>Autore</td></tr>
                   </thead>
                   <tbody>
                       <xsl:apply-templates select="book" />
                   </tbody>
               </table>
           </body>
       </html>
    </xsl:template>
    
    <xsl:template match="book">
        <tr>
            <td><xsl:value-of select="title"/></td>
            <td><xsl:value-of select="author"/></td>
        </tr>    
    </xsl:template>
    
</xsl:stylesheet>

Esempio 13 - Foglio di trasformazione XSLT con output HTML


È facile comprendere il comportamento del suddetto foglio di stile XSLT, considerando il documento di input come un albero: il primo template elabora l'elemento radice del documento di input, generando lo scheletro della pagina HTML e della tabella, mentre l'istruzione <xsl:apply-templates select="book" /> prosegue la trasformazione selezionando gli elementi del documento sorgente aventi come nome book. In tal modo viene eseguito il secondo template che produce, ad ogni chiamata, una riga della suddetta tabella, contenente rispettivamente in una cella il titolo del libro e nell'altra il nome dell'autore. Il risultato della trasformazione è quello riportato nell'Esempio 14.


<html>
   <head>
      <title>Libri</title>
   </head>
   <body>
      <table>
         <thead>
            <tr>
               <td>Titolo</td>
               <td>Autore</td>
            </tr>
         </thead>
         <tbody>
            <tr>
               <td>Miliardi di Tappeti di Capelli</td>
               <td>Andreas Eschbach</td>
            </tr>
            <tr>
               <td>I Pilastri della Terra</td>
               <td>Ken Follett</td>
            </tr>
         </tbody>
      </table>
   </body>
</html>

Esempio 14 - Risultato della trasformazione in HTML


Così come l'output può essere in formato HTML, lo stesso vale per qualsiasi altro linguaggio basato su XML (si pensi, ad esempio, al formato XSL-FO). Questa stessa tesi è scritta in formato XML, secondo la semantica del modello offerto da DocBook ( [Oas08] ). Ciò consente di ottenere documenti finali differenti.

Utilizzando i fogli di stile XSLT, forniti insieme a DocBook per la conversione in XSL-FO, è stato possibile ottenere con un ulteriore passaggio un documento PDF di alta qualità per la stampa. Per poter leggere la tesi direttamente su Internet, si è creato, invece, da zero un foglio di stile XSLT per la conversione nel linguaggio del wiki TWiki ( [TWi08] ). Il risultato è reperibile all'indirizzo http://tesi.fabio.web.cs.unibo.it/Tesi/MetaTesi.

In quest'ultimo caso, l'output non è costituito da un linguaggio strutturato aderente alle specifiche XML, ma, per così dire, testo semplice che segue una sintassi riconosciuta dal motore del software TWiki, il quale si occupa della conversione in formato HTML.

Tornando all'esempio precedente, un possibile foglio di stile XSLT che produca un output testuale estremamente banale è quello riportato nell'Esempio 15.


<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="2.0">

    <xsl:output method="text" />
    
    <xsl:template match="books">
        <xsl:text>Libri:&#xa;</xsl:text>
        <xsl:apply-templates select="book" />
    </xsl:template>
    
    <xsl:template match="book">
        <xsl:value-of select="title"/>, di <xsl:value-of select="author"/><xsl:text>&#xa;</xsl:text>
    </xsl:template>
    
</xsl:stylesheet>

Esempio 15 - Foglio di trasformazione XSLT per la conversione in testo semplice


L'applicazione di tale foglio XSLT al documento dell'Esempio 12 produce quanto mostrato nell'Esempio 16.


Libri:
Miliardi di Tappeti di Capelli, di Andreas Eschbach
I Pilastri della Terra, di Ken Follett

Esempio 16 - Risultato della trasformazione in testo semplice


In base alle esigenze, si può dunque progettare il foglio di trasformazione più adatto.

XSLT, in questo contesto, si può considerare un caso limite per la soluzione del problema, poiché, anche utilizzandolo con un editor adeguato, richiede comunque delle competenze che generalmente esulano da quelle di un designer, per la realizzazione di un sito Web, o da quelle di un tipografo, per l'impaginazione di un libro. Inoltre, in aggiunta al fatto di dover apprendere l'utilizzo di un software per svolgere compiti più avanzati, sia il designer Web che il tipografo dovrebbero comprendere anche il funzionamento di un linguaggio di programmazione, quale è XSLT. JMC, invece, lascia la piena libertà all'utilizzatore di sfruttare editor appartenenti alla propria area di competenze, così da non dover apprendere il funzionamento di strumenti nuovi.

2.3.2 XML Publisher

XML Publisher (!XPu08]) è un'applicazione, collocata nel più ampio IDE Stylus Studio, che si propone come un editor per l'elaborazione di documenti XML. Consente di creare layout avanzati per ottenere prodotti finali quali HTML, PDF, Postscript ed altri formati, utilizzando XSLT 1.0, XSLT 2.0 e XQuery 1.0. Il tutto è realizzabile da un'interfaccia grafica che semplifica il lavoro dell'utente, nascondendo i dettagli delle tecnologie utilizzate.

Per comprenderne immediatamente il funzionamento si osservi la Figura 12: sulla destra è rappresentato il documento XML dei contenuti sotto forma di albero; alla sua sinistra è stata creata una composta "trascinando" gli elementi del documento XML nelle opportune celle. Infine, in basso, è mostrato il risultato della trasformazione in formato HTML.


Esempio di utilizzo di Stylus Studio XML Publisher

Figura 12 - Esempio di utilizzo di Stylus Studio XML Publisher


Pur essendo un sistema integrato complesso e versatile, si è comunque vincolati allo stesso per la creazione del layout, a differenza di JMC, che ne consente lo sviluppo tramite un software noto all'utente. Inoltre, XML Publisher è un software proprietario a codice sorgente chiuso.

2.3.3 ISA*

Modello

ISA ( [Vit03] ) è un'applicazione concepita al fine di semplificare e velocizzare la creazione di siti Web. I contenuti devono essere scritti tramite l'applicativo Microsoft Word e l'autore deve specificare il ruolo di ciascuna porzione di testo definendola attraverso gli stili di testo. Il layout può essere sviluppato indipendentemente da un designer Web e l'applicativo, sfruttando l'associazione tra i nomi degli stili definiti nel testo e quelli specificati nel layout, produce un documento XSLT che applica la formattazione ai contenuti generati per mezzo di Word.

Per quanto riguarda la produzione dei layout è necessario utilizzare editor grafici che supportino la funzionalità definita slicing, che consente di delimitare aree dell'immagine. Come risultato, si ottiene un file HTML contenente una tabella che presenta in ogni cella una porzione dell'immagine selezionata. Tale meccanismo è supportato dagli editor più diffusi, quali Jasc Paint Shop Pro, Adobe Photoshop, Inkscape ed altri.

ISA* è un'architettura che generalizza il modello di ISA adattandolo ad altri ambiti, quali, ad esempio, l'e-learning e la produzione di documenti professionali.

La Figura 13 mostra concettualmente l'architettura di ISA*: le componenti di un documento vengono separate le une dalle altre, elaborate singolarmente e riassemblate per ottenere il risultato finale. Tali operazioni avvengono tramite convertitori bidirezionali per i formati desiderati.


Architettura di ISA*

Figura 13 - Architettura di ISA*


La necessità di segmentare i documenti e di utilizzare un formato di dati comune ai diversi convertitori ha portato a sviluppare rispettivamente, un modello, il Pentaformato e un linguaggio, IML. L'elaborazione complessiva dei documenti può essere suddivisa in due fasi principali, come illustrato nella Figura 13, che consistono nell'estrazione del contenuto e nella sua formattazione.

Pentaformato

La separazione tra le differenti parti di un documento avviene secondo un modello a cinque componenti (dimensioni), denominato Pentaformato e definito in [Dii07]. Queste ultime sono:

  • contenuto: le informazioni puramente testuali presenti nel documento;
  • struttura: l'organizzazione logica dei contenuti tramite elementi che forniscono un significato semantico del loro ruolo (paragrafi, titoli, contenitori, ecc.);
  • presentazione: gli elementi che conferiscono al puro testo caratteristiche visive tali da renderlo maggiormente accattivante e fruibile dai lettori;
  • comportamento: le componenti dinamiche presenti nel documento, dal più semplice link al più complesso script, che consentono una migliore interazione;
  • metadati: le informazioni che descrivono il documento stesso, quali l'autore o la data di pubblicazione e che permettono di mettere in relazione documenti tra di loro, indicizzarli e gestirli in contesti più ampi.

Tale modello è stato scelto poiché è applicabile a qualsiasi documento e permette di lavorare separatamente su ciascuna componente risultante dalla segmentazione.

IML

IML (Intermediate Markup Language, [Dii07]) è il linguaggio intermedio utilizzato come input ed output in tutti i passaggi di dati nelle varie conversioni effettuate nell'ambito dell'architettura di ISA*.

IML è fondamentalmente un sottoinsieme di XHTML, costituito da un numero limitato di elementi e di attributi che consentono di caratterizzarli ulteriormente, realizzando un meccanismo generale e flessibile tramite il quale è possibile modellare un qualsiasi contenuto.

Lo scopo di tale linguaggio è di esprimere unicamente contenuto strutturato, senza alcuna caratteristica presentazionale, né, tampoco, informazioni riguardanti metadati o comportamenti dinamici dei contenuti. Di conseguenza, un documento IML è un insieme di oggetti che specificano il ruolo di ciascun componente del documento (ad es., i blocchi di testo, i contenuti inline, i contenitori, le tabelle, e così via).

Estrazione del contenuto

La prima fase consiste nell'estrarre il contenuto dal documento sorgente e convertirlo in IML per poterlo rendere compatibile con i convertitori di ISA*. Tale fase consta di tre passaggi: pre-parsing, post-parsing ed analisi del contenuto.

Pre-parsing

In questa fase preliminare, fortemente dipendente dal formato dei dati considerati, il documento sorgente viene convertito in XML (nel caso non adotti già tale formato) in modo tale da potersi adattare all'architettura di ISA*, la quale è naturalmente basata su convertitori che utilizzano esclusivamente XML.

Post-parsing

Questa fase ha lo scopo di eliminare dal documento XML, risultante dalla fase precedente, tutti quegli elementi che non serviranno nella successiva fase di segmentazione: ad esempio, ricomporre linee in paragrafi (nei documenti PDF), rimuovere versioni alternative di una stessa immagine (nei documenti Word), e così via. Anche questa fase è strettamente dipendente dai formati dei documenti presi in considerazione.

Analisi del contenuto

In questa fase gli elementi presenti nel documento XML, epurato precedentemente, sono decorati da attributi che specificano se il loro ruolo è di contenuto, presentazione, comportamento o metadati. Tale obiettivo è raggiunto applicando euristiche espresse come regole di conversione in un meta-foglio di stile XSLT, in modo tale da renderne flessibile la modifica e l'ampliamento.

Formattazione

Nella seconda macro-fase dell'architettura di ISA* i contenuti, opportunamente segmentati, necessitano di essere formattati per ottenere il documento nel formato finale richiesto.

Le due parti di cui si compone tale fase riguardano la application logic e il rendering.

Application logic

In base alle necessità dell'applicazione stessa, questa fase può svolgere i compiti più diversi, ovvero:

  • convertire un documento in un altro formato;
  • modificare più o meno radicalmente la formattazione di un documento sostituendo, sostanzialmente, la dimensione riguardante la presentazione;
  • sostituire la dimensione del contenuto con un'altra in modo da riutilizzare la presentazione per creare un nuovo documento simile a quello originale;
  • analizzare la dimensione della struttura per filtrare alcune tipologie di contenuti, quali, per esempio, le pubblicità in un sito Web;
  • aggiungere alla dimensione dei metadati degli elementi tali da rendere il documento compatibile con altre applicazioni.

Rendering

Quest'ultima fase è sostanzialmente simmetrica rispetto alla prima, in quanto il documento IML restituito dall'application logic deve essere convertito in formato XML ed eventualmente nei formati binari voluti. Tali compiti sono assolti rispettivamente da fogli di stile XSLT e da convertitori specifici che trasformano il documento XML in formati binari.

In questa fase è previsto l'utilizzo di applicazioni esterne e strettamente legate ai formati, così da poter creare prodotti d'alta qualità. Tuttavia, talora, può essere necessario modificare tali applicativi per ottenere i risultati desiderati.

Sintassi di ISA

Quanto segue è la sintassi di ISA come descritta in [Ven04].

Gli elementi proposti sfruttano in maniera "impropria" due attributi del tag (X)HTML <a> e due di <img>: rispettivamente, href, target, name e alt.

Questa scelta è stata dettata dal fatto che gli editor esistenti, oltre ovviamente ad offrire la possibilità di associare ad ogni singola slice (che altro non è se non un elemento <img>) un link ipertestuale, presentano form che consentono di modificare complessivamente soltanto quegli attributi. È così possibile definire aree attive del layout, nel quale andranno inseriti i contenuti testuali.

Tipologie di aree

In questa sezione sono presentate le aree definibili attraverso editor grafici che supportano la funzionalità di slicing, mostrando il significato che devono assumere gli attributi elencati precedentemente.

fvblock

L'area fvblock è utilizzata per inserire nel layout qualsiasi tipo di contenuto, vedi testo semplice, immagini, tabelle, e così via.

Gli attributi dei tag <a> e <img> assumono i seguenti significati:

  • href: è da impostare al valore fvblock;

  • target: indica gli elementi che si vogliono includere, specificando eventualmente, tra parentesi tonde, il valore dell'attributo class associato agli stessi (ad esempio, div(citazione) fa riferimento a tutti gli elementi <div class="citazione"> ... </div>); il separatore da utilizzare per distinguere più elementi è la virgola;

  • alt: sfruttando la precedente sintassi, indica quali degli elementi contenuti in quelli specificati tramite l'attributo target non devono essere inclusi;

  • name: utilizzato per identificare l'elemento nel caso si voglia definire un'area di stretch relativa a questa zona.

Nell'Esempio 17 è presentato un possibile utilizzo dell'area fvblock.


Frammento iniziale:
    <p class="citazione">
        File deletion is <b>not</b> murder!
    </p>
    <p>
        (Un robot ribelle, Futurama, "2x14: Il Giorno della Mamma")
    </p>
    
Layout:    
    <td>
        <a href="fvblock" target="p(citazione)">
            <img src="pic.png" alt="b" />
        </a>
    </td>    
    
Risultato dell'applicazione del layout al frammento iniziale:
    <td background="pic.png">
        File deletion is murder!
    </td>

Esempio 17 - Utilizzo di fvblock


fvinclude

L'area fvinclude è utilizzata per inserire porzioni di documenti esterni o sotto-layout (ad esempio, bottoni di navigazione).

Gli attributi dei tag <a> e <img> assumono i seguenti significati:

  • href: fvinclude;

  • target: utilizzato per specificare il nome della proprietà di Word scelta dall'utente (ad esempio, header);

  • alt: utilizzato per specificare i possibili documenti alternativi da includere (ad esempio, header1.html, header2.html); il separatore di cui servirsi è la virgola.

Nell'Esempio 18 è mostrato il funzionamento dell'area fvinclude: dati i due header alternativi, se l'utente sceglie come valore della proprietà header impostata tramite Microsoft Word il valore header2.html ottiene il risultato mostrato.


Header alternativi:
    header1.html:
        <p>Header 1</p>

    header2.html:
        <p>Header 2</p>
        
Layout:
    <td>
        <a href="fvinclude" target="header">
            <img src="pic.png" alt="header1.html, header2.html" />
        </a>
    </td>

Risultato dell'applicazione del layout:
    <td background="pic.png">
        <p>Header 2</p>
    </td>

Esempio 18 - Utilizzo di fvinclude


fvstretch

L'area fvstretch è utilizzata per identificare zone contenenti immagini "liquide", ovvero immagini che si adattano, espandendosi in larghezza ed altezza, affinché il layout sia compatibile con la dimensione della finestra del browser.

fvstretch normale

Tale area permette di identificare una sola zona su cui effettuare lo stretching, senza riferimenti ad altre zone.

Gli attributi dei tag <a> e <img> assumono i significati:

  • href: fvstretch;

  • target: utilizzato per individuare le direzioni in cui effettuare lo stretching, può assumere solamente i valori h-100, v-100 o b-100, per indicare rispettivamente lo stretching orizzontale (horizontal), verticale (vertical) o in entrambe (both) le direzioni;

  • alt: non necessario.

fvstretch percentuale

Questa area permette di identificare più zone collegate su cui effettuare uno stretching in percentuale.

Gli attributi dei tag <a> e <img> assumono i seguenti significati:

  • href: fvstretch;

  • target: utilizzato per specificare le direzioni in cui effettuare lo stretching e la percentuale dello stesso associata all'elemento corrente (ad esempio, h-50 o v-25);

  • alt: usato per indicare i nomi (impostati tramite l'attributo name) di tutte le altre zone collegate; il separatore da utilizzare è la virgola;

  • name: utilizzato per assegnare un identificativo univoco alla zona.

Le zone alle quali applicare lo stretch percentuale devono essere scelte tenendo conto di due vincoli:

  • le zone devono essere all’interno di un’area in corrispondenza al blocco di testo che contiene il body;

  • se si utilizzano più zone nello stesso layout e nella stessa direzione, queste devono essere corrispondenti per quanto riguarda direzione e percentuale.

fvstretch relativo ad una zona di testo

L'ultima funzionalità dell'area fvstretch consiste nell'effettuare uno stretching relativo ad una zona di testo.

Gli attributi dei tag <a> e <img> assumono i seguenti significati:

  • href: fvstretch;

  • target: utilizzato per specificare le direzioni in cui effettuare lo stretching e la zona in base alla quale farlo, secondo la sintassi H-$fvblock o V-$fvblock, dove $fvblock è l'identificativo associato all'attributo name di un elemento fvblock (ad esempio, V-body o H-div);

  • alt: non necessario;

  • name: non necessario.

fvtile

L'area fvtile è utilizzata per identificare zone contenenti immagini "liquide", ovvero immagini che si adattano, effettuando un "piastrellamento" (tiling) della zona in cui sono contenute, affinché il layout sia compatibile con la dimensione della finestra del browser.

fvtile normale

Quest'area permette di identificare una sola zona su cui effettuare il tiling, ovvero senza possibili riferimenti ad altre zone.

Gli attributi dei tag <a> e <img> assumono i seguenti significati:

  • href: fvtile;

  • target: utilizzato per indicare le direzioni in cui effettuare il tiling, può assumere solamente i valori h-1 o v-1, per indicare rispettivamente il tiling orizzontale (horizontal) o verticale (vertical);

  • alt: non necessario.

fvtile percentuale

Tale area permette di identificare più zone collegate su cui effettuare un tiling in percentuale.

Gli attributi dei tag <a> e <img> assumono i seguenti significati:

  • href: fvtile;

  • target: utilizzato per specificare le direzioni in cui effettuare il tiling e la percentuale dello stesso associata all'elemento corrente (ad esempio, h-0.5 o v-0.7);

  • alt: utilizzato per indicare i nomi (impostati tramite l'attributo name) di tutte le altre zone collegate; il separatore da utilizzare è la virgola;

  • name: utilizzato per assegnare un identificativo univoco alla zona.

fvtile relativo ad una zona di testo

Quest'area permette di effettuare un tiling relativo ad una zona di testo.

Gli attributi dei tag <a> e <img> assumono i seguenti significati:

  • href: fvtile;

  • target: utilizzato per specificare le direzioni in cui effettuare il tiling e la zona in base alla quale farlo, secondo la sintassi H-$fvblock o V-$fvblock, dove $fvblock è l'identificativo associato all'attributo name di un elemento fvblock (ad esempio, V-body o H-div);

  • alt: non necessario;

  • name: non necessario.

Elementi per layout statici

La sintassi descritta precedentemente consente ad un designer Web di costruire un layout senza alcuna conoscenza di linguaggi di markup e solamente tramite l'utilizzo di un editor grafico. Tuttavia, chi conosce i linguaggi di markup può sviluppare direttamente pagine più elaborate utilizzando gli elementi illustrati nelle seguenti sezioni.

<fvblock>

L'elemento <fvblock> ha le stesse funzionalità dell'area fvblock. Gli attributi associati sono:

  • tag: utilizzato per indicare la zona del documento da includere. Se si vogliono selezionare elementi in modo globale si deve anteporre il prefisso "//" al percorso; se si vuole che la ricerca degli elementi avvenga localmente al contesto in cui ci si trova, non occorre il prefisso;

  • repeat: se presente ed impostato a yes, porta alla copia anche dell'elemento in questione e dei suoi attributi;

  • name: utilizzato per distinguere l'elemento da eventuali figli.

<fvexclude>

L'elemento <fvexclude> ha lo scopo di eliminare una porzione del contenuto visualizzato. Gli attributi associati sono:

  • tag: indica la zona del documento da escludere;

  • name: distingue l'elemento da eventuali figli.

<fvcontent>

L'elemento <fvcontent> deve essere necessariamente figlio di un elemento <fvblock> e serve ad ottenere il valore di una proprietà impostata come metadato tramite l'editor. Gli attributi associati sono:

  • tag: indica il nome della proprietà;

  • repeat: se presente ed impostato a yes, porta alla copia anche dell'elemento che presenta tale attributo; tuttavia, non può essere utilizzato se l'elemento <fvblock> che lo contiene ha tale attributo già impostato.

XPath

Per quanto riguarda la tipologia di area fvblock e gli elementi per layout statici <fvblock> e <fvexclude> è stata definita una sintassi semplificata di XPath per identificare gli elementi da includere o da escludere.

Tuttavia, si vuole lasciare agli utenti più esperti la possibilità di utilizzare le piene potenzialità di XPath.

XPath semplificato

Questa sintassi prevede la possibilità di identificare elementi in base al loro nome ed eventualmente restringendo la ricerca al valore dell'attributo class ad essi associato. Quest'ultimo va specificato tra parentesi tonde immediatamente dopo il nome dell'elemento: ad esempio, div(intestazione) si riferisce a tutti gli elementi <div class="intestazione" [...]> [...] </div>.

Come già accennato precedentemente, si dà la possibilità di specificare più elementi utilizzando come separatore la virgola.

Per poter selezionare in modo globale elementi del documento si deve anteporre al percorso il prefisso "//", altrimenti nulla se si vuole che la ricerca degli elementi avvenga localmente al contesto in cui ci si trova. Nell'Esempio 21 viene mostrato il risultato dell'applicazione del template dell'Esempio 20 al sorgente dell'Esempio 19. Come si può notare nell'esempio, occorre prestare attenzione all'utilizzo del contesto per evitare comportamenti indesiderati.


<div>
    <p>A</p>
</div>
<div class="utile">
    <h1>B</h1>
    <p>C</p>
</div>

Esempio 19 - XPath semplificato - Sorgente



<fvblock tag="//div(utile)">
    <div>
        <h1>
            <fvblock tag="h1" />
        </h1>
        <p>
            <fvblock tag="//p" />
        </p>
    </div>    
</fvblock>

Esempio 20 - XPath semplificato - Template



<div>
    <h1>
        B
    </h1>
    <p>
        AC
    </p>
</div>

Esempio 21 - XPath semplificato - Risultato dell'applicazione del template dell'Esempio 20 al sorgente dell'Esempio 19


XPath completo

Per la sintassi completa di XPath 2.0 si rimanda a [XPa07].

Al fine di distinguere la sintassi completa da quella semplificata è necessario anteporre ai percorsi il simbolo "#" (ad esempio, #//p[position()=last()]). In tal modo, ISA è in grado di utilizzare il pieno potere espressivo di XPath 2.0.

3 JMC

In questo capitolo è illustrato ad un livello generale il modello di JMC, JMC Meta-Converter, il software progettato e sviluppato nell'ambito di questa tesi.

3.1 Modello

L'idea fondamentale da cui si è partiti è quella di semplificare i processi di authoring multi-canale, consentendo agli utenti di agire su istanze di documenti piuttosto che su template complessi. Il compito di estrarre i template dai documenti è lasciato a JMC, riducendo la complessità dell'elaborazione.

Ciò consente, agli utenti coinvolti in un processo di sviluppo di un prodotto, di utilizzare al meglio le rispettive competenze, senza la necessità di intervenire nel lavoro altrui, la qual cosa richiede competenze ulteriori, o, peggio, l'impiego di persone con l'unico compito di fare da collante tra le differenti fasi di produzione.

In una situazione classica, un documento XML viene sottoposto ad una trasformazione XSLT per ottenere il documento finale, che sia in formato HTML, o comunque in un formato intermedio, quale XSL-FO, da cui si può ottenere, ad esempio, un file PDF. Quello che si vuole realizzare è il processo inverso, ovverosia, a partire da un'istanza di un documento in formato XML, estrapolare un file XSLT che applichi il layout di tale documento ad altre sorgenti di dati in formato XML.

Per realizzare tale obiettivo si è scelto di creare una relazione tra il documento di templating e il documento dei contenuti, così da stabilire una corrispondenza tra sotto-alberi e identificare in quale elemento del template debba essere trasformato l'elemento relativo nel documento che contiene i dati da formattare. Ciò si rende necessario poiché potenzialmente i due documenti possono essere di formati differenti. Ad esempio, è possibile che un template XSL-FO formatti dei dati presi da un file HTML; vien da sé che ciò non sarebbe attuabile senza identificare le opportune corrispondenze tra gli elementi dei due linguaggi.

3.1.1 Funzionalità

Considerando che gli editor che supportano lo slicing consentono di definire delle aree alle quali associare alcuni attributi, le funzionalità basilari supportate da JMC devono tenere conto di tale limitazione.

Di conseguenza, sono state identificate due tipologie di aree:

  • aree di testo: identificate successivamente come jblock, consentono di includere il testo presente nel documento dei contenuti, identificando gli elementi da inserire e quelli da escludere;
  • aree di inclusione: definite jinclude, servono ad inserire elementi di layout, definiti in file esterni, quali, ad esempio, parti fisse come menu, header o footer.

Per quanto riguarda la prima area, la corrispondenza tra il documento di templating e quello dei contenuti avviene sfruttando i nomi degli stili di formattazione del testo di Microsoft Word, mentre l'inclusione di ulteriori elementi di layout avviene indicando il percorso del file che contiene la porzione di layout da copiare.

Le limitazioni di questo approccio sono insite nel fatto che il documento dei contenuti deve essere necessariamente esportato in formato HTML, in quanto non è possibile definire la conversione tra elementi di linguaggi differenti.

Quello descritto, definito successivamente come linguaggio embedded, è studiato per essere utilizzato da designer Web, ovvero da figure professionali che generalmente non hanno conoscenze relative al linguaggio HTML e, pertanto, deve essere gestibile tramite editor grafici.

Per consentire ad utenti con conoscenze più avanzate di creare layout più complessi e flessibili è stato progettato un linguaggio, definito full, il quale supporta i seguenti attributi ed elementi:

  • j:role: associato ad un elemento del documento di templating, consente di formattare i contenuti secondo il layout dell'elemento stesso, specificando come valore quello definito nel documento dei contenuti tramite gli stili di formattazione del testo;
  • j:roleTransf: utilizzato in modo analogo all'attributo precedente, serve a definire conversioni tra elementi di linguaggi differenti;
  • j:copy: consente di copiare elementi dal documento dei contenuti e, nel caso in cui sia utilizzato propriamente l'attributo j:roleTransf, porta ad una conversione automatica nel linguaggio del template;
  • j:exclude: utilizzato congiuntamente all'attributo j:copy, serve ad escludere elementi durante la copia stessa;
  • j:val: restituisce il valore ottenuto dalla valutazione di un'espressione XPath come corpo dell'elemento cui è associato;
  • j:if: attribuito ad un elemento, in base alla veridicità della condizione XPath specificata, determina se l'elemento stesso debba comparire o meno nell'output finale;
  • j:for: associato ad un elemento, porta alla ripetizione dello stesso per ogni elemento della sequenza specificata tramite un'espressione XPath. Inoltre, è necessario specificare tramite l'attributo j:val il valore da utilizzare dentro gli elementi ripetuti;
  • j:transform: permette di formattare i contenuti secondo un foglio di stile XSLT scritto ad hoc per l'elemento cui è associato;
  • <j:env>: elemento contenitore per gli elementi <j:var>;
  • <j:var>: elemento che serve a definire variabili utilizzabili nelle espressioni XPath impiegate per gli altri attributi descritti.

È importante sottolineare che, a differenza del linguaggio embedded, il linguaggio full permette di marcare elementi del documento di templating ovunque essi si trovino: la limitazione del linguaggio embedded è insita nella necessità di utilizzare un editor grafico che supporti lo slicing, il che consente di definire aree contigue, ma non annidate una nell'altra.

Nella Sezione 4.1 sono descritti approfonditamente gli elementi e gli attributi elencati, con l'aggiunta di esempi chiarificatori. La logica di funzionamento di JMC nella versione pensata per utenti inesperti, ovvero tale da prevedere l'utilizzo del linguaggio embedded, è mostrata nella Figura 14.


Funzionamento di JMC nella versione semplificata

Figura 14 - Funzionamento di JMC nella versione semplificata


La differenza fondamentale di quest'ultima, rispetto alla versione che utilizza il linguaggio full, consiste nel fatto che può essere utilizzato un qualsiasi linguaggio XML per definire i documenti di templating e dei contenuti.

3.1.2 Documento di templating

Come è già stato affermato più volte, il documento di templating deve essere un file XML: questa non è una limitazione, poiché gli editor più noti ed utilizzati generalmente consentono di esportare in tale formato. Per poter marcare gli elementi dei template sono stati progettati due linguaggi: uno che può essere utilizzato direttamente dagli editor e rivolto a chi non ha particolari conoscenze del linguaggio ospite ed uno più espressivo, adoperabile agendo direttamente sul codice sorgente del template, destinato agli utenti più esperti.

Tali linguaggi, rispettivamente definiti full e embedded sono descritti successivamente nella sezione Sezione 4.1.2 e nella Sezione 4.1.3.

Mentre per il linguaggio full è sufficiente utilizzare un qualsiasi editor, anche semplicemente testuale, poiché si suppone adoperato da utenti esperti, per il linguaggio embedded sono stati identificati elementi ed attributi dei linguaggi ospite che siano gestibili da editor grafici. In particolare, nella Sezione 4.2 sono esaminati alcuni software adatti a tale scopo ed è mostrato come inserire tale sintassi all'interno dei documenti di templating.

Nel caso in cui si utilizzi il linguaggio embedded, il documento di templating risultante è necessariamente un file HTML, considerando l'uso di editor che permettono di effettuare lo slicing restituendo un documento HTML contenente una tabella di layout. Diversamente, adoperare il linguaggio full rende possibile marcare un qualsiasi documento in formato XML ottenendo, come risultato dell'elaborazione effettuata da JMC, un template che applica il layout di tale documento.

3.1.3 Documento dei contenuti

Il documento dei contenuti deve anch'esso essere in formato XML per potersi elaborare tramite fogli di stile XSLT. Analogamente a quanto detto per il documento di templating, gli editor possono generalmente produrre una versione XML tra i vari formati d'esportazione. Si pensi, ad esempio, all'editor forse più utilizzato per la scrittura di documenti, cioè Microsoft Word.

Come per il documento di templating, è necessario decorare opportunamente anche i documenti dei contenuti. Nella Sezione 4.1.1 sono identificati, per i formati presi in esame, gli attributi da inserire nei documenti dei contenuti e nella Sezione 4.2.2 è illustrato come utilizzare degli editor grafici per associarli ai documenti stessi.

Nel caso ci si serva per il documento di templating del linguaggio embedded, ottenendo dunque un template che restituisca un documento HTML senza la possibilità di conversione tra elementi appartenenti a formati differenti, il documento dei contenuti deve essere in formato HTML. Utilizzando, invece, il linguaggio full è possibile valersi di un documento dei contenuti in qualsiasi formato, a patto di associarvi gli opportuni attributi ed esportarlo in formato XML.

3.2 Modalità di utilizzo

Il prototipo di JMC si presenta come un insieme di file XSLT, di file XML di configurazione e di esecuzione e di una libreria per attuare le trasformazioni. I dettagli sono discussi in seguito, mentre ora si vuole dare un'idea dell'utilizzo pratico da parte degli utenti.

Si consideri come scenario la produzione di una pagina Web, processo nel quale, per semplicità, siano coinvolti un designer Web e un autore che stabilisca i contenuti. Considerando che si vuole utilizzare il linguaggio embedded, i documenti di templating e dei contenuti devono essere in formato HTML. Ciò non significa che debbano essere prodotti direttamente in tale formato, ma, come è spiegato in seguito, è sufficiente che i software utilizzati possano esportare in quel linguaggio.

Innanzitutto, il designer Web e l'autore devono concordare i valori degli attributi da assegnare agli elementi del documento di templating e del documento dei contenuti, in modo da consentire a JMC di effettuare le opportune trasformazioni per estrarre il template ed utilizzarlo per la formattazione dei dati.

A questo punto, essi possono lavorare indipendentemente e parallelamente alle due parti del progetto. Prendendo in esame la parte spettante al designer, questi può ricercare un documento che presenti un layout già adatto allo scopo, come quello riportato nella Figura 15.


Versione originale della pagina da utilizzare come template

Figura 15 - Versione originale della pagina da utilizzare come template


Se necessario, tramite un editor grafico il layout può essere modificato a piacere per adattarlo meglio alle esigenze specifiche. In questo caso, sono stati eliminati tutti i contenuti variabili ed effettuate modifiche minori, mantenendo il layout desiderato, come da Figura 16


Adattamento del template alle esigenze del designer

Figura 16 - Adattamento del template alle esigenze del designer


Ora è necessario impiegare la funzione di slicing offerta dal software di grafica adottato, in questo caso Adobe Photoshop. Come si può osservare nella Figura 17, sono state individuate cinque aree, aventi i seguenti significati:

  1. header della pagina;
  2. menu principale;
  3. separazione tra il menu ed il resto della pagina, irrilevante per questo esempio;
  4. menu di secondo livello;
  5. corpo della pagina.


Risultato dello slicing sul documento di templating

Figura 17 - Risultato dello slicing sul documento di templating


Sfruttando la finestra di dialogo, tramite la quale impostare le proprietà relative ad ogni singola slice, è possibile inserire la sintassi embedded di JMC. Nella Figura 18 è mostrato il caso specifico della slice relativa al corpo della pagina.


Introduzione della sintassi embedded nella slice relativa al corpo della pagina

Figura 18 - Introduzione della sintassi embedded nella slice relativa al corpo della pagina


Una volta esportata l'immagine suddivisa in slice in formato HTML, il codice relativo a tale slice risulta essere quello riportato nell'Esempio 22


<td>
    <a href="jblock" target="p(jmcUtilizzoTitolo), p(jmcUtilizzo)">
        <img src="area5-corpo.gif" width="762" height="545" border="0" alt="">
    </a>
</td>

Esempio 22 - Codice relativo alla slice definita per il corpo della pagina


Parallelamente, l'autore dei contenuti deve preoccuparsi di associare gli opportuni attributi concordati inizialmente con il designer utilizzando gli stili di testo forniti da Microsoft Word. Nella Figura 19 si può osservare la lista degli stili di default e dei due definiti dall'utente, jmcUtilizzo e jmcUtilizzoTitolo, e l'applicazione degli stessi al testo. In particolare, è esplicitamente indicata l'associazione tra il primo ed il testo selezionato.


Utilizzo degli stili di testo in Microsoft Word

Figura 19 - Utilizzo degli stili di testo in Microsoft Word


Esportando il documento Word in formato HTML, dopo un'opportuna ed inevitabile pulizia del codice stesso al fine di renderlo ben-formato rispetto alla sintassi XML, si ottiene quanto mostrato nell'Esempio 23.


<p class="jmcUtilizzoTitolo">
    <span>Modalità di utilizzo</span>
</p>

<p class="jmcUtilizzo">
    Il prototipo di JMC si presenta come un insieme di file XSLT, alcuni file XML di configurazione e di esecuzione 
    e delle librerie per attuare le trasformazioni. I dettagli verranno discussi in seguito, 
    mentre ora si vuole dare un'idea dell'utilizzo pratico da parte degli utenti.
</p>

Esempio 23 - Porzione del documento Word convertito in formato HTML


Completate in parallelo da designer e autore le due fasi, è il momento di utilizzare JMC. Tramite un file di configurazione bisogna specificare i percorsi dei documenti di templating e dei contenuti, così come del template da estrarre e del documento finale che si vuole produrre. Eseguendo un'istruzione da riga di comando si ottiene il template ed il file risultante dalla formattazione del documento dei contenuti secondo il layout del documento di templating. Come possibile sviluppo futuro, quest'ultima operazione può essere resa ancora più semplice creando un'interfaccia grafica che consenta di selezionare i file ed eseguire il processo in modo più agevole ed intuitivo. Per proseguire con l'esempio, alle altre zone del template devono essere associate le opportune aree jblock e jinclude; allo stesso modo devono essere prodotti i relativi contenuti rispettando i valori degli attributi concordati. Come si può intuire, la formattazione del testo non può essere dedotta dall'immagine iniziale utilizzata come template, ma è necessario creare dei fogli di stile CSS a mano o utilizzando un documento Microsoft Word con gli opportuni stili.


Risultato dell'applicazione del layout ai contenuti tramite JMC

Figura 20 - Risultato dell'applicazione del layout ai contenuti tramite JMC


In seguito all'utilizzo di JMC, una possibile pagina Web finale è rappresentata nella Figura 20.

Evidentemente, oltre ad avere ottenuto un documento finale formattato, si ha anche il template relativo a tale trasformazione, il quale può essere riutilizzato su qualsiasi altro documento di contenuti marcato con gli opportuni attributi.

3.3 Pregi e difetti

I vantaggi apportati da JMC, già presentati in ordine sparso come migliorie rispetto alle tecnologie e ai software illustrati nel Capitolo 2, sono qui riassunti per punti:

  • templating generale ed estendibile: l'idea che sta alla base di JMC è quella di proporre un modello di templating che non sia limitato ad un particolare linguaggio ospite, ma utilizzabile per estrarre template da un qualsiasi documento basato su di una sintassi XML;
  • creazione dei contenuti: i contenuti possono essere generati utilizzando qualsiasi editor che supporti nativamente XML o possa esportare il documento in tale formato;
  • conversione tra formati: JMC consente di creare una corrispondenza tra gli elementi presenti nel template e quelli nel documento dei contenuti; ciò permette di avere formati differenti tra template e contenuti, a patto di usare la sintassi full;
  • vasto supporto degli editor: JMC è stato progettato per consentire agli utenti di utilizzare editor diffusi e noti, sia per quanto riguarda la fase di creazione dei contenuti, sia per l'estrazione e la generazione di template che applichino caratteristiche di formattazione ai contenuti stessi; in particolare, sono state individuate caratteristiche comuni agli editor analizzati e che, con molta probabilità, dovrebbero essere supportate da editor analoghi;
  • utilizzo di strumenti open source: non necessariamente implicito nelle affermazioni del punto precedente è il fatto che JMC, non basandosi su formati proprietari, non necessita dell'utilizzo di strumenti proprietari per la creazione di template o di contenuti; nulla ne vieta, naturalmente, l'utilizzo, a patto che l'output degli stessi sia in formato XML;
  • separazione dei ruoli: JMC consente di separare nettamente la produzione dei template da quella dei contenuti, in modo tale da sfruttare al meglio le competenze degli specialisti dei vari settori, piuttosto che accentrare il lavoro su un'unica figura professionale;
  • utenza differenziata: JMC prevede l'utilizzo di due linguaggi, l'embedded (utilizzabile per mezzo di editor WYSIWYG noti e diffusi), per venire incontro agli utenti meno esperti e il full, maggiormente espressivo e rivolto ad utenti esperti (utilizzabile anch'esso tramite eventuali funzionalità avanzate di editor specifici per i vari linguaggi ospite o direttamente agendo sul codice sorgente degli stessi);
  • portabilità: poiché l'esecuzione di JMC è gestita tramite Apache Ant, il quale sfrutta librerie per le trasformazioni XSLT scritte in Java, JMC può essere utilizzato su un qualsiasi sistema operativo su cui sia possibile installare Java.

Per quanto riguarda le limitazioni, si può osservare come il solo utilizzo di un editor grafico non consenta di ottenere layout complessi. È, infatti, possibile definire solamente aree contigue e non vi è modo di creare aree che risultino nel documento finale annidate le une nelle altre.

Inoltre, la fase di associazione degli stili al testo nel documento finale stesso, può essere attuata creando un documento CSS a mano o tramite la definizione di stili di formattazione in un documento Microsoft Word, successivamente trasformato con meccanismi già definiti in ISA. Nel primo caso sono richieste competenze circa l'utilizzo di fogli di stile CSS, le quali esulano dalle conoscenze di un designer Web, mentre nel secondo caso può risultare abbastanza scomodo ed oneroso in termini di tempo definire stili, senza poterli provare in tempo reale. Infine, non vi è modo di definire con la sola sintassi embedded corrispondenze tra elementi di linguaggi differenti, pertanto i documenti dei contenuti devono essere convertiti in formato HTML per poter essere inclusi dentro ad un layout tabellare HTML.

4 JMC: linguaggi ed implementazione

È arrivato dunque il momento di descrivere dettagliatamente la progettazione e l'implementazione di JMC. In particolare, nella Sezione 4.1 sono descritti i linguaggi da impiegare nei documenti di templating e dei contenuti; successivamente, nella Sezione 4.2, sono proposti degli editor tramite i quali inserire la sintassi embedded e decorare i documenti dei contenuti. Infine, è descritta dettagliatamente l'implementazione, con riferimenti ai file principali del software JMC e al flusso di esecuzione tipico dello stesso.

4.1 Contenuti, linguaggi embedded e full

In questo capitolo è illustrato come marcare opportunamente il documento dei contenuti e sono proposte due versioni del linguaggio da associare al documento di templating: una embedded, tramite la quale sia possibile decorare gli elementi del linguaggio ospite mediante attributi dello stesso namespace, e una full, indipendente dal linguaggio ospite.

4.1.1 Documento dei contenuti

Così come nella Sezione 4.2 sono stati presi in considerazione linguaggi basati su XML per i template, parimenti i documenti dei contenuti dovranno rispettare la sintassi XML, ovvero essere, quantomeno, "ben formati" (well-formed), secondo i vincoli definiti in [XML06]. Per citare quelli più importanti:

  • il documento deve presentare un unico elemento radice (root element), che contenga tutti gli altri elementi. Esternamente ad esso possono essere presenti solamente white space, commenti (<!-- ... -->), processing instructions (<? ... ?>) o la dichiarazione del DOCTYPE (<!DOCTYPE ... >);
  • XML è case sensitive, quindi i tag di apertura e chiusura devono corrispondere quanto a maiuscole e minuscole (in particolare, è il tag di apertura di un elemento ad imporre il nome su quello di chiusura);
  • ogni elemento deve avere un tag di chiusura o, nel caso in cui sia un elemento vuoto, è possibile utilizzare la sintassi abbreviata;
  • gli elementi devono essere ben annidati, ovvero i tag di chiusura devono comparire nell'ordine inverso rispetto a quello dei corrispondenti tag di apertura;
  • i valori degli attributi associati agli elementi devono essere racchiusi tra apici singoli o doppi, naturalmente utilizzando lo stesso tipo per lo stesso attributo;
  • i caratteri speciali < e & devono essere sostituiti dalle rispettive entità &lt; e &amp;.

Rispettando tale sintassi, è possibile trasformare il documento utilizzando un template XSLT in modo da estrarne opportunamente i contenuti e formattarli in base al template stesso.

Individuazione dei contenuti

Considerando che i documenti dei contenuti possono essere di formati differenti, è stato necessario individuare per ogni formato gli attributi, appartenenti al namespace del linguaggio in esame, più consoni ad identificare gli elementi da formattare. La scelta è stata guidata principalmente da due criteri:

  • gli attributi devono essere associabili a tutti gli elementi di interesse;
  • gli attributi devono poter essere impostabili tramite editor WYSIWYG.

In questo contesto, si intende utilizzare detti attributi per creare un riferimento esplicito tra gli elementi del documento dei contenuti e quelli del template marcati con gli attributi j:role e j:roleTransf, per la cui descrizione si rimanda alla Sezione 4.1.2. L'attributo scelto deve assumere come valore una singola stringa.

Linguaggio (X)HTML

Analizzando le specifiche del linguaggio HTML ( [HTM99] ) e, in particolare, il relativo DTD (http://www.w3.org/TR/html401/sgml/dtd.html), è stato individuato l'attributo class, il quale può essere associato praticamente a tutti gli elementi del linguaggio ed è normalmente supportato dagli editor.

Linguaggio XSL-FO

Dalle specifiche del linguaggio XSL ( [XSL06] ), con riferimento particolare a XSL-FO e ad un suo DTD non ufficiale, [Gri02], si è giunti ad identificare l'attributo id.

4.1.2 Linguaggio full

Il linguaggio full, pur essendo anch'esso inserito all'interno del linguaggio ospite, diversamente da quello embedded appartiene ad un namespace differente ed è indipendente dal linguaggio ospite. In particolare, il namespace da utilizzare per il linguaggio full è http://www.jhack.it/2008/JMC.

Notazioni

Le notazioni, abbastanza formali, che saranno utilizzate nel definire il linguaggio sono le seguenti:

  • attributi:
    • attribute?: indica che l'attributo denominato attribute è opzionale;

  • valori assunti dagli attributi:
    • string: indica una qualsiasi sequenza alfanumerica;
    • number: indica un numero;
    • boolean: indica un valore booleano;
    • uri: indica un URI, relativo o assoluto;
    • any: indica un qualsiasi tipo di valore tra quelli suddetti;
    • expr ( type ): indica un'espressione XPath 2.0 che, in seguito alla valutazione, restituisca il tipo di dato "type"; il tipo può essere omesso;
    • "string": indica che l'attributo deve assumere come valore esattamente la stringa "string";
    • { "A" | 1 | expr ( boolean ) }: indica che l'attributo deve assumere come valore uno tra quelli specificati tra le parentesi graffe; in questo esempio, la stringa "A", il valore numerico 1 o un'espressione XPath che restituisca un valore booleano.

Operatori

Poiché le espressioni utilizzate sono XPath (in versione semplificata o completa) possono essere utilizzati tutti gli operatori definiti in [XQu07].

Attributi

In questa sezione sono illustrati gli attributi che possono essere associati ad elementi del linguaggio ospite. Per quanto possibile, si è cercato di rimanere sulle generali, svincolandosi da un particolare linguaggio ospite (ad esempio, la radice di un documento è denominata root, un elemento generico element, e così via). Anche nel caso in cui gli esempi risultino più chiari, esplicitando elementi o attributi di un particolare linguaggio, si consideri comunque che il discorso è valido per tutti i linguaggi ospite considerati. Si sottintende il prefisso del namespace dichiarato come xmlns:j="http://www.jhack.it/2008/JMC".

Priorità

Poiché il linguaggio è quasi esclusivamente basato su attributi e non vi è un ordine di valutazione implicito, come potrebbe essere quello indotto dall'annidamento degli elementi in un linguaggio basato su elementi, si è scelto di considerarli nell'ordine in cui compaiono. Tuttavia, poiché diverse combinazioni di attributi hanno un significato univoco, a prescindere dalla collocazione degli stessi, è stata definita una priorità di valutazione, secondo la quale gli attributi sono ordinati prima di essere valutati. Così facendo, l'utente non deve necessariamente ricordare un ordine particolare, ma solamente quei pochi casi che sono ambigui di natura.

Le priorità degli attributi sono le seguenti:


Attributo Priorità
j:role 3
j:if 2
j:for 2
j:copy 1
j:exclude 1
j:include 1
j:roleTransf 1
j:transform 1
j:val 1

Tabella 1 - Priorità degli attributi


Da quanto detto precedentemente, le due forme presentate nell'Esempio 24 sono equivalenti, poiché costituite da attributi di priorità differente. Infatti, una volta riordinati gli attributi secondo i valori delle priorità, si ottiene il medesimo risultato.


Due elementi che presentano i medesimi attributi in ordine diverso:
    <element j:if="..." j:role="..." j:transform="..."> [...] </element>
    <element j:role="..." j:transform="..." j:if="..."> [...] </element>

Risultato del riordinamento in base alle priorità:
    <element j:role="..." j:if="..." j:transform="..."> [...] </element>

Esempio 24 - Riordinamento degli attributi di priorità diverse


Diversamente, gli attributi con priorità uguali mantengono la stessa posizione relativa rispetto a quelli di pari valore, consentendo all'utente di specificare esplicitamente la precedenza di uno rispetto all'altro. Come si può osservare nell'Esempio 25, si ottengono due risultati nettamente differenti.


Primo caso con la relativa conversione in XSLT:
    <element j:role="..." j:if="..." j:for="..." j:val="..."> [...] </element>
    
    <xsl:template match="...">
        <xsl:if test="...">
            <xsl:for-each select="...">
                [...]
            </xsl:for-each>
        </xsl:if>
    </xsl:template>

Secondo caso:
    <element j:role="..." j:for="..." j:if="..." j:val="..."> [...] </element>
    
    <xsl:template match="...">
        <xsl:for-each select="...">
            <xsl:if test="...">
                [...]
            </xsl:if>
        </xsl:for-each>
    </xsl:template>

Esempio 25 - Risultati differenti per attributi di priorità differenti


j:role

L'attributo j:role rappresenta un legame esplicito tra il template e il documento sorgente da formattare. Può essere associato agli elementi del linguaggio ospite per i quali si vuole creare un template che applichi la formattazione definita da essi. Il valore dell'attributo j:role deve corrispondere a quello associato all'attributo designato per il linguaggio del documento dei contenuti. Ad esempio, è stato scelto l'attributo class per il formato (X)HTML.

<element 
    j:role = string >
    [...]
</element>

Nel caso in cui tale attributo sia utilizzato da solo, viene creato un template che copi gli attributi, come nell'Esempio 26.


Linguaggio ospite con attributo j:role:
    <element class="red" j:role="important">
        [...]
    </element>

Risultato della trasformazione in XSL:
    <xsl:template match="node()[@class='important']">
      <element class="red">
         <xsl:apply-templates />
      </element>
    </xsl:template>

Esempio 26 - Attributo j:role - Modalità di utilizzo


j:roleTransf

L'attributo j:roleTransf è necessario nel momento in cui il template utilizzato debba restituire un documento di formato differente rispetto a quello dei contenuti. Infatti, tutti gli elementi non marcati con l'attributo j:role porterebbero, in alcuni casi, alla sola copia del contenuto testuale ed in altri alla copia di elementi del linguaggio del documento dei contenuti; nella prima situazione verrebbe generato comunque un documento sintatticamente e semanticamente corretto, mentre nella seconda si avrebbero dei comportamenti imprevedibili a causa della presenza di elementi non appartenenti al linguaggio di destinazione.

<element 
    j:roleTransf = string ("global")? >
    [...]
</element>

Come già descritto per l'attributo j:role, il valore di j:roleTransf deve avere un corrispondente nel documento dei contenuti per poter stabilire a quale elemento debba corrispondere quello marcato nel template. Si è scelto di utilizzare lo stesso attributo designato per j:role, definito per ogni linguaggio del documento dei contenuti.

La procedura descritta finora consente di creare una relazione tra elementi che siano esplicitamente marcati nel documento dei contenuti. Ma ciò costringerebbe a decorare ogni singolo elemento, compito inutilmente dispendioso. Per questo è possibile affiancare al valore dell'attributo j:roleTransf già presente, la parola chiave global. Così facendo, il template risultante non cattura solo gli elementi del documento dei contenuti che hanno l'attributo corrispondente a quello specificato con j:roleTransf, ma direttamente gli elementi stessi.

Per meglio comprendere quanto detto, si osservi l'Esempio 27, dove è mostrato l'utilizzo di j:roleTransf con e senza il valore global.


Linguaggio ospite con attributo j:roleTransf:
    <span j:roleTransf="grassetto" style="font-weight: bold">
        Inline grassetto
    </span>
    <span j:roleTransf="inline global">
        Inline generico
    </span>

Documento dei contenuti:
    <fo:inline id="grassetto"> [...] </fo:inline>
    <fo:inline id="inline"> [...] </fo:inline>.

Risultato della trasformazione:
    <xsl:template match="fo:inline[some $x in tokenize(@id, '\s+') satisfies ($x = 'grassetto')]" mode="#default">
        <span style="font-weight: bold">
            <xsl:apply-templates mode="#default"/>
        </span>
    </xsl:template>
       
    <xsl:template match="fo:inline" mode="#default">
        <span>
            <xsl:apply-templates mode="#default"/>
        </span>
    </xsl:template>

Esempio 27 - Attributo j:roleTransf - Modalità di utilizzo con un template (X)HTML che formatta un documento FO


j:copy

L'attributo j:copy ha due ruoli nettamente differenti in base ai valori specificati. Può essere associato agli elementi del linguaggio ospite per i quali si vuole che essi o il loro contenuto vengano copiati così come sono nel documento risultante o per creare in quest'ultimo dei template che copino elementi presenti nel documento da formattare. Nel primo caso i valori da utilizzare sono esclusivamente i seguenti:

  • #cc: carbon copy, copia l'elemento (comprensivo dei suoi figli, a qualsiasi profondità) e i suoi attributi, senza alcuna modifica;
  • -#cc: copia tutti i figli dell'elemento, a qualsiasi profondità;
  • #text: copia l'elemento e tutti i nodi testo, figli di primo livello;
  • -#text: copia tutti i nodi testo, figli di primo livello;
  • #deeptext: copia l'elemento e tutti i nodi testo, a qualsiasi profondità;
  • -#deeptext: copia tutti i nodi testo, a qualsiasi profondità.

Nel secondo caso, il valore da specificare nell'attributo è un XPath semplificato o completo, naturalmente riferito agli elementi presenti nel documento da formattare. Come per i valori statici specificati precedentemente, anteponendo il carattere "-" all'espressione XPath si evita la copia dell'elemento contenente l'attributo stesso. Per poter eliminare elementi figli (a qualsiasi profondità) rispetto a quelli identificati dall'espressione XPath specificata è possibile utilizzare l'attributo j:exclude.

<element 
    j:copy = { "(-)?#cc" | "(-)?#text" | "(-)?#deeptext" | (-)?expr } 
    (j:exclude = expr [, expr]*)?
    >
    [...]
</element>

Nell'Esempio 28 sono riportati alcune possibilità di utilizzo.


Linguaggio ospite con attributo j:copy (per i valore di $cp ed $ex si guardino i risultati delle trasformazioni):
    <element class="red" j:copy="$cp" j:exclude="$ex">
        File deletion is <b>non</b> murder! 
    </element>

Risultato della trasformazione con: 

$cp="#cc" 
    <element class="red">
        File deletion is <b>non</b> murder! 
    </element>

$cp="-#cc" 
    File deletion is <b>non</b> murder! 
    
$cp="#text" 
    <element class="red">
        File deletion is murder! 
    </element>

$cp="-#text" 
    File deletion is murder! 
    
$cp="#deeptext" 
    <element class="red">
        File deletion is not murder! 
    </element>

$cp="-#deeptext" 
    File deletion is not murder!
    
$cp="#cc" / $ex="b"
    <element class="red">
        File deletion is murder! 
    </element>

Esempio 28 - Attributo j:copy - Esempi di utilizzo


j:exclude

L'attributo j:exclude, necessariamente affiancato dall'attributo j:copy, serve ad escludere dalla copia elementi specificati dall'espressione XPath di quest'ultimo. Il valore dell'attributo deve essere una sequenza di una o più espressioni XPath semplificate o complete ed il separatore da utilizzare è la virgola.

<element 
    j:copy = expr 
    j:exclude = expr [, expr]* >
    [...]
</element>

Un possibile utilizzo è già stato mostrato nell'Esempio 28.

j:val

L'attributo j:val può essere associato agli elementi del linguaggio ospite per i quali si vuole che il contenuto sia sostituito dal valore risultante dalla valutazione di un'espressione XPath.

<element 
    j:val = expr >
    [...]
</element>

Nell'Esempio 29 sono riportati alcuni possibili utilizzi.


Linguaggio ospite con attributo j:val (per il valore di $expr si guardino i risultati delle trasformazioni):
    <element j:val="$expr">
        [...] 
    </element>

Risultato della trasformazione con:
    $expr="1+5 * 8+1" 
        <element>
            <xsl:value-of select="1+5 * 8+1"/>
        </element>

    $expr="concat(//*[@class='titolo'], ' ', //*[@class='sottotitolo'])"
        <element>
            <xsl:value-of select="concat(//*[@class='titolo'], ' ', //*[@class='sottotitolo'])"/>
        </element>

Esempio 29 - Attributo j:val - Esempi di utilizzo


Come si può osservare, anche se nel primo caso si sarebbe potuto restituire direttamente <element>42</element>, tale considerazione non si può generalizzare, poiché, come è evidenziato dal secondo caso, la valutazione dell'espressione potrebbe necessitare di informazioni presenti solo nel contesto del documento da formattare.

j:if

L'attributo j:if può essere associato agli elementi del linguaggio ospite che si vuole siano essi stessi, e i propri discendenti, restituiti o meno in seguito alla valutazione di un'espressione XPath che abbia come risultato un valore booleano.

<element 
    j:if = expr(boolean) >
    [...]
</element>

Il generico utilizzo è riportato nell'Esempio 30.


Linguaggio ospite con attributo j:if:
    <element j:if="$expr"> [...] </element>

Risultato della trasformazione:
    <xsl:if test="$expr">
        <element>
            [...]
        </element>
    </xsl>

Esempio 30 - Attributo j:if - Modalità di utilizzo


j:for

L'attributo j:for può essere associato agli elementi del linguaggio ospite per i quali si vuole che vengano ripetuti una volta per ogni elemento della sequenza specificata tramite un'espressione XPath. È inoltre necessario definire tramite l'attributo j:val il valore da utilizzare dentro agli elementi ripetuti.

<element 
    j:for = string " in " expr 
    j:val = expr >
    [...]
</element>

Nell'Esempio 31 è riportato un possibile utilizzo.


Documento sorgente cui si fa riferimento:
    <div class="elenco">
        <div class="authors">
            <div class="author">
                <div class="personname">
                    <p class="name">Arthur</p>
                    <p class="surname">Clarke</p>
                </div>
            </div>
            <div class="author">
                <div class="personname">
                    <p class="name">Lester</p>
                    <p class="surname">del Rey</p>
                </div>
            </div>
        </div>
    </div>

Linguaggio ospite con attributo j:for:
    <element j:role="elenco">
        <element2 j:for="autore in [...]/div[@class='elenco']/div[@class='authors']/div[@class='author']" 
                  j:val="autore/div[@class='personname']/p[@class='name']" 
                  j:role="nomi">
                  [...]
        </element2>
    </element>

Risultato della trasformazione:
    <xsl:template match="node()[@class='elenco']">
        <element>
            <xsl:call-template name="nomi"/>
        </element>
    </xsl:template>
    <xsl:template name="nomi">
        <xsl:for-each select="[...]/div[@class='elenco2']/div[@class='authors']/div[@class='author']">
            <element2>
               <xsl:value-of select="./div[@class='personname']/p[@class='surname']"/>
            </element2>
        </xsl:for-each>
    <xsl:template>

Esempio 31 - Attributo j:for - Modalità di utilizzo


j:transform

L'attributo j:transform può essere utilizzato per associare ad un elemento un foglio di stile XSLT al fine di applicare una trasformazione specifica all'elemento stesso. In questo modo è possibile includere nel foglio di stile XSLT trasformazioni che hanno priorità su quelle eventualmente già presenti, poiché richiamate tramite <apply-imports />.

<element 
    j:transform = uri >
    [...]
</element>

Nell'Esempio 32 è riportato un possibile utilizzo.


Linguaggio ospite con attributo j:transform:
    <element j:role="elementTransf" j:transform="elementTransf.xsl">
        [...]
    </element>

Risultato della trasformazione:
    <xsl:import href="tableTransf.xsl"/>
    [...]
    <xsl:template match="node()[@class='elementTransf']">
        <xsl:apply-imports />
    </xsl:template>

Esempio 32 - Attributo j:transform - Modalità di utilizzo


j:include

L'attributo j:include può essere utilizzato per inserire, come figlio dell'elemento cui è associato tale attributo, il contenuto del file XML specificato come valore dell'attributo stesso.

<element 
    j:include = uri >
    [...]
</element>

Nell'Esempio 33 è riportato un possibile utilizzo.


Linguaggio ospite con attributo j:include:
    <div j:include="menu.html">
        [...]
    </div>

Contenuto del file "menu.html":
    <ul>
        <li><a href="/home">Home</a></li>
        <li><a href="/archivio">Archivio</a></li>
        <li><a href="/contatti">Contatti</a></li>
    </ul>
    
Output finale:
    <div>
        <ul>
            <li><a href="/home">Home</a></li>
            <li><a href="/archivio">Archivio</a></li>
            <li><a href="/contatti">Contatti</a></li>
        </ul>
    </div>

Esempio 33 - Attributo j:include - Modalità di utilizzo


Elementi

In questa sezione sono illustrati gli elementi che possono essere utilizzati all'interno del linguaggio ospite.

<j:env>

L'elemento <j:env>, se necessario, deve essere utilizzato per racchiudere uno o più elementi <j:var>, descritti nella sezione successiva. Può comparire una volta sola nel documento di template e se ne consiglia la collocazione come primo elemento figlio della radice.

<root>
    <j:env>
        <!-- Content = (j:var)+ -->
    </j:env>
    [...]
</root>

<j:var>

L'elemento <j:var> può servire a specificare una variabile ed il relativo valore. Esso deve comparire all'interno dell'elemento <j:env>, precedentemente descritto. Al fine di utilizzare il valore della variabile in un'espressione è sufficiente preporre al suo nome il simbolo $.

<j:var
    name = string
    val = any />

Nell'Esempio 34 è riportato un possibile utilizzo.


Linguaggio ospite con elemento var:
    <root>
        <j:env>
            <j:var name="media" val="'print'" />
        </j:env>    
    
        <element j:if="$media='print'"/>
            [...]
        </element>
    </root>

Risultato della trasformazione:
    <xsl:variable name="media" select="'print'" />
    [...]
    <xsl:if test="$media='print'">
        <element>
            [...]
        </element>
    </xsl>

Esempio 34 - Elemento j:var - Modalità di utilizzo


4.1.3 Linguaggio embedded

Con il termine embedded si vuole indicare la sintassi che sfrutta elementi ed attributi del linguaggio ospite, generalmente in modo non convenzionale, per introdurre costrutti di templating.

Poiché l'introduzione di tale sintassi è da attuare tramite editor grafici che supportino la funzionalità di slicing, si è proceduto in modo analogo a quanto già realizzato nell'ambito di ISA.

Ciò comporta l'utilizzo degli elementi <a> e <img> e di alcuni attributi relativi ad essi, impostabili tramite le finestre di dialogo offerte dagli editor grafici stessi.

In particolare, si vogliono definire due tipi di aree: una che consenta di inserire le parti del documento dei contenuti desiderate, siano esse testo semplice, elenchi, tabelle, e così via, ed una che serva ad includere ulteriori elementi di layout o contenuti, quali menu o altri elementi fissi.

jblock

Tramite l'area jblock è possibile specificare quali elementi del documento dei contenuti prendere in considerazione per ottenere il documento finale. Gli attributi degli elementi <a> e <img> della slice relativa assumono i seguenti significati:

  • a/@href: deve assumere il valore jblock e serve a distinguere l'area;
  • a/@target: indica gli elementi che si vogliono includere, e, grazie alla versione semplificata di XPath già descritta riguardo ad ISA, è possibile specificare la classe HTML associata agli stessi (ad esempio, p(link) fa riferimento a tutti gli elementi <p class="link"> ... </p>); per elencare più elementi è sufficiente utilizzare come separatore la virgola;
  • img/@alt: sfruttando la sintassi appena descritta, permette di specificare elementi da escludere tra i possibili figli di quelli definiti tramite l'attributo precedente.

Per maggior chiarezza si veda l'Esempio 35.


Slice ottenuta dal documento di templating:
    <td>                    
        <a href="jblock" target="p(citazioneImportante)">
            <img alt="p(autore)" [...] />
        </a>                        
    </td>

Documento dei contenuti:
    <p class="citazioneImportante">
        Non ottenere ciò che si vuole, a volte, è un magnifico colpo di fortuna.
        <p class="autore">(Dalai Lama)</p>
    </p>
    <p>
        C'è un solo sistema per determinare se un animale è intelligente oppure no: sezionargli il cervello!
        <p class="autore">(Prof. Hubert J. Farnsworth)</p>
    </p>

Trasformazione del template in sintassi full:
    <td j:copy="p[@class='citazioneImportante']" j:exclude="p[@class='autore']" [...] />
    
Risultato dell'applicazione del template generato da JMC al documento dei contenuti:
    <td>
        <p class="citazioneImportante">
            Non ottenere ciò che si vuole, a volte, è un magnifico colpo di fortuna.
        </p>        
    </td>

Esempio 35 - Area jblock - Modalità di utilizzo


Come si può osservare, delle due citazioni viene presa in considerazione solo la prima poiché ha il valore dell'attributo class richiesto e, di questa, viene ignorato l'autore, così come indicato tramite l'attributo alt.

jinclude

L'area jinclude serve ad inserire elementi presenti in file esterni e può essere utilizzata per parti fisse di un documento, quali header, footer e menu di un sito Web. Gli attributi dell'elemento <a> della slice relativa assumono i seguenti significati:

  • a/@href: deve assumere il valore jinclude e serve a distinguere l'area;
  • a/@target: indica il percorso del documento di cui includere il contenuto.

L'Esempio 36 mostra l'utilizzo di questo tipo di area.


Slice ottenuta dal documento di templating:
    <td>                    
        <a href="jinclude" target="header.html">
            <img [...] />
        </a>                        
    </td>

Contenuto del file header.html:
    <div>
        <h1>Blog ad Improbabilità Infinita</h1>
        <h2>L’unico blog che può trasformarvi in una balena o in un vaso di petunie</h2>
    </div>

Trasformazione del template in sintassi full:
    <td j:include="header.html" />
    
Risultato dell'applicazione del template generato da JMC al documento dei contenuti:
    <td>
        <div>
            <h1>Blog ad Improbabilità Infinita</h1>
            <h2>L’unico blog che può trasformarvi in una balena o in un vaso di petunie</h2>
        </div>   
    </td>

Esempio 36 - Area jinclude - Modalità di utilizzo


4.2 Linguaggi ospite ed editor

Il metodo più efficace per evitare che gli utenti debbano preoccuparsi di agire direttamente sul codice sorgente dei documenti consiste nell'identificare degli applicativi già ampiamente conosciuti e facilmente utilizzabili, senza particolari conoscenze tecniche. In questo capitolo ne sono stati analizzati i più diffusi, al fine di individuare le caratteristiche che li possano rendere utili a tale scopo. Tale discorso vale per l'introduzione della sintassi embedded, la quale richiede editor noti a designer Web e ad autori di contenuti.

Per quanto riguarda la sintassi full, è sufficiente un qualsiasi editor che consenta, tramite interfaccia grafica, di inserire elementi ed attributi non appartenenti al linguaggio ospite o che permetta di agire direttamente sul codice sorgente. In entrambi i casi si suppone che l'utilizzatore sia un utente esperto del linguaggio XML, così come della particolare istanza del linguaggio ospite.

4.2.1 Editor per documenti di templating

Nelle sezioni che seguono sono brevemente analizzati editor che consentono di esportare layout nell'unico formato di interesse per utenti che utilizzano il solo linguaggio embedded, ovvero HTML. Sono solo alcuni esempi ed è molto probabile che qualsiasi altro editor analogo possa portare ai medesimi risultati, ovvero consentire di effettuare lo slicing, che si ricorda essere la capacità di definire graficamente delle aree di un'immagine ed esportare un documento HTML contenente un layout tabellare.

Adobe Photoshop

Adobe Photoshop CS4 ( [Pho08] ) è forse il software professionale per immagini bitmap più utilizzato in ambito professionale ed è disponibile per i sistemi operativi Apple Mac OS X e Microsoft Windows.

La definizione di slice può essere effettuata utilizzando lo strumento Slice, accessibile dalla barra degli strumenti. Una volta create le slice, si può impiegare lo strumento Slice Select per associare attributi ad ogni singola slice. Essa stessa è rappresentata da un elemento <img>, al quale è possibile aggiungere un collegamento ipertestuale. I valori utili allo scopo sono:

  • Name: attributo id dell'elemento <img> associato alla slice e il nome del file con cui è salvata;
  • URL: attributo href dell'elemento <a>;
  • Target: attributo target dell'elemento <a>;
  • Alt: attributo alt dell'elemento <img>.

Definita una slice come in Figura 21, il codice relativo risultante dal salvataggio in formato HTML del layout tabellare corrispondente, la quale operazione è attuabile dalla finestra di dialogo raggiungibile da File > Save for Web & Devices, è mostrato nell'Esempio 37.


Definizione degli attributi associati ad una slice in Adobe Photoshop CS4

Figura 21 - Definizione degli attributi associati ad una slice in Adobe Photoshop CS4



<html>
    [...]
    <body>
        <table>
            <tr>
                <td>
                    <a href="jURL" target="jTarget">
                        <img id="jName" src="jName.png" alt="jAlt" [...] />
                    </a>
                </td>
                [...]
            </tr>
            [...]
        </table>
    </body>
</html>

Esempio 37 - Codice relativo alla slice definita nella Figura 21


Adobe Illustrator

Adobe Illustrator CS4 ( [Ill08] ) è la controparte di Adobe Photoshop per la realizzazione di grafica vettoriale ed è anch'esso un editor commerciale disponibile per i sistemi operativi Apple Mac OS X e Microsoft Windows.

La definizione di slice può essere effettuata in maniera assolutamente equivalente a quella descritta a proposito dell'applicativo Adobe Photoshop, poiché entrambi i software si basano sullo stesso meccanismo di slicing. Non volendo ripetere il medesimo esempio, si rimanda alla sezione dedicata ad Adobe Photoshop.

Adobe Fireworks

Adobe Fireworks CS4 ( [Fir08] ) è un editor commerciale per l'elaborazione di siti Web che consente di gestire sia grafica bitmap che vettoriale ed è sviluppato sia per il sistema operativo Apple Mac OS X che per Microsoft Windows.

La definizione di slice avviene attraverso lo strumento Slice tool presente nella barra degli strumenti nella sezione Web. Gli attributi utilizzati sono:

  • Slice: attributi id e name dell'elemento <img> associato alla slice e il nome del file con cui è salvata;
  • Link: attributo href dell'elemento <a>;
  • Alt: attributo alt dell'elemento <img>;
  • Target: attributo target dell'elemento <a>.

La slice rappresentata nella Figura 22 porta alla produzione del codice HTML presente nell'Esempio 38, esportando il file tramite la finestra di dialogo raggiungibile da File > Export.


Definizione degli attributi associati ad una slice in Fireworks CS4

Figura 22 - Definizione degli attributi associati ad una slice in Fireworks CS4



<html>
    [...]
    <body>
        <table>
            <tr>
                <td>
                    <a href="jLink" target="jTarget">
                        <img name="jSlice" src="jSlice.gif" id="jSlice" alt="jAlt" [...] />
                    </a>
                </td>
                [...]
            </tr>
            [...]
        </table>
    </body>
</html>

Esempio 38 - Codice relativo alla slice definita nella Figura 22


Image Cut

Image Cut ( [Ima08] ) è un editor commerciale che attua unicamente lo slicing su immagini create tramite altri software.


Definizione degli attributi associati ad una slice in Image Cut

Figura 23 - Definizione degli attributi associati ad una slice in Image Cut


La Figura 23 mostra come associare i valori opportuni alle slice e l'Esempio 39 mostra il codice HTML risultante dall'estrazione delle slice.


<html>
    <body>
        <table>
            <tr>
                <td>
                    <a target="jTarget" href="jURL">
                        <img src="images/jName.png" alt="jAlt" [...] >
                    </a>
                </td>
            </tr>
        </table>
    </body>
</html>

Esempio 39 - Codice relativo alla slice definita nella Figura 23


4.2.2 Editor per la creazione di contenuti

In questa sezione è proposto l'utilizzo di alcuni editor per la produzione di contenuti e spiegato come utilizzarli al fine di identificare le porzioni di testo da elaborare per mezzo di JMC.

Microsoft Word

Microsoft Word ( [Wor08] ) è molto probabilmente l'editor commerciale più utilizzato per la produzione di documenti, pertanto è necessario analizzare come si possano marcare i documenti creati con esso. Quella presentata è la versione per Apple Mac OS X, ma il discorso vale anche per la corrispondente versione per Microsoft Windows.

La scelta più naturale per contrassegnare il testo è quella di utilizzare gli stili di formattazione. È infatti possibile crearne di nuovi tramite la finestra di dialogo mostrata nella Figura 24, accessibile dal menu "Format > Style...".


Creazione di un nuovo stile in Microsoft Word per Mac

Figura 24 - Creazione di un nuovo stile in Microsoft Word per Mac


Il valore definito come nome dello stile deve corrispondere a quello del relativo attributo j:role o j:roleTransf definiti nel documento di templating. Nella figura precedente è stato creato lo stile InlineGrassetto.

Esportando il documento in formato HTML, i nomi degli stili vengono associati agli attributi class delle porzioni di testo cui sono stati assegnati gli stili stessi. È opportuno sottolineare come il formato HTML utilizzato da Microsoft Word sia ben lontano dall'essere ben-formato, pertanto è necessario trasformarlo opportunamente, compito già svolto da ISA. Poiché generalmente ogni editor non prettamente HTML, che esporti in tale formato, adopera una propria sintassi, non si può garantire che sia direttamente compatibile con JMC, ma probabilmente bisogna attuare una pulizia del codice mirata a renderlo utilizzabile.

OpenOffice*

Come controparte open source, si è preso in esame OpenOffice ( [Ope08] ), una suite di programmi, utilizzabile con i principali sistemi operativi, che comprende OpenOffice Writer, un word processor di larga diffusione e di capacità paragonabili a quelle di Microsoft Word.


Creazione di un nuovo stile in OpenOffice

Figura 25 - Creazione di un nuovo stile in OpenOffice


Come risulta chiaro dalla Figura 25 è possibile creare nuovi stili da associare al testo, caratteristica sufficiente per l'utilizzo successivo del documento con JMC.

Esportando un documento decorato con tali stili in formato (X)HTML si ottiene davvero un documento (X)HTML ben-formato, contrariamente al risultato raggiungibile con Microsoft Word. Analogamente a quest'ultimo editor, i nomi degli stili vengono assegnati agli attributi class delle porzioni di testo cui sono associati.

Adobe Dreamweaver

Adobe Dreamweaver CS4 ( [Dre08] ) è una soluzione commerciale per la produzione di siti Web. Considerando che tale software serve proprio a creare codice HTML, l'associazione degli opportuni valori alle porzioni di testo, che devono corrispondere ai relativi elementi del documento di templating (marcati con j:role o j:roleTransf), risulta immediata utilizzando l'attributo class. La finestra di dialogo che consente tale azione è riportata nella Figura 26.


Associazione di un attributo class ad un elemento con Adobe Dreamweaver

Figura 26 - Associazione di un attributo class ad un elemento con Adobe Dreamweaver


Ciò non toglie che si possa adoperare un qualsiasi altro editor HTML, poiché sicuramente tutti supportano l'attributo class.

4.3 Implementazione di JMC

Come è già stato in precedenza sottolineato, l'implementazione di JMC è stata realizzata tramite fogli di stile XSLT, scelta naturale conseguente all'utilizzo di documenti XML come template e come sorgenti di dati.

I file/directory principali che costituiscono l'applicazione JMC sono:

  • JMC.xsl: è il cuore dell'applicazione e contiene il codice che consente l'estrazione del template, ovvero trasforma il documento di templating, già decorato con la sintassi full, in un foglio di trasformazione XSLT che applica il layout del template stesso;
  • JMCconf.xml: contiene i parametri di configurazione di JMC;
  • jValidation.xsl: fornisce funzioni per la validazione degli attributi del linguaggio full;
  • emb2full.xsl: attua la trasformazione da linguaggio embedded a full;
  • build.xml: script Ant che gestisce i diversi passaggi delle trasformazioni;
  • build.properties.xml: file di configurazione per lo script build.xml, utilizzato per indicare i file coinvolti nelle trasformazioni;
  • lib/*.jar: librerie utilizzate dallo script Ant principalmente per le trasformazioni XSLT. In particolare, la libreria utilizzata per queste ultime è Saxon-B 9.1 (http://saxon.sourceforge.net/).

4.3.1 Ant e il flusso di esecuzione

Cos'è Ant?

Apache Ant (Another Neat Tool, [Ant08]), è uno strumento open source, scritto in linguaggio Java, creato principalmente per gestire i processi di compilazione di progetti Java. Tuttavia, presenta caratteristiche che lo rendono utilizzabile in contesti differenti. La scelta di servirsene è dovuta alle seguenti caratteristiche:

  • essendo scritto in Java, risulta naturalmente platform-independent. In particolare, ridefinisce le tipologie dei comandi più comuni strettamente dipendenti dai sistemi operativi e permette di utilizzare per i percorsi dei file lo slash e il backslash, gestendo l'opportuna conversione in base al sistema operativo su cui viene eseguito lo script;
  • il formato in cui sono scritti gli script eseguiti da Ant e i relativi file di configurazione è XML; ciò facilita sia la loro scrittura che la loro lettura;
  • gli script Ant sono strutturati con dei target che possono richiamarsi a vicenda grazie ad un sistema di dipendenze e definiscono al loro interno i task da eseguire; ciò consente, oltre ad organizzare in modo chiaro l'esecuzione, di richiamare specifici target senza modificare in alcun modo il codice;
  • è possibile estenderne le capacità scrivendo delle classi Java che implementino le funzionalità volute;
  • è un progetto open source.

Il file di configurazione, da utilizzare per specificare i percorsi dei documenti che prendono parte al processo di estrazione del template e di applicazione del layout dello stesso al documento dei contenuti, è strutturato come nell'Esempio 40.


<conf>
    <workingDir>templates/html/prova</workingDir>
    <srcTemplatePath>template.html</srcTemplatePath>
    <srcDocPath>sourceDoc.html</srcDocPath>
    <srcTemplateFullPath>templateFull.html</srcTemplateFullPath>
    <resTemplatePath>templateExtracted.xsl</resTemplatePath>    
    <resDocPath>resDoc.html</resDocPath>
    </body>
</conf>

Esempio 40 - Ant - Esempio di file di configurazione


Gli elementi di tale file hanno il seguente significato:

  • workingDir: percorso assoluto, o relativo rispetto all'applicativo JMC, della directory contenente i file coinvolti nelle trasformazioni; da ciò deriva che i percorsi dei file specificati tramite i successivi elementi debbano essere relativi a tale directory;
  • srcTemplatePath: documento di templating dal quale deve essere estratto il template;
  • srcDocPath: documento dei contenuti da formattare secondo il template;
  • srcTemplateFullPath: documento di templating risultante dalla trasformazione dall'eventuale linguaggio embedded al relativo linguaggio full;
  • resTemplatePath: documento di trasformazione XSLT che applica il layout del documento di templating;
  • resDocPath: documento risultante dall'applicazione del suddetto foglio di stile al documento dei contenuti.

Nell'esempio precedente, dunque, si tratta di un template derivato da un documento HTML, template.html, che applica la formattazione ad un altro documento HTML, sourceDoc.html, ottenendo come documento finale resDoc.html.

Flusso di esecuzione

Come si è detto, l'esecuzione è gestita da target Ant eseguiti secondo un'opportuna logica di dipendenze. Essi sono:

  • all: è il target di default eseguito nel caso in cui lo script Ant venga richiamato senza indicare un target specifico; dipendendo dagli altri target, esegue l'intero processo di estrazione del template e di applicazione al documento dei contenuti;
  • init: inizializza le variabili interne e quelle specificate nel file di configurazione;
  • clean: rimuove i file temporanei;
  • emb2full: attua la trasformazione del documento di templating da linguaggio embedded a full;
  • full2template: porta all'estrazione del template dal documento di templating;
  • applyTemplate: formatta il documento dei contenuti in base al template estratto.

Per eseguire l'intero processo è sufficiente lanciare da riga di comando l'istruzione ant, supponendo di trovarsi nella directory principale di JMC e supponendo altresì che lo script Ant abbia come nome del file esattamente build.xml. Nel caso lo si rinominasse, sarebbe necessario specificare il nome del file tramite l'opzione -f, quindi, ad esempio, ant -f JMC.xml.

Se si volesse eseguire un target specifico, piuttosto che quello di default, sarebbe sufficiente indicare il nome di tale target come ultimo parametro passato al comando: ad esempio, per applicare un template già estratto precedentemente, il comando da lanciare sarebbe ant applyTemplate.

4.3.2 File in dettaglio

In questa sezione sono illustrati più in dettaglio i file principali che compongono l'applicativo JMC, in modo tale da giustificare le scelte progettuali più importanti.

JMCconf.xml

Il file JMCconf.xml contiene le configurazioni di JMC, riportate parzialmente nell'Esempio 41.


<conf>
    <variables>
        <variable name="JMCuri" value="http://www.jhack.it/2008/JMC" />
    </variables>    
    
    <validation>
        <debug>0</debug>
        <terminateOnFailure>0</terminateOnFailure>
    </validation>    
    
    <roleAttrMatch>
        <attribute if="html" then="class" />
        <attribute if="fo:root" then="id" />
    </roleAttrMatch>    
        
    <attributes>

        <priority>
            <attribute name="role" weight="3" />
            <attribute name="if" weight="2" /> 
            <attribute name="val" weight="1" />
            <!-- ... -->
        </priority>
        
        <required>
            <attribute name="exclude" requires="copy role" />
            <attribute name="if" requires="role" />
            <attribute name="role" requires="" />
            <!-- ... -->
        </required> 
        
        <conflicts>
            <attribute name="role" conflictsWith="" />
            <attribute name="if" conflictsWith="copy exclude" />
            <attribute name="val" conflictsWith="copy exclude transform" />
            <!-- ... -->
        </conflicts>
    
    </attributes>
</conf>

Esempio 41 - File di configurazione di JMC


In dettaglio, i parametri hanno i seguenti significati:

  • JMCuri: identifica il namespace utilizzato per gli elementi del linguaggio full;
  • validation/debug: indica se l'esecuzione della validazione degli attributi del linguaggio full essere verbosa (1) o meno (0);
  • validation/terminateOnFailure: nel caso la validazione non vada a buon fine è possibile terminare l'esecuzione (1) o proseguirla (0);
  • roleAttrMatch: è utilizzato per specificare, per ogni tipo di formato supportato (in questo caso HTML e XSL-FO), l'attributo utilizzato nel documento dei contenuti che ci si aspetta faccia match con gli elementi j:role e j:roleTransf del linguaggio full del documento di templating;
  • priority, required e conflicts: si riferiscono agli attributi del linguaggio full ed identificano per ogni attributo l'ordine di valutazione, gli eventuali altri attributi che devono necessariamente accompagnarlo e quelli con i quali eventualmente non deve comparire in riferimento ad uno stesso elemento.

jValidation.xsl

La validazione avviene rispetto agli attributi del linguaggio full, pertanto vengono identificati tutti gli elementi contenenti attributi appartenenti al namespace j="http://www.jhack.it/2008/JMC". Per ogni elemento viene dunque confrontato l'insieme degli attributi con le regole definite in JMCconf.xml, per verificare che non vi siano attributi che ne richiedano altri non presenti, o che ve ne siano di conflittuali.

Nel suddetto file di configurazione è possibile stabilire se l'eventuale presenza di errori debba causare la terminazione dell'intero processo o la sua prosecuzione.

emb2full.xsl

Questo foglio di stile guida la conversione del documento HTML, risultante dalle operazioni di slicing, dal linguaggio embedded a quello full, poiché il meta-convertitore lavora unicamente utilizzando quest'ultimo linguaggio.

Per comprendere il funzionamento del meccanismo, si osservi il codice XSLT presente nell'Esempio 42, che gestisce l'area jblock.


<xsl:template match="td[a/@href='jblock']">
    <td>
        <xsl:attribute name="valign" select="'top'" />
        <xsl:attribute name="background" select="a/img/@src" />
        
        <div>
            <xsl:attribute name="style" select="'position: relative;'" />
            
            <xsl:attribute name="j:copy" select="j:XPathSimple2Full(a/@target)" />
            
            <xsl:if test="a/img/@alt and normalize-space(a/img/@alt) != ''">
                <xsl:attribute name="j:exclude" select="j:XPathSimple2Full(a/img/@alt)" />
            </xsl:if>
        </div>
    </td>
</xsl:template>

Esempio 42 - Conversione di un'area jblock da linguaggio embedded a full


La conversione da XPath semplificato ad XPath vero e proprio è attuata tramite la funzione riportata nell'Esempio 43.


<xsl:function name="j:XPathSimple2Full">
    <xsl:param name="xpath" as="xs:string" />
    <xsl:choose>
        <xsl:when test="fn:matches($xpath, '^(\-|\+)?#')">
            <!-- Viene usato un XPath vero e proprio, pertanto lo si restituisce cosi' com'e' -->
            <xsl:value-of select="fn:replace($xpath, '^(\-|\+)?#(.*)', '$1$2')" />
        </xsl:when>
        <xsl:otherwise>
            <!-- La sintassi e' semplificata, quindi la si trasforma in un vero XPath -->
            <xsl:value-of select="fn:replace($xpath, '\(([^\)]*)\)', concat('[@class=', $singleQuote, '$1', $singleQuote, ']'))" />        
        </xsl:otherwise>
    </xsl:choose>        
</xsl:function>

Esempio 43 - Conversione da XPath semplificato ad XPath vero e proprio


JMC.xsl

Tale foglio di stile XSLT costituisce la componente principale dell'applicativo JMC, poiché realizza l'estrazione del template dal documento di templating, opportunamente marcato con la sintassi full (direttamente o come risultato della conversione dal linguaggio embedded).

Più precisamente, si tratta di un meta-foglio di stile XSLT, in quanto restituisce, a sua volta, un foglio di stile XSLT, il quale può essere utilizzato direttamente per formattare il documento dei contenuti.

Per poter gestire la conversione tra formati differenti, è necessario passare in fase di trasformazione (tramite il parametro srcDocPath) il percorso del documento dei contenuti da formattare. In tal modo, sfruttando l'attributo j:roleTransf, è possibile creare template che trasformino gli elementi del documento dei contenuti nei relativi elementi del linguaggio in cui è scritto il template.

Prima di procedere con l'estrazione del template, viene verificata la correttezza degli attributi del linguaggio full tramite una chiamata ad un template definito nel file jValidation.xsl. La valutazione degli attributi avviene come descritto nella Sezione 4.1.2: dopo essere stati ordinati secondo le priorità stabilite nel file di configurazione JMCconf.xml, sono valutati a partire da quello di priorità maggiore.

Successivamente, si procede con la creazione del foglio di stile XSLT da restituire come output, importando i documenti definiti con l'attributo j:transform e creando le variabili definite tramite j:var.

A questo punto vengono creati i template XSLT utili a catturare gli elementi del documento dei contenuti. Per meglio comprendere quanto segue, si propongono un semplice documento di templating in formato HTML e un documento dei contenuti in formato XSL-FO, riportati rispettivamente nell'Esempio 44 e nell'Esempio 45. Si tenga presente che, per brevità e chiarezza, sono stati omessi anche elementi fondamentali di tali linguaggi, lasciando solo quelli utili alla spiegazione.


<html>
    <body>
        <div><h1 j:role="titolo">Titolo</h1></div>    
        <h2 j:role="autore">Autore</h2>
        
        <div j:role="corpo">
            <div>
                <div j:role="incipit">Incipit <span j:roleTransf="inline global">inline generico</span></div>
            </div>
            
            Corpo
            <div j:role="testo"><span class="grassetto" j:roleTransf="grassetto">inline grassetto</span></div>
        </div>
    </body>
</html>

Esempio 44 - Documento di templating HTML, contenente la sintassi full



<fo:root>
    <fo:page-sequence>
        <fo:flow>
            <fo:block id="titolo">The Hitchhiker's Guide to the Galaxy</fo:block>
            <fo:block id="autore">Douglas Adams</fo:block>
            
            <fo:block id="corpo">
                <fo:block id="incipit">
                    Far out in the uncharted backwaters of the unfashionable end of the western spiral arm 
                    of the <fo:inline id="inline">Galaxy</fo:inline> lies a small unregarded <fo:inline>yellow sun</fo:inline>.
                </fo:block>
          
                <fo:block id="testo"><fo:inline role="grassetto" font-weight="bold">42</fo:inline>!</fo:block>
                
            </fo:block>
        </fo:flow>  
    </fo:page-sequence>
</fo:root>

Esempio 45 - Documento dei contenuti in formato XSL-FO


In una prima fase viene generata la struttura del layout: gli elementi del template sono copiati così come appaiono fino a raggiungere elementi contenenti la sintassi di JMC o nodi testo. In particolare, si vuole focalizzare l'attenzione sugli attributi j:role e j:roleTransf, poiché sono quelli che guidano la creazione dei template.

Si è parlato di nodi testo dal momento che il template può contenere sia parti statiche (marcate tramite l'attributo j:copy), che devono essere copiate nel documento finale a prescindere dal documento dei contenuti, e parti dinamiche, ovvero nodi testo normali, che si considerano come il risultato dell'elaborazione di nodi testo del documento dei contenuti e che portano alla creazione di istruzioni apply-templates.

Il risultato di questa prima fase è riportato nell'Esempio 46.


<xsl:template match="/">
    <html>
        <body>
            <div>
                <xsl:apply-templates select=".//*[@id = 'titolo']"/>
            </div>
            <xsl:apply-templates select=".//*[@id = 'autore' or @id = 'corpo']"/>
        </body>
    </html>
</xsl:template>

Esempio 46 - Estrazione della struttura del template


Come si può osservare in questo caso, è stato creato più di un apply-templates e, per evitare ovvie duplicazioni, è stato necessario utilizzare l'attributo select per catturare gli elementi opportuni.

Nella fase successiva sono valutati unicamente gli elementi appartenenti alla sintassi full di JMC per creare tutti i template che catturino gli elementi selezionati dai suddetti apply-templates, riportati nell'Esempio 47.


<xsl:template match="node()[@id='titolo']">
    <h1>
        <xsl:apply-templates/>
    </h1>
</xsl:template>
<xsl:template match="node()[@id='autore']">
    <h2>
        <xsl:apply-templates/>
    </h2>
</xsl:template>
<xsl:template match="node()[@id='corpo']">
    <div>
        <div>
            <xsl:apply-templates select=".//*[@id = 'incipit']"/>
        </div>
        <xsl:apply-templates select="text() | *[@id != 'incipit']"/>
    </div>
</xsl:template>
<xsl:template match="node()[@id='incipit']">
    <div>
        <xsl:apply-templates/>
    </div>
</xsl:template>
<xsl:template match="node()[@id='testo']">
    <div>
        <xsl:apply-templates/>
    </div>
</xsl:template>

Esempio 47 - Estrazione dei template dei singoli elementi


In particolare, si osservi il terzo template, relativo all'attributo "corpo". La creazione dello stesso segue la medesima logica della prima fase di estrazione della struttura del template.

Infine, vengono creati gli eventuali template di default per la conversione degli elementi propri del documento dei contenuti nei rispettivi elementi del linguaggio del template, prendendo in considerazione unicamente gli elementi marcati con l'attributo j:roleTransf. Come si può osservare nell'Esempio 48, l'utilizzo di global porta a due template nettamente differenti: per quanto riguarda il primo, specificare tale parola chiave crea un template che cattura qualsiasi elemento fo:inline, mentre il secondo solo quegli elementi fo:inline che contengono nell'attributo id la stringa "grassetto".


<xsl:template match="fo:inline" mode="#default">
    <span>
        <xsl:apply-templates mode="#default"/>
    </span>
</xsl:template>

<xsl:template match="fo:inline[some $x in tokenize(@id, '\s+') satisfies ($x = 'grassetto')]" mode="#default">
    <span class="grassetto">
        <xsl:apply-templates mode="#default"/>
    </span>
</xsl:template>

Esempio 48 - Template per la conversione di elementi tra linguaggi differenti


La necessità di accedere al documento dei contenuti, durante l'estrazione del template, è d'obbligo in questa fase, poiché non vi sarebbe alcun altro modo esplicito per attuare una conversione tra elementi di linguaggi differenti.

Il template completo è riportato nell'Esempio 49.


<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="2.0">
    <xsl:output method="xml" version="1.0" encoding="UTF-8" indent="yes"/>
   
    <xsl:template match="/">
        <html>
            <body>
                <div>
                    <xsl:apply-templates select=".//*[@id = 'titolo']"/>
                </div>
                <xsl:apply-templates select=".//*[@id = 'autore' or @id = 'corpo']"/>
            </body>
        </html>
    </xsl:template>
       
    <xsl:template match="node()[@id='titolo']">
        <h1>
            <xsl:apply-templates/>
        </h1>
    </xsl:template>
    <xsl:template match="node()[@id='autore']">
        <h2>
            <xsl:apply-templates/>
        </h2>
    </xsl:template>
    <xsl:template match="node()[@id='corpo']">
        <div>
            <div>
                <xsl:apply-templates select=".//*[@id = 'incipit']"/>
            </div>
            <xsl:apply-templates select="text() | *[@id != 'incipit']"/>
        </div>
    </xsl:template>
    <xsl:template match="node()[@id='incipit']">
        <div>
            <xsl:apply-templates/>
        </div>
    </xsl:template>
    <xsl:template match="node()[@id='testo']">
        <div>
            <xsl:apply-templates/>
        </div>
    </xsl:template>
    
    
    <xsl:template match="fo:inline" mode="#default">
        <span>
            <xsl:apply-templates mode="#default"/>
        </span>
    </xsl:template>
    <xsl:template match="fo:inline[some $x in tokenize(@id, '\s+') satisfies ($x = 'grassetto')]" mode="#default">
        <span class="grassetto">
            <xsl:apply-templates mode="#default"/>
        </span>
    </xsl:template>
</xsl:stylesheet>

Esempio 49 - Listato completo del template estratto


5 Conclusioni

Obiettivo della tesi è generalizzare la funzionalità di meta-conversione nell'ambito dell'architettura di ISA*, così da consentire l'estrazione di template a partire da qualunque documento di templating, marcato in modo opportuno.

ISA* è un'architettura nata dalla volontà di semplificare i processi di authoring di documenti di formati differenti, quali pagine Internet, libri cartacei o prodotti concernenti l'ambito dell'e-learning, ponendo un accento particolare sulla separazione tra produzione dei layout e sviluppo dei contenuti.

Correntemente, ISADesign, la versione di ISA* specializzata nella creazione di pagine Web, consente di creare i layout tramite editor grafici e i contenuti per mezzo di Microsoft Word, svolgendo il compito di fondere le due parti. Ciò avviene grazie ad un meta-foglio di stile XSLT, il quale trasforma il documento HTML, ottenuto in seguito all'utilizzo della funzionalità di slicing degli opportuni editor grafici, in un foglio di stile XSLT che, applicato al documento dei contenuti, porta alla creazione della pagina Web finale. Il modello di ISA è descritto nella Sezione 2.3.3.

Tale meccanismo può essere generalizzato per utilizzare qualsiasi documento in formato XML. Per valutare lo stato dell'arte della produzione di documenti, nell'ottica di un processo di sviluppo che tenga conto della separazione dei ruoli delle figure professionali coinvolte, sono state analizzate soluzioni software, presentandone nel Capitolo 2 caratteristiche peculiari, pregi e difetti.

Le categorie valutate riguardano l'authoring finalizzato al Web, quello relativo alla stampa cartacea e quello multi-canale. Complessivamente, i limiti principali di tali software consistono nella necessità di conoscere i linguaggi tramite cui sono creati i documenti di templating e dei contenuti; inoltre, si è vincolati all'utilizzo di editor specifici il che obbliga ad apprenderne il funzionamento.

Si è deciso, dunque, di partire dal modello fornito da ISA e sono stati proposti due linguaggi che ne generalizzano le funzionalità, uno definito embedded, da inserire nei documenti di templating tramite editor WYSIWYG noti agli utenti, ed uno full, con un potere maggiormente espressivo, ma appartenente ad un namespace differente rispetto a quello del documento di templating.

Questi linguaggi consentono di marcare gli elementi del documento di templating che devono costituire il template da estrarre e, create le opportune corrispondenze con il documento da formattare, di ottenere inoltre la conversione tra formati differenti, avendo dunque la possibilità di formattare contenuti espressi in un linguaggio diverso rispetto a quello del documento di templating. Quest'ultima operazione necessita dell'utilizzo del linguaggio full.

JMC è il software sviluppato per svolgere tale compito: costituito principalmente da un meta-foglio di stile XSLT, JMC interpreta la sintassi full e porta all'estrazione del template sotto forma di un foglio di stile XSLT il quale, applicato al documento dei contenuti, crea il documento finale. Incidentalmente, il template estratto può essere riutilizzato per qualsiasi altro documento dei contenuti che presenti gli opportuni stili di formattazione. Nel caso sia utilizzato il linguaggio embedded, esso viene convertito nel relativo codice full prima di sottoporre il documento all'estrazione del template.

I vantaggi apportati da tale soluzione sono molteplici:

  • templating generale ed estendibile: l'idea che sta alla base di JMC è quella di proporre un modello di templating che non sia limitato ad un particolare linguaggio ospite, ma utilizzabile per estrarre template da un qualsiasi documento basato su una sintassi XML;
  • creazione dei contenuti: i contenuti possono essere generati utilizzando qualsiasi editor che supporti nativamente XML o possa esportare il documento in tale formato;
  • conversione tra formati: JMC consente di creare una corrispondenza tra gli elementi presenti nel template e quelli nel documento dei contenuti; ciò permette di avere formati differenti tra template e contenuti, a patto di usare la sintassi full;
  • vasto supporto degli editor: JMC è stato progettato per consentire agli utenti di utilizzare editor diffusi e noti, sia per quanto riguarda la fase di creazione dei contenuti, sia per l'estrazione e la generazione di template che applichino caratteristiche di formattazione ai contenuti stessi; in particolare, sono state individuate caratteristiche comuni agli editor analizzati e che dovrebbero essere supportate da editor analoghi;
  • utilizzo di strumenti open source: non necessariamente implicito nelle affermazioni del punto precedente è il fatto che JMC, non basandosi su formati proprietari, non necessita dell'utilizzo di strumenti proprietari per la creazione di template o di contenuti; nulla ne vieta, tuttavia, l'utilizzo, a patto che l'output degli stessi sia in formato XML;
  • separazione dei ruoli: JMC consente di separare nettamente la produzione dei template da quella dei contenuti, in modo tale da sfruttare al meglio le competenze degli specialisti dei vari settori, piuttosto che accentrare il lavoro su un'unica figura professionale;
  • utenza differenziata: JMC prevede l'utilizzo di due linguaggi, uno utilizzabile per mezzo di editor WYSIWYG noti e diffusi, per venire incontro agli utenti meno esperti, ed uno maggiormente espressivo rivolto ad utenti esperti, anch'esso utilizzabile tramite eventuali funzionalità avanzate di editor specifici per i vari linguaggi ospite o direttamente agendo sul codice sorgente degli stessi;
  • portabilità: poiché l'esecuzione di JMC è gestita tramite Apache Ant, il quale sfrutta librerie per le trasformazioni XSLT scritte in Java, JMC può essere utilizzato su un qualsiasi sistema operativo su cui sia possibile installare Java.

Pur avendo numerosi pregi, tale soluzione presenta alcune limitazioni nel caso in cui sia possibile utilizzare il solo linguaggio embedded: la demarcazione di aree attive tramite editor grafici non offre la flessibilità adeguata a formattare aree incluse le une nelle altre, ma solamente aree contigue, poiché il risultato dell'operazione di slicing è una tabella di layout HTML.

La definizione degli stili di formattazione associati agli elementi introdotti nel layout sono da specificare tramite un foglio di stile CSS, la cui creazione esula dalle capacità di un designer Web. Nella versione semplificata proposta da ISA ed adottata da JMC, tale processo avviene definendo gli stili in un documento Microsoft Word e lasciando che sia ISA a trasformarli in un documento CSS corretto. Ciò può risultare abbastanza oneroso in termine di tempo poiché necessita di procedere per tentativi, non potendo verificare il risultato finale in tempo reale.

Da ultimo, la sola sintassi embedded non consente di estrarre contenuti da documenti in formati diversi rispetto a quello di templating, pertanto essendo quest'ultimo HTML, il documento dei contenuti deve essere proposto a JMC in tale formato.

Per concludere, si propongono alcuni possibili sviluppi futuri.

Considerando che la sintassi full permette di utilizzare formati arbitrari per i documenti di templating e dei contenuti si può pensare di estendere l'utilizzo di JMC ad altri formati XML: ad esempio, si potrebbe prendere in considerazione SVG per la creazione di template. Inoltre, potrebbe essere utile definire un meccanismo generale e facilmente estendibile per definire la corrispondenza tra attributi ed elementi di linguaggi differenti, in modo tale da aiutare l'utilizzatore nel compito di convertire gli elementi più comuni ed utilizzati di linguaggi noti.

Più in generale, al fine di rendere ancora più semplice la fase di estrazione del template e l'applicazione dello stesso ai documenti dei contenuti, JMC necessita di un'interfaccia grafica per l'esecuzione delle trasformazioni. Inoltre, è da prendere in considerazione l'integrazione del meccanismo stesso all'interno dell'architettura di ISA* così da renderlo utilizzabile in tutti gli ambiti per i quali quest'ultima è stata progettata.

Bibliografia

[Ant08] The Apache Software Foundation. Apache Ant. Ultima visita: 10/11/2008.

[Aßm03] Uwe Aßmann. Invasive Software Composition. Editor: Springer-Verlag Heidelberg. 2003.

[CC02] Gerardo Canfora and Luigi Cerulo. A Visual Approach to Define XML to FO Transformations, in ACM International Conference - Proceedings of the 14th international conference on Software engineering and knowledge engineering, Ischia, Italia, 15-19 Luglio. ACM. Pagg. 563-570. 2002.

[Coc08] The Apache Software Foundation. Apache Cocoon. Ultima visita: 07/11/2008.

[Cor08] Corel Corporation. CorelDRAW X4. Ultima visita: 26/11/2008.

[Dii07] Angelo Di Iorio. Pattern-based Segmentation of Digital Documents: Model and Implementation. 2007.

[Dre08] Adobe Systems Incorporated. Adobe Dreamweaver CS4. Ultima visita: 25/11/2008.

[FCA00] FederComin/Anasin. ICT - Le figure professionali. 2000.

[Fir08] Adobe Systems Incorporated. Adobe Fireworks CS4. Ultima visita: 25/11/2008.

[Gia02] Fabio Giannetti. FOA: an XSL-FO Authoring Tool, in Extreme Markup Languages 2002, Montréal, Quèbec, 6-9 Agosto. 2002.

[Gri02] Nikolai Grigoriev. Sagehill Enterprises. Sagehill Enterprises FO DTD. 2002.

[HTM99] AA.VV. HTML 4.01 Specification. Editor: Dave Raggett, Arnaud Le Hors and Ian Jacobs. 24/12/1999.

[Ill08] Adobe Systems Incorporated. Adobe Illustrator CS4. Ultima visita: 25/11/2008.

[Ima08] XVEL Software. Image Cut 1.5. Ultima visita: 26/11/2008.

[KK01] Clemens Kerer and Engin Kirda. Layout, Content and Logic Separation in Web Engineering, in Web Engineering, Software Engineering and Web Application Development. Springer-Verlag. Pagg. 135-147. 2001.

[KKJ01] Clemens Kerer, Engin Kirda, Mehdi Jazayeri and Roman Kurmanowytsch. Building and Managing XML/XSL-powered Web Sites: an Experience Report, in Proceedings of the 25th International Computer Software and Applications Conference on Invigorating Software Development, Los Alamitos, CA, USA. IEEE Computer Society. Pagg. 547-554. 2001.

[Oas08] OASIS. DocBook. Ultima visita: 07/11/2008.

[Ope08] Sun Microsystems - Free software community. OpenOffice 3.0.0. Ultima visita: 26/11/2008.

[Par04] Terence Parr. Enforcing strict model-view separation in template engines, in International World Wide Web Conference - Proceedings of the 13th international conference on World Wide Web, New York, NY, USA, 15-19 Luglio. ACM. Pagg. 224-233. 2004.

[Pho08] Adobe Systems Incorporated. Adobe Photoshop CS4. Ultima visita: 25/11/2008.

[SVG03] AA.VV. W3C. Scalable Vector Graphics (SVG) 1.1 Specification. Editor: Jon Ferraiolo and Dean Jackson. 14/01/2003.

[TWi08] Peter Thoeny. TWiki. Ultima visita: 09/11/2008.

[Tom08] The Apache Software Foundation. Apache Tomcat. Ultima visita: 07/11/2008.

[Ven04] Luca Ventura. Applicazione dei meta-fogli di stile: un esperimento. Pagg. 37-56. 2004.

[Vit03] Fabio Vitali. Creating Sophisticated Web Site Using Well-known Interfaces, in HCI International 2003 Conference, Creta, Grecia, 22-27 Giugno. 2003.

[Wor08] Microsoft Corporation. Microsoft Word. Ultima visita: 15/11/2008.

[XML06] AA.VV. Extensible Markup Language (XML) 1.0 (Fourth Edition). Editor: Tim Bray, Jean Paoli, C. M. Sperberg McQueen, Eve Maler and François Yergeau. 29/09/2006.

[XPa07] AA.VV. W3C. XML Path Language (XPath) 2.0. Editor: Anders Berglund, Scott Boag, Don Chamberlin, Mary F. Fernández, Michael Kay, Jonathan Robie and Jérôme Siméon. 23/01/2007.

[XPu08] Progress Software Corporation. XML Publisher. Ultima visita: 06/11/2008.

[XQu07] AA.VV. W3C. XQuery 1.0 and XPath 2.0 Functions and Operators. Editor: Ashok Malhotra and Jim Melton Norman Walsh. 23/01/2007.

[XSL06] AA.VV. W3C. Extensible Stylesheet Language (XSL) Version 1.1. Editor: Anders Berglund. 05/12/2006.


to top


You are here: Tesi > MetaStylesheet > MetaTesi

to top

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