Skip to topic | Skip to bottom
Home

Tesi
Tesi.FormatoDatiGenericoIsaWikir1.15 - 17 Nov 2004 - 16:57 - FabioVitalitopic end

Start of topic | Skip to actions

Formati Dati Generico

Il sistema IsaWiki permette la conversione di un documento da e verso molteplici formati (HTML, DOC, XML, WIKI, PDF, TeX?). Questa conversione è realizzata secondo un modello chiamato superior standard: esiste un formato intermedio nel quale è possibile esprimere un qualunque documento (in qualunque formato) e partendo dal quale è possibile generare documenti in tutti i formati supportati. La figura seguente mostra lo schema di conversione utilizzato in IsaWiki:

motoreConversione.jpg

Un documento in un qualunque formato A può essere trasformato in un documento nel formato B semanticamente equivalente, attraverso due passaggi distinti:

  • la conversione dal formato A al formato intermedio S
  • la conversione dal formato S al formato di destinazione B

In questo contesto, quindi, è necessario capire in dettaglio cosa vuol dire l'espressione semanticamente equivalente. L'idea di base è che ogni documento, indipendentemente dal formato-dati in cui è espresso, può essere diviso in due componenti nettamente distinte:

  • il contenuto: ossia l'informazione vera e propria, ciò che l'autore del documento vuole esprimere.
  • il layout: ossia i meccanismi di presentazione di questa informazione.

Il layout dipende da un lato dalle esigenze e preferenze dell'autore (o meglio, di chi/cosa produce il documento finale, sia esso un esperto di grafica, un meccanismo automatico, un tool di conversione) e dall'altro dal formato di dati utilizzato. In molti casi infatti le caratteristiche del linguaggio di markup utilizzato, le capacità dello strumento di editing usato, le abilità di chi produce i documenti influiscono sul risultato grafico finale.

Indipendentemente dalla resa grafica finale, tuttavia, la parte che realmente caratterizza un documento è il suo contenuto poichè esprime realmente l'essenza del documento. Il contenuto si arricchisce attraverso una rappresentazione grafica avanzata ma rappresenta già di per sè l'informazione.

In molti casi inoltre è necessario gestire separatamente contenuto e layout per permettere reflowing verso altri dispositivi, visualizzazione di documenti per utenti disabili, utilizzo di strumenti di visualizzazione personalizzati, ecc. Inoltre, l'individuazione del contenuto vero della pagina permette una gestione più avanzata dell'informazione, attraverso la frammentazione in unità atomiche (riutilizzabili) del documento stesso.

Queste osservazioni (che verranno meglio approfondite in altre sedi) rappresentano il punto di partenza per la definizione del formato generico di IsaWiki. L'idea principale è la seguente:

Qualunque documento in qualunque formato-dati può avere una rappresentazione in un formato intermedio che "cattura" solo il contenuto vero e proprio del documento stesso.

Nei documenti di testo è possibile ritrovare alcuni pattern che si ripetono, anche se con nomi o strutture apparentemente diversi, ma che sono semanticamente equivalenti. A questi costrutti di base, infatti, possono essere aggiunti diversi effetti grafici o elementi presentazionali, ma l'informazione di fondo resta la stessa. Un esempio concreto: un paragrafo HMTL espresso con un tag <P>, un elemento XML <paragraph>bla...bla...bla...</paragraph>, una blocco di testo in formato Wiki o in PDF rappresentano lo stesso oggetto dal punto di vista concettuale. Inoltre, anche se visualizzati con colori diversi, in diverse aree del documentodella pagina o con qualunque altro tipo di presentazione, sono lo stesso oggetto.

Il formato generico di IsaWiki si pone, appunto, l'obiettivo di descrivere tutti i pattern ripetuti nei documenti di testo e definire un formato astratto da e verso il quale convertire i documenti.

Chiameremo il formato di dati generico IML (IsaWiki Markup Language). In realtà tale affermazione non è completamente corretta ma necessita di una precisazione: IML non è il formato generico di IsaWiki ma una sua rappresentazione in una sintassi simil-XHTML. In particolare è la rappresentazione interna usata dall'editor di IsaWiki.

Il formato di dati generico non è, infatti, un linguaggio di markup, esprimibile mediante un DTD che descrive documenti a struttura fissa, ma è un meta-linguaggio generalizzato (o dichiarativo) che descrive le strutture che si ripetono nei documenti: non è usato per specificare che un documento è composto da particolari elementi, con nome ed attributi fissi, ma per definire alcune categorie di elementi generici e le relazioni tra questi. Ad esempio, IML non è usato per indicare che una paginaun documento è una sequenza di <P> con attributo align ma che è una sequenza di contenitori che racchiudono testo o elementi inline. E' indifferente che questi contenitori siano espressi come paragrafi <P> in HTML, o elementi <paragraph> in XML o altro.

Vale la pena descrivere con un po' più di attenzione cosa significhi che IML è un "linguaggio generalizzato di markup", come XML o SGML: si indicano con questo termine, infatti, quei linguaggi che permettono di definire strutture semanticamente arbitrarie all'interno di un documento, individuando di volta in volta gli aspetti più rilevanti del documento a seconda del loro uso. Ad esempio, in un documento testuale pensato unicamente per la pubblicazione può bastare evidenziare semplicemente i paragrafi, i grassetti, i titoli, ecc., mentre per documenti più complessi o dalle applicazioni più ricche può essere utile evidenziare il valore strutturale di ogni frammento, identificando questo paragrafo come un commento, quello come una didascalia, questo grassetto come un nome proprio e quel grassetto come la somma da pagare, ecc.

Sia nel caso di SGML che di XML, la necessità di convogliare le esigenze di un formato generalizzato (in grado dunque di gestire ogni tipo di etichettatura) con le esigenze di un formato di markup (che richiede un elenco chiuso e delimitato di termini - elementi - da cui trarre le etichette) ha fatto sì che ci si dirigesse gioco-forza verso la creazione di un meta-linguaggio, attraverso il quale - cioè con DTD o XML Schema, ecc. - si elencassero in modo formale tutte e sole le etichette adeguate allo specifico tipo di documento.

Ora, assurgere a livello di meta-linguaggio ha permesso a SGML e XML di sottolineare con lo stesso strumento (appunto, il DTD) due principi ben diversi: la generalizzazione del linguaggio, e la sua gerarchia. Se di generalizzazione abbiamo già detto, va specificato adesso che la gerarchia in XML e SGML è altresì completamente e infinitamente imponibile sugli elementi del linguaggio che si va a specificare. In altre parole, il DTD non definisce solo le etichette, ma anche i vincoli per l'uso di queste etichette, e in particolare i vincoli di contenimento e ripetizione

Come si è notato più volte, la maggior differenza esistente tra SGML e XML è stata la opzionalizzazione del DTD, ovvero appunto dello strumento di definizione del linguaggio di markup effettivamente utilizzato. Questo ha fatto sì che la vincolazione degli elementi di un documento XML ad un vocabolario predefinito diventasse un'operazione virtuale, sicuramente compiuta nella mente dell'autore del documento, forse (anzi probabilmente) condivisa con il destinatario concreto del documento, ma non per questo pubblicata o anche soltanto ammessa all'esterno.

Senza un DTD, un documento XML è effettivamente opaco e impenetrabile dal punto di vista semantico, strutturale e presentazionale. Certo, se i nomi degli elementi sono stati scelti in maniera appropriata (ad esempio, <commento> per indicare un commento), allora un essere umano può dedurre una semantica almeno parziale degli elementi, e da questa inferire l'organizzazione strutturale e di conseguenza anche presentazionale.

Una delle conseguenze di questa opacità è che genera non più soltanto una separazione di contenuto e presentazione, ma una assoggettazione della presentazione al contenuto: senza un documento terzo (un foglio di stile) o un atto interpretativo da parte di un essere umano, il documento XML non ha nessuna presentazione. In altre parole, non è un documento visualizzabile. Dall'interpretazione della componente semantica si deve dedurre la componente strutturale e da questa la componente di presentazione, e non può essere altrimenti.

Se poniamo la questione in questo modo, però, non (mi) è chiaro un aspetto: l'ordine interpretazione semantica-> struttura -> presentazione è un limite dell'approccio XML o è il modo corretto di fare le cose? In altri termini, è il metalinguaggio che impone questo vincolo al processo di interpretazione/visualizzazione dei documenti (che in realtà dovrebbe seguire un'altro schema) o questo è lo schema ideale a cui vogliamo arrivare?

Ad una prima analisi, lo schema interpretazione semantica-> struttura -> presentazione potrebbe sembrare l'unico modo possibile per interpretare un documento: il contenuto è la linea guida dell'interpretazione e struttura e presentazione derivano appunto dal contenuto stesso (cosa che sembra molto naturale). In quest'ottica, però, come si spiegano le osservazioni successive, sulla necessità di un formato generico e di pattern (strutture) ripetuti, associabili a più significati?

Un'altra interpretazione potrebbe essere la seguente: "sostituire lo schema fisso e unidirezionale di XML con uno schema più flessibile che considera la struttura come un qualcosa ad un livello "superiore" scorrelata da significato e presentazione". Di volta in volta, significato e presentazione possono essere associati ad elementi che hanno la stessa struttura. Ma fino a che punto può essere corretto considerare struttura e significato completamente scorrelati? Non potremmo dire che una struttura ha un significato intrinseco e viceversa?

Si noti che questo non è in nessuna maniera dovuto imprescindibilmente al concetto di linguaggio generalizzato, ma deriva invece dall'idea di meta-linguaggio: nel momento in cui vengono forniti degli strumenti per generare strutture, piuttosto che strumenti per attribuire significato a strutture predefinite, si assoggettano le strutture al significato, e non le si lascia indipendenti.

Ma qual'è il rapporto tra strutture e significato? Vale la pena discutere a fondo sul ruolo di queste due componenti, sui loro vincoli e dipendenze, e sulla "semantica" che diamo ad entrambe. Possiamo fare degli esempi concreti?

Probabilmente i due aspetti non possono essere completamente scorrelati ed associabili in modo diverso in situazioni diverse. Tuttavia potrebbe esserci solo un problema di terminologia e di comprensione chiara ed univoca di ciò che intendiamo per "significato di una struttura".

Allora, ti spiego il mio ragionamento, vediamo se sei d'accordo:

  • il significato di un frammento di documento è una caratteristica necessariamente definita e compresa da esseri umani: questo è un enunciato, questa una dimostrazione, questo un commento, questo un esercizio, questo un ingrediente e quello un passo della ricetta.
  • la presentazione del medesimo frammento è l'insieme delle caratteristiche tipografiche che, in questa specifica visualizzazione vengono attribuite al frammento: un certo font, un certo margine, una certa interlinea, ecc.
  • la struttura, un po' per definizione e un po' per esclusione dagli altri concetti, è il rapporto che intercorre tra il frammento in questione e gli altri che compongono il resto del documento: viene descritto da caratteristiche come il contenimento, la giustapposizione, la ripetizione, la facoltatività, ecc. Altreesì (ma qui il discorso si fa sottile), appartengono alla sfera della struttura concetti come contenitore, blocco, elemento inline. La forma di un contenitore come descritto in IML, infatti, è una semplice presa d'atto della struttura dell'elemento e del suo contenuto, non del "significato" del contenitore o della sua rappresentazione grafica.

Sono d'accordo ma strutturerai la cosa in maniera gerarchica. Mi spiego: la presentazione non la vedo come una proprietà del frammento di testo, ma della struttura utilizzata per rappresentare il frammento. La classificazione proposta in precedenza diventa:

  • il significato di un frammento di documento è una caratteristica necessariamente definita e compresa da esseri umani: questo è un enunciato, questa una dimostrazione, questo un commento, questo un esercizio, questo un ingrediente e quello un passo della ricetta. E' un concetto ad un livello più alto, indipendente dalla rappresentazione in un documento di testo. L'idea è che un commento resta un "concetto" a sè stante che in documento di testo può essere rappresentato con una determinata struttura, in un discorso verbale può diventare una frase (in questo caso, diversi accenti o toni di voce potrebbero essere assimilati a diverse presentazioni), in un ragionamento mentale è un "pensiero". Può avere senso un parallelismo del genere?
  • la presentazione non si riferisce ad un frammento (o meglio al suo significato) ma alla struttura scelta per rappresentare il frammento nel documento. E' l'insieme delle caratteristiche tipografiche che, in questa specifica visualizzazione vengono attribuite al frammento: un certo font, un certo margine, una certa interlinea, ecc. Di conseguenza parlerei prima di struttura ed in seguito di presentazione. La presentazione è una proprietà della struttura più che del significato.
  • la struttura: è la rappresentazione in un documento di un concetto che esiste ed ha un proprio significato indipendentemente dal fatto di essere espresso e descritto attraverso un documento di testo. In quest'ottica le strutture a disposizione sono naturalmente ed inevitabilmente circoscritte ad alcuni elementi di base che possono essere sì combinati in maniera infinita ed indefinita, ma che formano un "alfabeto" di costrutti di base da cui si costruisce il "linguaggio" delle strutture. Le strutture sono composte da due parti:
    • un "alfabeto di elementi di base". E' necessario definire alcune strutture che si ripetono nei documenti e che permettono di rappresentare significati. L'espressione "rappresentare significati" non significa spiegare cosa significa un frammento ma "proiettare in un documento di testo" un concetto di livello più alto. Questa "proiezione" non può non passare attraverso l'uso di un set ristretto di strutture.
    • un insieme di regole di costruzione,che esprimono i vincoli e le relazioni tra i costrutti di base. Entrano in gioco concetti come il contenimento, la giustapposizione, la ripetizione, la facoltatività, ecc.

Ora, la scelta del significato non è soggetto a limiti: i significati applicabili ai frammenti di documento sono tanti quanti sono i concetti descrivibili a parole, e quindi, per la nostra discussione, infiniti. D'altra parte, il nostro modello tipografico limita a solo un certo numero di attributi la presentazione: scelto il font, l'interlinea, i margini e poco altro, la presentazione è fatta.

Com'è la struttura? Per i DTD, la struttura è un qualunque costrutto derivabile attraverso le regole di costruzione, quindi altrettanto infinito quanto i significati, e infatti da esso dipende. Però non è intrinseco nel concetto (semantico) di "commento" la natura (strutturale) di contenitore o blocco, tanto quanto non ne è intrinseca la natura (presentazionale) di "Times New Roman, 12 pt, margine 3 px".

Mi convince fino ad un certo punto. Non è "intrinseco" nel concetto (semantico) di "commento" la natura (strutturale) di contenitore o blocco, ma per certi versi è "naturale" scegliere questo tipo di costrutto. L'idea è la seguente:

  • un significato esiste indipendentemente dalla struttura
  • per essere espresso in un documento di testo bisogna scegliere una struttura e "forzare" questo significato in questa struttura (ecco, quindi, che struttura e significato sono su due piani diversi).
  • Alcune di queste associazioni significato->struttura sono naturali e derivano dal significato stesso del frammento.

In sostanza, far dipendere il numero ed i tipi di strutture dai loro significati (cioe' dai loro nomi) equivale ad assoggettare le strutture all'infinita varietà di significati, quando invece vediamo che sono pochi e ripetuti i tipi concretamente usati (e ancora meno quelli concretamente utili) nella progettazione di documenti.

Per concludere, quello che cerco di spiegarmi è come giustificare che la restrizione delle strutture ad un certo numero limitato sia da un lato infinitamente utilizzabile per la creazione di significati (e direi che qui ci sono), ma dall'altro che non costituisca un'indebita restrizione delle esigenze strutturali di un documento reale (e qui faccio un po' più fatica).

A me sembra che questa "forzatura" sia un processo inevitabile. In fondo un documento di testo, esprime concetti ed impone dei vincoli sui costrutti che si possono utilizzare. E' uno strumento di rappresentazione di idee (?) e quindi, come tutti gli strumenti, impone dei vincoli e delle regole.

Lasciamo pure perdere l'equivalenza tra XHTML, HTML e XML delle strutture identificate. Riusciamo a convincere un ipotetico lettore che tutte le risposte alle sue esigenze di organizzazione delle strutture del suo documento sono contenute nelle forme di IML? Riusciamo a garantirgli la necessaria libertà di espressione del significato togliendogli libertà nell'espressione delle strutture?

Non so se allo stato attuale si può concludere questo, ma si potrebbe pensare a qualche estensione di IML (se necessaria). Bisogna capire fino a che punto estendere il linguaggio e nello stesso tempo coprire tutte le strutture necessarie.

Questo diventa, quindi, il punto fondamentale della discussione: un documento di testo è una rappresentazione di concetti che devono necessariamente essere "rappresentati" usando i costrutti forniti dal linguaggio. Il problema è capire quanti e quali sono questi costrutti che permettono di coprire tutti i significati.

Esistono fondamentalmente due approcci:

  • un approccio esaustivo, che è quello usato da TEI e DocBook?. Si basa sulla definizione di un linguaggio estremamente dettagliato e ricco di costrutti.
  • un approccio minimalista, che è quello usato da IML. Si basa sulla definizione di pochi costrutti e pattern, sufficienti tuttavia a rappresentare tutti (o quasi, questo è il punto!) i possibili significati di un documento.

La differenza non sta nel risultato che si può ottenere (ovviamente un linguaggio come TEI ha molti costrutti ed inevitabilemente permette una descrizione ed un controllo dei contenuti molto più fine di IML!) ma negli obiettivi dei due approcci:

  • l'approccio esaustivo porta alla creazione di documenti complessi ma completi di informazioni
  • l'approccio minimalista porta alla creazione di documenti più semplici ma che perdono alcune informazioni. L'obiettivo è appunto minimizzare la perdita delle informazioni e riuscire ad esprimere in maniera "decente" sia gli stessi concetti (significati) che la stessa presentazione.

Un punto cruciale quindi è capire qual'è il rapporto tra i due approcci. L'idea è che hanno due scopi diversi e sono su due piani diversi: se si vuole creare un documento complesso del quale analizzare e strutturare nel dettaglio tutti i frammenti e tutti i possibili significati (usando specifici tag, costrutti ed attributi) bisogna usare un approccio esaustivo, se si vuole rappresentare dei documenti in maniera semplificata ma senza perdere informazioni rilevanti conviene utilizzare un approccio minimalista.

IMPORTANTE: Un approccio minimalista si basa su spostamento delle informazioni. In altri termini, non vogliamo impoverire il linguaggio e perdere le informazioni e le classificazioni dei frammenti (fornite di default in un linguaggio esaustivo) ma utilizzare un set ristretto di costrutti di base e aggiungere (come attributi? come metainformazioni?) questi dati. Un esempio: il costrutto <TERM> del DTD di TEI può essere espresso come un'elemento in-line di classe termineTecnico, cioè <SPAN class='termineTecnico'> in IML. La prima rappresentazione è più diretta e naturale, la seconda, tuttavia, permette di ottenere lo stesso risultato(?).

Riassumendo:

  • l'approccio esaustivo "cattura" i significati attraverso i costrutti del linguaggio
  • l'approccio minimalista "esprime" le strutture attraverso i costrutti del linguaggio e "cattura" i significati associando informazioni a determinate strutture.

Riusciamo (e anche questo è importante) a fornire una presentazione "naturale" delle strutture in modo che, anche se in maniera magari non sofisticata, il documento XML che presenta ed utilzza solo queste strutture sia immediatamente visualizzabile in maniera "decente"?

Vale la pena investigare le relazioni tra struttura->presentazione e capire se esistono associazioni "intrinseche" o almeno "naturali" tra le due componenti, estendendo le riflessioni fatte sul rapporto tra significato e struttura.

Discorso diverso è invece la completa separazione tra significato, strutture e presentazione, senza assoggettazioni: questo può essere fatto soltanto se le strutture esistono e vengono identificate indipendentemente dal loro significato. Un modo potrebbe essere quello di identificare strutture semplici e ben note, creare un catalogo di design pattern di strutture di documenti.

Questo è esattamente quello che si è prefisso di fare IML. Mantenendo comunque la liberta di assegnare alle strutture qualunque significato e qualunque caratterizzazione presentazionale, IML definisce un numero limitato di pattern da identificare nei documenti di testo. In ipotesi, qualunque struttura effettivamente esistente nei documenti di markup deve avere o un'immediata corrispondenza nelle strutture di IML, o una sua facile convertibilità in IML attraverso l'uso di elementi fittizi che rigenerino la struttura del pattern richiesto.

Guardiamo IML da un altro punto di vista e cerchiamo di spiegar(ci) i motivi per cui un approccio minimalista è il più adatto alla realizzazione di un CMS in cui i documenti sono creati e gestiti indipendentemente dal formato-dati originario (e possono essere convertiti, quindi, da un formato-dati all'altro usando, appunto, il formato generico): assumendo che il modello superior standard è il più adatto allo scopo in quanto più efficiente, più facile da estendere e più sicuro (in seguito discuteremo più a fondo queste considerazioni), il punto cruciale è capire quanto deve essere complesso e completo il formato intermedio.

Anche in questo caso esistono due soluzioni:

  • approccio esaustivo: definire un linguaggio esteso e complesso che racchiuda tutti (o la maggior parte dei) costrutti forniti dai diversi formati-dato
  • approccio minimalista: definire un linguaggio ridotto ed un insieme di associazioni e regole che permettano di ricondurre i costrutti (molti) dei diversi formati-dato a quelli (pochi) del formato generico. Questo processo è realizzato arricchendo i costrutti del formato intermedio con informazioni aggiuntive. Ovviamente anche in questo caso bisogna minizzare le informazioni "perse" durante la traduzione.

Un approccio minimalista permette:

  • di aggiungere più facilmente un nuovo formato dati al motore di conversione
  • di creare applicazioni più efficienti (meno casi da gestire e regole più generali di conversione)
  • di testare il motore di conversione più facilmente

Queste ultime riflessioni comunque devono essere ulteriormente discusse, approfondite ed estese.

IML dunque definisce i seguenti elementi:

  • testo atomico
  • blocco
  • elemento in-line
  • lista
  • record
  • tabella speciale
  • contenitore

Di seguito sono discussi in dettaglio i singoli elementi del linguaggio, i vincoli imposti su ognuno e le relazioni tra le diverse componenti di IML.

Testo atomico

Il testo atomico è una sequenza di soli caratteri. Esso può essere contenuto solo all'interno degli elementi blocco, record ed in-line e non può contenere nessuno degli altri elementi di IML.

Blocco

Il blocco è un oggetto che inizia e termina con un line-break. In un sistema di scrittura occidentale i blocchi sono posti verticalmente uno dopo l'altro all'interno del documento. La seguente immagine mostra un testo molto semplice composto da 3 blocchi, di diverso livello:

blocchi.jpg

IML permette la definizione di 3 diversi tipi di blocco:

  • blocco-paragrafo: blocco standard, rappresentato in IML con <P>
  • blocco-titolo: particolare tipo di blocco standard, utilizzato solitamente per strutturare un documento. Con una sintassi molto simile ai titoli HTML, in IML sono rappresentati con i tag <H1>,<H2>,...,<H6>.
  • blocco-personalizzato: blocco personalizzato dall'utente che gli assegna un'etichetta e conseguentemente un ruolo. Ad esempio si può pensare ad un blocco contenente un commento importante. In IML è rappresentato come <P class ="commentoImportante">commento...</P>. La rappresentazione XML che è semanticamente equivalente, invece, è <commentoImportante>commento...</commentoImportante>

Elemento in-line

Un elemento in-line è un elemento posto all'interno di un blocco o di un altro elemento in-line ed utilizzato per assegnare un particolare ruolo ad un frammento di testo. Gli elementi inline sono inseriti in sequenza orizzontale all'interno di un blocco, così come il testo. All'interno di un elemento in-line è possibile trovare del testo o altri elementi in-line. Non è possibile avere blocchi all'interno di un elemento di questo tipo.

IML permette la definizione di 2 tipi di elementi in-line:

  • in-line predefiniti: sono gli elementi inline comunemente utilizzati nei documenti di testo e per questo supportati da tutti i formati-dato. Appartengono a questa categoria gli elementi <I>, <U>, <B>, <A>.
  • in-line personalizzati: gli elementi in-line che l'utente può creare in base alle proprie esigenze e preferenze, per assegnare determinati ruoli ai vari frammenti di testo. Si consideri l'esempio di un frammento di testo che l'utente vuole classificare come "data". IML definisce questo elemento in-line con la seguente sintatti (simile ad HTML): <SPAN class ="data">25 Dicembre 2004</SPAN>. La rappresentazione XML che è semanticamente equivalente, invece, è <data>25 Dicembre 2004</data>

Ovviamente, da un certo punto di vista, è sempre e comunque possibile attribuire un significato particolare agli eleemnti in-line predefiniti, cioe' un significato particolare ad un elemento bold o italic. Tuttavia questo ha poco senso perché l'operazione appropriata dovrebbe invece essere inversa: l'attribuzione di una presentazione italic ad una struttura in-line con significato particolare.

Lista

Una lista è un elenco (ordinato o non) di item. Ogni item può contenere a sua volta 4 diversi tipi di elementi:
  • blocco
  • lista
  • record
  • tabella speciale
Di conseguenza un item di una lista non può contenere direttamente testo o elementi in-line. Questo vincolo ha richiesto l'implementazione in IsaWiki di meccanismi per la correzione e la normalizzazione delle liste secondo il formato di dati generico.

La sintassi delle liste in IML prevede l'uso dei tag <OL> ed <UL> rispettivamente come elementi-radice di una lista non-ordinata e di una lista ordinata. Ogni elemento <OL> (e allo stesso modo <UL>) può contenere esclusivamente una sequenza di elementi <LI>. L'elemento <LI> quindi è il singolo item della lista che può contenere, come visto in precedenza, blocchi, altre liste, record e tabelle speciali.

Riassumendo, la sintassi di IML è praticamente identica alla sintassi di HTML, con l'aggiunta di un vincolo sul contenuto di <LI>. Il contenuto di un item della lista non può essere direttamente testo o elemento inline, ma deve essere un elemento strutturato. Di seguito un esempio di lista ordinata composta da due item contenenti, rispettivamente, un blocco ed una lista non ordinata con un singolo item (contenente a sua volta testo, racchiuso in un blocco):

<OL>
    <LI> <P> Blocco A</P>   </LI>
    <LI>
      <UL>
       <LI> <P> Blocco B</P>   </LI>
      </UL>
    </LI>
</OL>

Record

Un record è una sequenza di valori qualificati da etichette. In altri termini, il record è una coppia nome-valore dove l'elemento nome è una sequenza di soli caratteri e l'elemento valore può contenere un blocco o una struttura più complessa. In particolare il valore di un record può contenere:
  • uno o più blocchi
  • una lista
  • un record
  • una tabella speciale

Il record, quindi, è utilizzato per mappare i costrutti usati nei documenti per descrivere dati strutturati e per associare determinati valori a determinate etichette. Ogni record ha un nome che lo identifica.

La sintassi IML deriva da quella XHTML che non prevede la struttura di record. Per superare questo limite, in IML un record è rappresentato con una tabella <TABLE> a due colonne in cui:

  • la prima colonna è un elemento <TH> contenente le etichette della coppie nome-valore
  • la seconda colonna è un elemento <TD> contenente i valori del record, che possono essere anche strutturati.
Ogni riga della tabella rappresenta una coppia nome-valore.

La tabella IML che desscrive un record ha due attributi:

  • class: specifica il nome del record (che verrà poi utilizzato nella conversione in formato XML)
  • IWType: indica se la tabella è un record o una tabella speciale (in questo caso assume valore "record").

Di seguito è riportato un esempio di record e la corrispondente rappresentazione in IML. All'etichetta Nome e Cognome è assegnato un testo atomico, all'etichetta Indirizzo invece è assegnata un'informazione ulteriormente strutturata in un record le cui etichette sono Via, Civico .

Nome e Cognome Indirizzo
Angelo Di Iorio Mura Anteo Zamboni 7

La rappresentazione IML di questo record è la seguente:

<TABLE class="info" IWType="record">
  <TR> 
    <TH>  Nome e Cognome    </TH>
    <TD> <P> Angelo Di Iorio </P>   </TD>
  </TR> 
  <TR> 
    <TH>  Indirizzo   </TH>
    <TD>
     <TABLE class="ufficio" IWType="record">
       <TR>
         <TH> Via   </TH>
         <TD> <P> Mura Anteo Zamboni </P> </TD>
       </TR>
       <TR> 
         <TH>  Civico  </TH>
         <TD> <P> 7 </P> </TD>
       </TR>
     </TABLE>
    </TD>
  </TR>
</TABLE>

Anche in questo caso è possibile creare una rappresentazione XML dello stesso record, che è semanticamente equivalente alla precedente:

<INFO>
    <NOMECOGNOME>Angelo Di Iorio</NOMECOGNOME>
    <INDIRIZZO>
        <UFFICIO>
            <VIA>Mura Anteo Zamboni</VIA>
            <CIVICO> 7 </CIVICO>
        <UFFICIO>
    </INDIRIZZO>
</INFO>

Attenzione: due dubbi su questa rappresentazione e l'implementazione di IsaWiki. Da discutere:

  • Il contenuto di <TH> può essere un blocco o è solo testo?
  • è corretto l'annidamento di INDIRIZZO nella rappresentazione XML?

Tabella speciale

Una tabella speciale è un oggetto che contiene più record dello stesso tipo. Anche le tabelle speciali, come i record, sono identificate da un nome e vengono utilizzate per descrivere dati strutturati (in particolare dati diversi che si ripetono con la stessa struttura).

In IML di una tabella speciale è una tabella <table> formata da:

  • la prima riga che contiene le etichette (una per ogni colonna, ovviamente)
  • tante righe quanti sono i record (il valore nella colonna corrispondente ad una etichetta forma con quest'ultima la coppia nome-valore di ogni record)

Inoltre la tabella IML ha due attributi:

  • class: specifica il nome della tabella-speciale (che verrà poi utilizzato nella conversione in formato XML)
  • IWType: indica se la tabella è un record o una tabella speciale (in questo caso assume valore "table").

Le celle che contengono le etichette (quelle della prima riga) possono contenere solo testo (verranno poi convertite in XML con il nome di un tag), le celle-valore invece posso contenere blocchi, liste, record e tabelle speciali.

Si noti che in IML la rappresentazione di un record può essere definita rappresentazione per colonna poichè un record si estende su due colonne (la prima contiene le etichette e la seconda i valori), mentre una tabella speciale è rappresentata per righe, poichè ogni record della tabella occupa una riga e le etichette stesse si estendono su una riga (la prima) e non su una colonna. Una tabella speciale composta da due righe, quindi, è un record visualizzato orizzontalmente (a differenza della rappresentazione verticale di default di un record IML).

Di seguito è riportato un esempio di tabella speciale contenente due record, che ripetono la struttura dell'esempio precedente:

Nome e Cognome Indirizzo
Angelo Di Iorio Mura Anteo Zamboni 7
Fabio Vitali Mura Anteo Zamboni 7

La rappresentazione IML di questa struttura-dati è la seguente:

<TABLE class="persone" IWType="table"> 
    <TR class="info">    
        <TH>Nome e cognome</TH>
        <TH>Indirizzo</TH>
    </TR>
    <TR class="info">    
      <TD><P>Angelo Di Iorio</P></TD>
      <TD>
        <TABLE class="ufficio" IWType="record">
          <TR>
             <TH> Via   </TH>
             <TD> <P> Mura Anteo Zamboni </P> </TD>
          </TR>
          <TR> 
              <TH>  Civico  </TH>
              <TD> <P> 7 </P> </TD>
          </TR>
        </TABLE>
      </TD>
    </TR>
    <TR class="info">    
      <TD><P>Fabio Vitali</P></TD>
      <TD>
        <TABLE class="ufficio" IWType="record">
          <TR>
             <TH> Via   </TH>
             <TD> <P> Mura Anteo Zamboni </P> </TD>
          </TR>
          <TR> 
              <TH>  Civico  </TH>
              <TD> <P> 7 </P> </TD>
          </TR>
        </TABLE>
      </TD>
    </TR>
</TABLE> 

La corrispondente rappresentazione XML è la seguente:

<PERSONE>
<INFO>
    <NOMECOGNOME>Angelo Di Iorio</NOMECOGNOME>
    <INDIRIZZO>
        <UFFICIO>
            <VIA>Mura Anteo Zamboni</VIA>
            <CIVICO> 7 </CIVICO>
        <UFFICIO>
    </INDIRIZZO>
</INFO>
<INFO>
    <NOMECOGNOME>Fabio Vitali</NOMECOGNOME>
    <INDIRIZZO>
        <UFFICIO>
            <VIA>Mura Anteo Zamboni</VIA>
            <CIVICO> 7 </CIVICO>
        <UFFICIO>
    </INDIRIZZO>
</INFO>
</PERSONE>

Contenitore

Un contenitore è un oggetto che può contenere un numero arbitrario di:
  • blocchi
  • liste
  • record
  • tabelle speciali

Appartengono a questo gruppo: gli item di una lista, le celle delle tabelle di layout, le aree identificate come contenuto editabile, le celle dei record e delle tabelle speciali.

Questi oggetti potrebbero essere definiti contenitori di livello 0, in quanto contengono le strutture di primo livello (blocchi, liste, tabelle speciali e record) che, a loro volta, racchiudo il contenuto vero e proprio del documento.

Ha senso utilizzare il contenitore in modo così generico? O conviene pensare a un DIV o qualcosa di simile?

Nella tesi di Daniele Gubellini, si introduce il concetto di contesto (vedi CatalogoPattern). E' un contenitore all'interno del quale improvvisamente certi construtti hanno giustificazione e senso (o perdono giustificazione e senso). Ad esempio, all'interno dell'elemento <FORM> il costrutto <INPUT> assume improvvisamente senso e giustificazione.

Non è che il contenitore che stiamo cercando di definire in realtà non è altro che un contesto additivo? N.B.: gli item di una lista non appartengono ai possibili contenitori: quelli appartengono senza dubbio al pattern TABELLA, avendo la seguente forma:

<!ELEMENT UL (LI+) >

Mi fa notare Daniele che in realtà tutti i contenitori appartengono al pattern tabella, che ha anche la forma

<!ELEMENT X (A|B|C)*>

dove A, B e C sono record (se fossero atomi X sarebbe un blocco). Secondo me ha abbastanza ragione, ma mi piacerebbe dicuterne.

-- FabioVitali - 10 Nov 2004
to top


You are here: Tesi > FormatoDatiGenericoIsaWiki

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