Il problema dell`overlapping nel change tracking dei

Transcript

Il problema dell'overlapping nel change tracking
dei documenti di testo in Open Document
Format e Oce Open XML
Alessio Rolni
10 marzo 2010
Sommario
Il problema dell'overlapping si può presentare quando, ad uno stesso
documento, vengono associate più gerarchie distinte.
Ad esempio, nel-
la gestione del change tracking di editor di documenti: qualsiasi editor
prevede la possibilità di identicare ogni modica eettuata da ogni singolo autore, ed eettuare operazioni su di essa (ad esempio validarla,
rigettarla, etc..).
Ad un singolo contenuto (il documento), viene quindi
aggiunta una nuova gerarchia (le informazioni di change tracking), che si
sovrappone all'esistente e si interseca con essa.
L'overlapping nei formati documentali è un problema noto, e nel passato è sempre stato gestito con tecniche ad hoc, facenti leva sul particolare
formato dei dati di ogni singola applicazione.
Nel caso in cui i dati siano rappresentati in XML il problema assume
proporzioni importanti.
La gestione delle gerarchie multiple non è una
caratteristica prevista dall'XML, che necessita di un'organizzazione dei
dati strutturata ad albero. E stiamo assistendo in questi anni all'introduzione di formati XML in una moltitudine di ambiti applicativi che prima facevano uso di formati ad hoc.
Questo perchè l'XML è facilmente
gestibile ed elaborabile con una moltitudine di strumenti, ed uno stesso
documento può essere fruito in diversi ambiti (ad esempio redatto con un
word processor, pubblicato su un sito web e letto online da un browser su
un palmare).
L'introduzione di gerarchie in overlap all'interno di un le XML può
generare diversi problemi (ad esempio l'XML può non essere più ben
formato) e sono state studiate diverse tecniche per risolverli.
Questo documento si propone di denire cos'è l'overlapping, di elencare
le diverse tecniche conosciute per gestire l'overlapping in documenti XML,
focalizzandosi sull'ambito del change tracking. Verranno introdotti brevemente i formati di dati Open Document Format (Openoce.org) e Oce
Open XML (Microsoft Oce 2007) con particolare enfasi sui meccanismi
del change tracking.
Verranno presentati degli esempi di overlapping in formato OpenOfce.org e Microsoft Oce 2007.
1
Indice
1 Introduzione
4
2 Tecniche per la gestione dell'overlapping
5
2.1
Gerarchie sacre e profane
2.2
Linee Guida TEI . . . . . . . . . . . . . . . . . . . . . . . .
6
2.3
Gli approcci al problema . . . . . . . . . . . . . . . . . . . .
6
2.3.1
Milestones . . . . . . . . . . . . . . . . . . . . . . . .
6
2.3.2
Flattened
8
2.3.3
Fragmentation
2.3.4
Twin documents
2.3.5
2.4
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
5
. . . . . . . . . . . . . . . . . . . . .
9
. . . . . . . . . . . . . . . . . . . .
11
Stand-o markup . . . . . . . . . . . . . . . . . . . .
13
Vantaggi e svantaggi di ogni approccio . . . . . . . . . . . .
15
3 Il change tracking e l'overlapping - considerazioni generali 18
4 Il formato dati del change tracking in ODF (Open Document Format)
20
4.1
Cenni sulla struttura dei documenti Open Document Format 20
4.2
La lista delle modiche . . . . . . . . . . . . . . . . . . . . .
23
4.3
Tipologie di modiche
. . . . . . . . . . . . . . . . . . . . .
23
. . . . . . . . . . . . . . . . . . . . . . .
24
4.4
4.3.1
Inserimenti
4.3.2
Cancellazioni
4.3.3
Cambiamenti di formato . . . . . . . . . . . . . . . .
26
Le metainformazioni del change tracking . . . . . . . . . . .
26
. . . . . . . . . . . . . . . . . . . . . .
25
5 Il formato dati del change tracking in OOXML (Oce
Open XML - Microsoft)
28
5.1
Cenni sulla struttura dei documenti OOXML
5.2
Le annotazioni
5.3
. . . . . . . .
28
. . . . . . . . . . . . . . . . . . . . . . . . .
29
5.2.1
Annotazioni Inline
5.2.2
Annotazioni Cross Structure
. . . . . . . . . . . . . . . . . . .
5.2.3
Annotazioni di proprietà . . . . . . . . . . . . . . . .
31
il supporto al change tracking e le tipologie di modica . . .
32
. . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
30
30
5.3.1
Inserimento di un run
5.3.2
Cancellazione di un run
. . . . . . . . . . . . . . . .
33
5.3.3
Spostamento di un run . . . . . . . . . . . . . . . . .
34
5.3.4
Modica di attributi/proprietà di un run (run properties) . . . . . . . . . . . . . . . . . . . . . . . . . .
33
35
5.3.5
Inserimento di un paragrafo
. . . . . . . . . . . . .
36
5.3.6
Cancellazione di un paragrafo . . . . . . . . . . . . .
37
5.3.7
Spostamento di un paragrafo
37
5.3.8
Modica di attributi/proprietà del paragrafo
5.3.9
Inserimento di una cella di tabella
. . . . . . . . . . . . .
5.3.10 Cancellazione di una cella di tabella
. . . .
39
. . . . . . . . . .
40
. . . . . . . . .
41
. . . . . . . . . . . . . . . . . . . . .
42
5.3.12 Inserimento di una riga di tabella . . . . . . . . . . .
43
5.3.11 Unione di celle
5.3.13 Cancellazione di una riga di tabella . . . . . . . . . .
44
5.3.14 Inserimento di XML custom . . . . . . . . . . . . . .
44
2
5.3.15 Cancellazione di XML custom . . . . . . . . . . . . .
45
5.3.16 Spostamento di XML custom . . . . . . . . . . . . .
46
5.3.17 Altre operazioni
47
. . . . . . . . . . . . . . . . . . . .
6 Alcuni esempi in Open Document Format
48
6.1
Inserimento . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
6.2
Cancellazione . . . . . . . . . . . . . . . . . . . . . . . . . .
49
6.3
Complichiamo un po' le cose: la cancellazione dentro l'inserimento
6.3.1
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
Problema (bug?)
50
nella cancellazione con lo stesso
utente . . . . . . . . . . . . . . . . . . . . . . . . . .
7 Alcuni esempi in OOXML
51
53
7.1
Inserimento . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2
Cancellazione . . . . . . . . . . . . . . . . . . . . . . . . . .
54
7.3
Cancellazione da parte di altri utenti . . . . . . . . . . . . .
55
7.4
Inserimento di paragrafo . . . . . . . . . . . . . . . . . . . .
56
7.5
Spostamento di paragrafo vuoto . . . . . . . . . . . . . . . .
57
7.6
Spostamento di un run . . . . . . . . . . . . . . . . . . . . .
57
Riferimenti bibliograci
53
59
3
1 Introduzione
In generale, si parla di overlapping quando esiste una situazione nella quale, ad
un unico contenuto, si vogliono associare più gerarchie, ovvero, in XML/SGML,
quando si rende necessario applicare più elementi di markup sullo stesso contenuto, e questi elementi sono indipendenti l'uno dall'altro [8].
Focalizzandoci sull'XML, questo è un problema di espressività del linguaggio: i
singoli elementi del documento devono essere organizzati gerarchicamente in un
unico albero, ed ogni frammento del documento deve essere contenuto in uno ed
un solo elemento XML. Ogni elemento XML deve essere contenuto in uno ed un
solo elemento padre, il quale deve essere contenuto in uno ed un solo elemento
padre a sua volta, così no al raggiungimento dell'elemento radice.
Questi
vincoli hanno più a che fare con la facilità di elaborazione dell'XML che non
con le caratteristiche e gli scopi dei linguaggi di markup in generale [10]. Infatti
esistono numerosi casi nei quali un singolo frammento di documento deve essere
associato a descrittori di markup dierenti e gerarchicamente incompatibili. E'
uno scenario comune nella bioinformatica, nella linguistica, nel change tracking,
etc...
In letteratura il problema è noto da tempo, e sono numerosi gli studi per gestire
documenti con gerarchie in sovrapposizione.
Alcune risposte possono essere
trovate nell'SGML stesso, con un opportuno tag (CONCUR) che non è stato però implementato nell'XML, oppure facendo uso di modelli dierenti, sia
astratti (GODDAG), che linguaggi di markup alternativi (LMNL) all'XML.
Possiamo riconoscere diverse tipologie di overlapping:
•
Overlapping classico : quando due frammenti di uno stesso documento,
annotati con due identicatori generali dierenti, si sovrappongono.
•
Self overlapping : quando due componenti della stessa struttura, con lo
stesso nome, si sovrappongono.
Questo può essere il caso, ad esempio,
di due revisioni su due regioni di testo che si sovrappongono.
Le re-
visioni apparterranno alla stessa struttura (la struttura delle revisioni,
appunto). Si avranno quindi elementi dello stesso tipo con gli stessi nomi che si sovrapongono.
Se si implementassero questi casi forzando un
rilassamento delle restrizioni di buona formattazione dell'XML, sarebbe
impossibile determinare i commenti in maniera univoca, ad esempio [7]:
<comment>John <comment>likes</comment> Mary</comment>
•
Elementi virtuali : si tratta di elementi usati per denire elementi il cui
contenuto è un riordinamento di materiale presente altrove nel documento.
Sono anche usati per denire elementi il cui contenuto non è una regione
di testo continuo. In questo caso sono chiamati elementi discontinui.
4
•
Contenimento/Dominanza: la dominanza è la relazione tra parti del documento, dove una domina l'altra se è un'antenata nella struttura del doc-
è una relazione che identica quale parte del documento ingloba sicamente un'altra parte, senza relazione gerarchica tra le
parti. Ancora più semplicemente, una parte a contiene un'altra parte b se a
contiene tutti i caratteri del contenuto di b.
umento. Il contenimento
2 Tecniche per la gestione dell'overlapping
Nei primi lavori sul problema degli overlap, uno dei metodi per la loro gestione
era semplicemente l'ignorare le regole di annidamento dei tag dell'SGML/XML,
creando dei documenti che non potevano essere validati, perchè malformati, e
per i quali non poteva essere scritto alcun DTD, rendendo impossibile la loro
elaborazione per mezzo degli strumenti XML.
Successivamente sono state identicate diverse tecniche.
Vediamo di seguito
alcuni concetti importanti e le principali sul dominio dei documenti XML.
2.1 Gerarchie sacre e profane
In documenti aventi più di una gerarchia è utile fare distinzione tra i nodi (tag
di markup) condivisi tra tutte le gerarchie (cosiddetti sacri) ed i nodi specici
di una determinata gerarchia (profani).
Esemplicando, se avessimo a che fare con un documento HTML con più gerarchie, i tag <HTML> e <BODY>, necessari alla corretta formattazione del
documento per ogni gerarchia, sarebbero nodi sacri.
I nodi specici di ogni
altra gerarchia sarebbero profani.
Possiamo quindi denire sacra la gerarchia composta dai nodi sacri.
Di
contro, profana è ogni gerarchia composta dai propri nodi profani.
Si può notare che non possono esservi problemi di overlapping all'interno del
markup sacro, nè all'interno delle singole gerarchie profane, nè all'interno dell'unione della gerarchia sacra con una gerarchia profana.
Invece, possono esservi problemi di overlap in caso di unione tra la gerarchia
sacra e più di una gerarchia profana nello stesso documento.
5
2.2 Linee Guida TEI
TEI (Text Encoding Initiative) è un consorzio che sviluppa e mantiene uno standard per la rappresentazione di testi in formato digitale. Pubblica un insieme di
linee guida che specicano metodi di codica per testi che debbano essere letti
da macchine. I maggiori campi di applicazione si possono trovare nell'ambito
delle scienze sociali, della linguistica e negli studi umanistici in genere.
Nella versione P5 delle Linee Guida per la codica e lo scambio di testi elettronici, il capitolo 20 riguarda la codica in XML di strutture non gerarchiche
[4].
I metodi descritti dalle linee guida possono riassumersi in:
•
uso di elementi vuoti per delimitare i margini delle strutture in overlapping
(milestones);
•
suddivisione degli elementi in overlapping in segmenti che si innestino
adeguatamente, ma che possano comunque essere ricostruiti nel loro contesto gerarchico (fragmentation/segmentation)
•
codiche ridondanti dell'informazione in forme multiple (twin documents)
•
la possibilità di fare aermazioni su un determinato testo puntando ad
esso, invece di includere tag XML al suo interno (stand-o markup)
2.3 Gli approcci al problema
2.3.1
Milestones
L'approccio Milestones rappresenta una gerarchia primaria in XML standard,
delimitando i tag di inizio e di ne delle gerarchie secondarie utilizzando elementi
vuoti [10].
L'idea alla base è che, tra le varie gerarchie che competono implicitamente in
una struttura in overlap, una sia scelta come gerarchia dominante. L'inzio e la
ne di quelli che avrebbero dovuto essere gli elementi delle altre gerarchie sono
rappresentati utilizzando elementi vuoti [7].
L'inserimento di elementi vuoti evita che le caratteristiche del testo che cadono
al di fuori della gerarchia principale invalidino il documento, identicandone
l'inizio e la ne per le successive elaborazioni.
6
In alcuni casi, può essere necessario introdurre elementi vuoti sia per il tag di
inizio degli elementi appartenenti a gerarchie secondarie, che per quello di ne .
Le linee guida TEI, che descrivono la tecnica, chiamano milestones gli elementi
vuoti.
Questa tecnica è particolarmente conveniente da adottare nelle applicazioni di
data capture e, più in generale, in contesti di semplice scansione sequenziale dei
documenti [7].
Inoltre, vi è dierenza tra l'elaborazione/validazione in XML
della gerarchia principale, che è evidente, e quella delle gerarchie secondarie,
che devono prima essere decodicate.
Utilizzando le milestones, l'elemento rappresentato con questo approccio si appiattisce nell'albero XML, ed è necessario utilizzare del software specico per il
suo riconoscimento e la ricostruzione della sua struttura.
Per vedere l'appiattimento dovuto all'utilizzo delle milestones, utilizziamo
l'esempio in [10] creando un piccolo albero XML:
<TEI>
...
<l>
<sp>
<speaker>Tibère</speaker>
Poursuivez...
</sp>
<sp>
<speaker>Agrippine</speaker>
Quoi, Seigneur?
</sp>
<sp clix:role=start-range clix:sID=sp1 />
Le propos détestable
</l>
<l>
où je vous ai surprise.
<sp clix:role=end-range clix:eID=sp1 />
<sp clix:role=start-range clix:sID=sp2 />
A ! Ce propos damnable
</l>
<l>
d'une si grande horreur tous mes sens travailla
<sp clix:role=end-range clix:eID=sp2 />
</l>
...
</TEI>
Un semplice albero potrebbe essere:
7
Dove, all'interno dei rettangoli rossi, è evidente l'appiattimento degli elementi
espressi con milestones.
Inoltre, nessun elemento XML rappresenta esplicitamente il materiale delle gerarchie secondarie. L'elaborazione con strumenti XML, quindi, aumenta di complessità, in quanto le gerarchie secondarie non sono rappresentate uniformemente da nodi nell'albero del documento. Esse devono essere necessariamente
ricostruite con software ad hoc.
2.3.2
Flattened
L'approccio attened esprime ogni elemento del documento tramite milestones,
sia la gerarchia principale che le gerarchie secondarie, indipendentemente dal
fatto che gli elementi siano in overlap tra loro oppure no.
Con questa tecnica vengono sicuramente risolti tutti gli overlap.
Tuttavia l'approccio Flattened condivide con le Milestones i problemi di appiattimento dell'albero XML, magnicati dal fatto che l'appiattimento si riscontra
non solo sugli elementi eettivamente in overlap, ma sull'intero documento; la
dicoltà nel riconoscimento e nell'elaborazione delle gerarchie, anche in questo
caso applicabile a tutte le gerarchie, non solo a quelle in overlap. In più saltano
le gerarchie di dominanza, che devono essere ricostruite con software specico.
Esempio (sempre da [10]):
8
<clix:clix>
<TEI clix:role="start-range" clix:sID="tei01" />
<teiHeader clix:role="start-range" clix:sID="h01" />
...
<teiHeader clix:role=end-range" clix:eID="h01" />
<text clix:role="start-range" clix:sID="t01" />
<body clix:role="start-range" clix:sID="b01" />
<l clix:role="start-range" clix:sID="l01" />
<sp clix:role="start-range" clix:sID="sp01" />
<speaker clix:role="start-range" clix:sID="spk01" />
Tibère
<speaker clix:role="end-range" clix:eID="spk01" />
Poursuivez ...
<sp clix:role="end-range" clix:eID="sp01" />
Agrippine
Quoi, Seigneur?
<sp clix:role="end-range" clix:sID="sp02" />
Tibère
<l clix:role="end-range" clix:eID="l01" />
où je vous ai surprise .
Agrippine
Ah! Ce propos damnable
<body clix:role="end-range" clix:eID="b01" />
<text clix:role="end-range" clix:eID="t01" />
<TEI clix:role="end-range" clix:eID="tei01" />
</clix:clix >
2.3.3
Fragmentation
Quando un elemento che appartiene ad un vocabolario secondario si sovrappone
ad elementi appartenenti al vocabolario primario, è spezzato in tanti piccoli
frammenti quanti sono necessari a risolvere la sovrapposizione.
Come per l'approccio milestones, viene scelta una gerarchia dominante.
Gli
elementi delle altre gerarchie sono rappresentati normalmente, sempre che si
inseriscano correttamente all'interno della gerarchia dominante. Se un elemento
subordinato si estende oltre i propri limiti sovrapponendosi ad un elemento
della gerarchia dominante, l'elemento subordinato è spezzato in tanti frammenti
quanti sono necessari per far sì che ogni frammento sia correttamente annnidato
agli elementi della gerarchia dominante.
9
Vengono utilizzate opportune convenzioni sintattiche per distinguere tra elementi parziali e non parziali e per riconoscere i frammenti di uno stesso elemento,
come ad esempio attributi specici.
Per combinare gli elementi facilitando la costruzione delle gerarchie secondarie
si possono introdurre meccanismi di concatenazione (virtual join ), utilizzando
appositi attributi prev e next.
Altri approcci più semplici permettono di suddividere il testo in parti con i valori
I (iniziale), M (medio), F (nale), utilizzando l'attributo prev. Questo metodo,
però, può necessitare di elaborazioni con software specico per stabilire quali
elementi delle singole parti debbano essere combinati con quali e soprattutto
in quale ordine, cosa che il parser XML non può assicurare.
Ciò che invece
è identicato correttamente dal parser è l'annidamento e la correttezza delle
aperture/chiusure dei tag della gerarchia principale e delle gerarchie secondarie,
e questo, secondo Spielberg-McQueen e Huitfeld ([7]), rende la Fragmentation
preferibile alle Milestones.
Mutuando l'esempio di fragmentation da [10]:
<TEI>
...
<l>
<sp>
Poursuivez ...
</sp>
<sp>
Quoi , Seigneur ?
</sp>
<sp xml:id="sp1.1" next="sp1.2">
</sp>
</l>
<l>
<sp xml:id="sp1.2">
</sp>
<sp xml:id="sp2.1" next="sp2.2">
Ah ! Ce propos damnable
</sp>
</l>
<l>
<sp xml:id="sp2.2">
</sp>
</l>
...
</TEI>
Un problema di questo approccio è che, molto spesso, la codica avrà un numero
di elementi maggiore di quelli che eettivamente si intende rappresentare. Ciò
è molto evidente nell'esempio in [4]:
10
il brano originale:
<l>Scorn not the sonnet; critic, you have frowned,</l>
<l>Mindless of its just honours; with this key</l>
<l>Shakespeare unlocked his heart; the melody</l>
<l>Of this small lute gave ease to Petrarch's wound.</l>
Espresso con fragmentation :
<l>
<seg
<seg
</l>
<l>
<seg
<seg
</l>
<l>
<seg
<seg
</l>
<l>
<seg
</l>
n="sentence1">Scorn not the sonnet;</seg>
n="sentence2">critic, you have frowned,</seg>
n="sentence2">Mindless of its just honours;</seg>
n="sentence3">with this key</seg>
n="sentence3">Shakespeare unlocked his heart;</seg>
n="sentence4">the melody</seg>
n="sentence4">Of this small lute gave ease to Petrarch's wound.</seg>
dove ci sono ben 7 istanze dell'elemento seg (segmento) rappresentante i versi,
e solo 4 versi di fatto esistenti.
L'esempio precedente permette anche di rilevare un secondo problema:
da
un punto di vista semantico si nota che pochissime sentence possono essere
riconosciute come frasi dal punto di vista linguistico.
La combinazione dei due problemi, in particolare, può rendere particolarmente
dicile l'analisi automatica del testo. Un sistema automatico che volesse contare
le frasi della poesia dell'esempio precedente, potrebbe restituire un risultato non
corretto.
2.3.4
Twin documents
Nell'approccio Twin Documents ogni gerarchia è un documento XML distinto,
con la propria struttura ad albero.
Concettualmente questo è il metodo più
semplice per risolvere gerarchie in overlap.
Non è necessario scegliere alcuna gerarchia principale, e non sono necessari strumenti particolari per esaminare separatamente ogni gerarchia. Le informazioni
sono rappresentate esplicitamente nei dati, ed i singoli documenti possono essere
elaborati senza grossi sforzi con strumenti XML.
11
I problemi di questo approccio vanno ricercati nel fatto che è necessario mantenere copie multiple dello stesso contenuto testuale (ciò può portare ad inconsistenze), e manca la possibilità di descrivere relazioni tra le gerarchie.
Inoltre, trovando in ogni documento markup profani diversi su markup sacri
comuni, potrebbe essere impossibile stabilire un ordine tra i tag profani appartenenti a due gerarchie diverse, nel caso volessimo unire due documenti in
uno solo.
Esempio (sempre da [10]):
<TEI> <! -- verse vocabulary -- >
<teiHeader> ... </teiHeader>
<text>
<body>
<l>
Poursuivez ...
Quoi, Seigneur ?
</l>
<l>
Ah! Ce propos damnable
</l>
<l>
</l>
</body>
</text>
</TEI>
<TEI> <! -- performance vocabulary -- >
<teiHeader> ... </teiHeader>
<text>
<body>
<sp>
Poursuivez ...
</sp>
<sp>
<speaker> Agrippine </speaker>
Quoi, Seigneur?
</sp>
<sp>
Le propos détestable où je vous ai surprise .
</sp>
<sp>
<speaker> Agrippine </speaker>
Ah! Ce propos damnable d'une si grande horreur tous mes sens travailla
</sp>
</body>
</text>
</TEI>
12
2.3.5
Stand-o markup
Lo Stand-o Markup è una tecnica che associa ad un documento sorgente uno o
più documenti esterni, ognuno con il proprio markup. Questi documenti esterni
puntano a porzioni del documento sorgente.
In altre parole, viene eettuata
una separazione tra il testo e gli elementi usati per descriverlo, i quali non
contengono nessuna parte del testo della gerarchia principale, ma includono
semplicemente dei riferimenti.
Le linee guida TEI raccomandano l'utilizzo di
meccanismi XInclude/XPointer deniti nel W3C, oppure semplici puntatori.
Secondo gli standard adottati attualmente, i documenti esterni possono essere
inseriti in apposite sezioni all'interno dello stesso le del documento principale.
Ecco un esempio.
Dato questo documento sorgente:
<root>
<speaker xml:id="spk01">Tibère</speaker>
Poursuivez ...
<speaker xml:id="spk02">Agrippine</speaker>
Quoi, Seigneur ?
<speaker xml:id="spk03">Tibère</speaker>
<speaker xml:id="spk04">Agrippine</speaker>
Ah ! Ce propos damnable
</root>
Questi potrebbero essere documenti esterni:
<TEI> 
...
<l>
<xinclude href="source.xml" xpointer="xpath1(id('spk01'))"/>
<xinclude href="source.xml" xpointer="string-range(xpath1(id('spk01')),0,13)"/>
<xinclude href="source.xml" xpointer="string-range(xpath1(id('spk03')),0 ,19)"/>
</l>
<l>
</l>
<l>
<xinclude href ="source.xml" xpointer="string-range(xpath1(id('spk04')),24,47)"/>
</l>
...
</TEI>
<TEI> 
...
<sp>
13
</sp>
<sp>
</sp>
<sp>
<xinclude href="source.xml" xpointer="xpath1(xpath1(id('spk03'))"/>
<xinclude href="source.xml" xpointer="string-range(xpath1(id('spk03'))),0,42)"/>
</sp>
<sp>
<xinclude href="source.xml" xpointer="string-range(xpath1(id('spk04')),0,70) "/>
</sp>
...
</TEI>
Questo approccio è utile quando si ha a che fare con testi che non permettono
l'inserimento di tag addizionali, oppure testi soggetti all'applicazione di numerose gerarchie secondarie incompatibili tra loro. Altri scenari di applicazione
possono essere singoli schemi che necessitino di risolvere ambiguità gerarchiche
multiple, rendendo impossibile applicare una sola gerarchia secondaria.
Applicando lo stand-o markup è possibile annotare un documento in sola lettura; è possibile distribuire i le di annotazione senza distribuire il testo sorgente; elementi discontinui possono essere combinati in una annotazione singola;
soggetti dierenti possono produrre indipendentemente annotazioni dierenti;
dierenti le di annotazione possono contenere dierenti livelli di informazione.
Inoltre l'approccio è elegante.
Tra gli svantaggi possiamo rilevare il fatto che nuove annotazioni possono richiedere
interpretazioni (ed elaborazioni) nuove e disgiunte da quelle già costruite per le
precedenti annotazioni. Anche se tutte le informazioni delle gerarchie fossero incluse, l'informazione sarebbe comunque dicile da elaborare utilizzando i metodi generici XML. Secondo Spielberg-McQueen e Huitfeld [7], inoltre, l'approccio stand-o non permette agevolmente di vericare se il markup eettivamente
rispetti i vincoli espressi in un DTD.
14
2.4 Vantaggi e svantaggi di ogni approccio
Sia Spielberg-McQueen e Huitfeld, in [7], che le linee guida TEI, in [4] che
Jeni Tennison, in [13], puntualizzano i vantaggi e gli svantaggi di ogni tecnica.
Proviamo a rappresentare, in forma matriciale, un compendio delle osservazioni:
Approccio
Vantaggi
Svantaggi
Milestones
è facile identicare la
viene favorita una
gerarchia principale
gerarchia a discapito delle
altre
è facile elaborare la
è dicile identicare il
gerarchia principale con
contenuto delle gerarchie
strumenti XML
in overlap
è dicile elaborare le
gerarchie in overlap con
strumenti XML
Flattened
relativa facilità di
è dicile identicare il
applicazione dell'
approccio per la
risoluzione
dell'overlapping
nessuna gerarchia è
possibili problemi nelle
predominante rispetto
relazioni di dominanza,
alle altre
da ricostruire
gerarchie con strumenti
standard XML
è dicile editare le
gerarchie senza strumenti
costruiti ad hoc
Fragmentation
è facile identicare la
viene favorita una
gerarchia principale
gerarchia a discapito delle
altre
è facile elaborare la
possibili problemi nelle
gerarchia principale con
relazioni di contenimento
strumenti XML
è facile validare il
può portare ad elementi
documento
fortemente discontinui
l'elaborazione del
in overlap può non essere
agevole
15
Approccio
Vantaggi
Svantaggi
inadatto all'elaborazione
di documenti con requisiti
di ordinamento
particolari
Twin Documents
tutte le gerarchie sono
il contenuto si ripete in
facilmente identicabili
ogni documento
è dicile allineare le
strutture
è dicile eettuare analisi
incrociate tra le strutture
costruiti ad hoc
Stand-o Markup
nessuna gerarchia è
è dicile identicare le
predominante
gerarchie
permette di eettuare
markup su documenti in
gerarchie con strumenti
read-only
standard XML
le gerarchie secondarie
possono essere prodotte
da soggetti diversi in
costruiti ad hoc
tempi diversi
le gerarchie secondarie,
è dicile validare le
essendo disgiunte,
gerarchie con DTD
possono essere distribuite
indipendentemente dal
documento sorgente
maggiore espressività ed
eleganza
Si possono quindi identicare quattro aspetti importanti che devono essere
necessariamente presi in considerazione nella scelta del tipo di approccio da
utilizzare per risolvere il problema dell'overlap in XML:
1. La facilità con cui l'approccio scelto permette di rappresentare tipi dierenti di overlap o di eettuare compiti specializzati. La scelta di utilizzare
una tecnica a discapito di un'altra dipende fortemente dal tipo di overlap
da gestire. Ad esempio la possibilità di gestire self-overlapping, che manca
nell'approccio Twin Documents, a meno di aver a che fare con un numero
variabile di documenti che aumenta in ragione di quanto self-overlap è
presente. Se si ha a che fare con elementi discontinui, invece, la Fragmen-
tation è naturalmente il metodo migliore. Lo Stand-o Markup, dal canto
16
suo, permette di eettuare annotazioni su documenti scritti da altri senza
necessariamente avere permessi di scrittura su di essi.
2. La capacità di generare documenti facilmente modicabili (editabili). Sicuramente gli approcci Milestones e Fragmentation permettono di generare le con una modicabilità (anche manuale) paragonabile all'XML. Gli
approcci Stand-o Markup e Twin Documents, invece, richiedono strumenti di editing specici sia per la gestione del markup che per la modica dei
contenuti.
3. L'applicabilità di strumenti standard XML per l'elaborazione dei documenti. Ad esempio, è molto più facile elaborare con XLST dei documenti
in formato Milestones o Fragmented piuttosto che avere a che fare con un
approccio Twin Documents, Stand-o Markup o Flattened. In questi casi
è utile adarsi ad un processo di conversione del documento in un formato
più adatto (alcuni meccanismi di traduzione sono descritti in [10]). Un altro esempio è la validazione dei le con DTD, che nell'approccio Stand-o
Markup è particolarmente disagevole.
4. Alcuni approcci livellano le gerarchie, rendendo impossibile capire se ve
ne sia una predominante rispetto alle altre, ma questo potrebbe non essere desiderabile, ad esempio nel caso di gestione del change tracking: è
chiaro che esiste una gerarchia principale (il contenuto) e gerarchie secondarie (i commenti e le revisioni), e questo rende gli approcci Milestones e
Fragmentation i più adatti.
In ultima analisi, non sembra esserci un approccio migliore degli altri per i
documenti XML. La scelta della tecnica da utilizzare è fortemente condizionata
dal tipo di overlap e dal tipo di documento da gestire.
Questo è anche riportato nelle linee guida TEI [4]:
al momento non sembra
ancora esistere una soluzione al problema che racchiuda in sè semplicità formale,
capacità nel rappresentare tutte le strutture possibili, facilità nella validazione
formale e/o automatica.
Al più è possibile mediare tra vantaggi e svantaggi
delle soluzioni conosciute.
17
3 Il change tracking e l'overlapping - considerazioni generali
La gestione del change tracking può essere denita come tutto quell'insieme di
tecniche che gestiscono le modiche apportate su un determinato documento da
soggetti diversi in tempi diversi. Questo include il supporto alla creazione e visualizzazione delle modiche, alla possibilità di accettarle, correggerle, scartarle,
ed alla possibilità di inserire commenti.
Generalmente, una modica può essere:
•
un inserimento, quando si aggiunge del contenuto ad un testo esistente o
alla sua struttura/formato
•
una cancellazione, quando si toglie contenuto o formattazione.
In caso
di cancellazione, è opportuno un meccanismo che memorizzi cosa è stato
cancellato.
Le operazioni di revisione (accettazione o scarto delle modiche) necessitano
di un strato di meta-informazioni che associno l'operazione di modica ad un
determinato soggetto. Per semplicità tralasceremo le problematiche di autenticazione/autorizzazione, che esulano dallo scopo di questa trattazione.
L'aggiunta di commenti è un'operazione dierente.
Il word processor li deve
visualizzare in una forma speciale, e, generalmente, sono trattati come entità
separate dal resto del testo (anche se collegate ad esso). Necessitano anch'esse
di uno strato di meta-informazioni per, ad esempio, l'identicazione dell'autore.
Scenari più complessi possono comprendere uno strato di supporto al change
tracking anche per quanto riguarda i commenti, e possibilità di visualizzare lo
stato del documento in un determinato istante di tempo, rendendo necessario
introdurre un meccanismo di ordinamento coerente di tutti gli elementi, tramite
contatori e/o timestamp.
Le speciche Open Oce Document Format e Oce Open XML non si limitano a descrivere i meccanismi di change tracking per i documenti word, ma
esplorano il problema anche per i fogli di calcolo e di presentazione.
Nella presente trattazione, per semplicità, verrà dato risalto principalmente ai
documenti word.
Dal punto di vista dell'overlapping, anche alla luce del capitolo precedente, sulla
problematica del change tracking possiamo fare le seguenti considerazioni:
18
•
è presente una gerarchia principale (il testo da modicare)
•
sono presenti una o più gerarchie secondarie (le modiche, i commenti/annotazioni, le autorizzazioni)
•
i pezzi di testo all'interno delle gerarchie potrebbero godere di proprietà
di ordinamento
•
la necessità di avere strumenti ad hoc per l'editazione dei documenti creati
è naturalmente soddisfatta dai word-processor stessi
In merito all'ultimo punto, potrebbero esserci (e, allo stato attuale, eettivamente ci sono) dei problemi per quanto riguarda l'editazione di documenti XML
scritti con un word processor da parte di un altro word processor. Sebbene siano
già stati implementati meccanismi di traduzione da un formato all'altro, il problema della loro correttezza e completezza e senz'altro da approfondire, ma esula
lo scopo del presente documento.
19
4 Il formato dati del change tracking in ODF
(Open Document Format)
I meccanismi di change tracking del formato Open Document Format sono
descritti nello standard ODF da OASIS (Organization for the Advancement
of Structured Information Standards). OASIS è un consorzio no-prot per lo
sviluppo, la convergenza e l'adozione di standard aperti per la società mondiale
dell'informazione.
Il documento relativo allo standard adottato da OpenOce.org e da altre suite
oce è descritto nella specica Open Document Format for Oce Applications (OpenDocument) v1.1, approvata nel febbraio 2007. La sezione 4.6 della
specica descrive come debbano essere rappresentate le modiche ai documenti.
L'XML-Schema usato per descrivere la specica è espresso in linguaggio Relax
NG [12].
4.1 Cenni sulla struttura dei documenti Open Document
Format
Nella specica Open Document Format, ogni componente della struttura è rappresentato da un elemento ed i suoi attributi. La struttura di un documento si
applica a tutti i tipi di documento previsti: non vi è dierenza tra un documento
di testo, un foglio di calcolo od un disegno, tranne che nel contenuto.
Gli elementi principali sono i seguenti:
•
Document Root (uno o più di uno)
•
Metadati
•
Body Element
•
Congurazioni
•
Script
•
Dichiarazioni dei font utilizzati
•
Stili e layout
I Document Root sono gli elementi principali di un documento in formato Open
Document.
Possono esservi due modalità di rappresentazione di un documento:
20
•
unico le XML
•
insieme di diversi sottodocumenti all'interno di un package, ognuno dei
quali memorizza parte del documento completo.
Ogni sottodocumento
rappresenta un particolare aspetto del documento.
<oce:document>
Nel primo caso, il documento ha un unico root element (
);
diversamente sono presenti più Root Element, uno per ogni sottodocumento
(<oce:document-content> per il contenuto, <oce:document-styles> per gli
stili utilizzati - se diversi da quelli standard, <oce:document-meta> per le
metainformazioni del documento, <oce:document-settings> per le congurazioni speciche dell'applicazione).
I Metadati sono le informazioni generali sul documento, come ad esempio l'autore o la data e l'ora dell'ultimo salvataggio.
Sono contenuti in un apposita
Document Root.
Il Body Element contiene un elemento per indicare il tipo di contenuto del
documento. Nella specica sono modellati i seguenti contenuti:
•
documenti di testo
•
documenti di disegno
•
documenti di presentazione
•
fogli di calcolo
•
graci
•
immagini
Per lo scopo della presente trattazione, ci focalizzeremo sul formato dei
documenti di testo. Questo è lo schema del contenuto all'interno del Body
Element per i documenti di testo:
<define name="office-body-content" combine="choice">
<element name="office:text">
<ref name="office-text-attlist"/>
<ref name="office-text-content-prelude"/>
<zeroOrMore>
<ref name="office-text-content-main"/>
</zeroOrMore>
<ref name="office-text-content-epilogue"/>
</element>
</define>
21
Il contenuto di un documento di testo può consistere di una sequenza di paragra, tabelle, indici, nestre di testo, sezioni di testo ed elementi graci. In più,
un documento di testo può contenere moduli, informazioni di change tracking e
dichiarazioni di variabili.
Alcuni di questi dati (change tracking, dati relativi ai moduli, dichiarazione di
variabili) sono contenuti all'interno di un elemento chiamato Prelude:
<define name="office-text-content-prelude">
<ref name="office-forms"/>
<ref name="text-tracked-changes"/>
<ref name="text-decls"/>
<ref name="table-decls"/>
</define>
Il resto dei dati, ovvero la parte del documento vera e propria, può essere
trovata all'interno dell'elemento oce-text-content-main:
<define name="office-text-content-main">
<choice>
<zeroOrMore>
<ref name="text-content"/>
</zeroOrMore>
<group>
<ref name="text-page-sequence"/>
<zeroOrMore>
<choice>
<ref name="draw-a"/>
<ref name="shape"/>
</choice>
</zeroOrMore>
</group>
</choice>
</define>
Verichiamo il contenuto dell'elemento text-content, perchè ricorrerà più volte
nel corso della trattazione:
<define name="text-content">
<choice>
<ref name="text-h"/>
<ref name="text-p"/>
<ref name="text-list"/>
<ref name="text-numbered-paragraph"/>
<ref name="table-table"/>
<ref name="draw-a"/>
<ref name="text-section"/>
<ref name="text-soft-page-break"/>
<ref name="text-table-of-content"/>
<ref name="text-illustration-index"/>
<ref name="text-table-index"/>
<ref name="text-object-index"/>
<ref name="text-user-index"/>
<ref name="text-alphabetical-index"/>
<ref name="text-bibliography"/>
<ref name="shape"/>
<ref name="change-marks"/>
</choice>
</define>
Possiamo notare che non è necessario che il testo all'interno di un documento
contenga un paragrafo.
22
4.2 La lista delle modiche
Tutti i cambiamenti ad un documento sono memorizzati in una lista, che
contiene un elemento per ogni modica apportata al documento. La lista è
coontenuta all'interno dell'elemento
<text:tracked-changes>
Se l'elemento è assente, il change tracking non è stato attivato per il documento.
Lo schema dell'elemento tracked-changes è il seguente
<define name="text-tracked-changes">
<optional>
<element name="text:tracked-changes">
<ref name="text-tracked-changes-attr"/>
<zeroOrMore>
<ref name="text-changed-region"/>
</zeroOrMore>
</element>
</optional>
</define>
All'interno dell'elemento possiamo avere una o più text-changed-region, ovvero
la lista dei cambiamenti apportati al testo:
<define name="text-changed-region">
<element name="text:changed-region">
<ref name="text-changed-region-attr"/>
<ref name="text-changed-region-content"/>
</element>
</define>
Ogni elemento ha un ID. In particolare, gli elementi che marcano l'inizio e la
ne di una regione usano l'ID per identicare la regione alla quale
appartengono:
<define name="text-changed-region-attr" combine="interleave">
<attribute name="text:id">
<ref name="ID"/>
</attribute>
</define>
4.3 Tipologie di modiche
Nella specica Open Document Format sono modellate 3 tipologie di modiche:
•
inserimenti
23
•
cancellazioni
•
modiche di formato
Queste tipologie vengono modellate all'interno del text-changed-region-content.
Vediamole una per una.
4.3.1
Inserimenti
Gli inserimenti di testo sono identicati dal tag <text:insertion>. Questo elemento contiene tutte le informazioni necessarie all'identicazione del contenuto
inserito.
Il contenuto inserito può rientrare in diverse casistiche. Può essere:
•
un semplice brano di testo all'interno di un paragrafo
•
un intero paragrafo
•
una tabella
Il contenuto inserito è parte del documento di testo ed è identicato, con la
tecnica dele milestones, da un elemento vuoto start ed un elemento vuoto end.
Ecco lo schema:
<define name="text-changed-region-content" combine="choice">
<element name="text:insertion">
<ref name="office-change-info"/>
</element>
</define>
L'esempio che segue è diviso in due parti: nella prima è presente il contenuto
della lista delle modiche, con tutte le metainformazioni; nella seconda parte,
separata dalla prima da una linea vuota, c'è la sezione del documento che è
interessata dalla modica:
<text:changed-region text:id="c001">
<text:insertion>
<office:change-info>
<dc:creator>Michael Brauer</dc:creator>
<dc:date>1999-05-18T12:56:04</dc:date>
</office:change-info>
</text:insertion>
</text:changed-region>
</text:tracked-changes>
<text:p>
This is the original text<text:change-start text:change-id="c001"/>,
but this has been added<text:change-end text:change-id="c001"/>.
</text:p>
24
Nell'esempio possiamo notare le metainformazioni nella lista delle modiche (chi
ha apportato la modica - l'inserimento - ed il timestamp). Nel testo vediamo
gli elementi milestones che delimitano l'inizio e la ne dell'inserimento.
4.3.2
Cancellazioni
Le cancellazioni sono identicate dal tag <text:deletion>, che contiene il testo
cancellato. La posizione, all'interno del documento, del testo cancellato è identicata da un apposito elemento <text:change text:region-id=xxx />
Lo schema:
<element name="text:deletion">
<zeroOrMore>
<ref name="text-content"/>
</zeroOrMore>
</element>
</define>
Nell'esempio che segue è stata eettuata la cancellazione del testo , but this
has been deleted, che si trova nell'elemento <text:p>
<text:changed-region text:id="c002">
<text:deletion>
<dc:creator>Michael Brauer</dc:creator>
<dc:date>1999-05-18T12:56:04</dc:date>
<text:p>, but this has been deleted</text:p>
</text:deletion>
<text:p>
This is the original text<text:change text:region-id="c002"/>.
</text:p>
Anche in questo caso possiamo notare le metainformazioni nella parte della
lista delle modiche.
Diversamente dall'inserimento, abbiamo anche il testo
cancellato, contenuto nei tag <text:p>.
Nella parte del testo, abbiamo una milestone che identica la posizione del testo
cancellato, con un riferimento (l'attributo region-id) che rimanda direttamente
al nodo relativo nella lista delle modiche.
Nel caso in cui il testo cancellato debba essere inserito nuovamente nel documento, esso verrà posizionato nel punto esatto della milestone di cancellazione.
25
Come viene sottolineato nella sezione 4.6.4 della specica [11], possiamo notare
che il testo cancellato presente nella sezione della lista delle modiche viene
incluso nei tag <text:p></text:p>, anche se, prima della modica, non faceva
parte di un paragrafo a sè stante. Questa è una regola dettata dalla specica.
Nel caso di reinserimento del testo cancellato, emergono tre scenari:
•
se la milestone di cancellazione si trova all'interno di un paragrafo, si
reintroduce il testo cancellato ignorando i tag di paragrafo aggiunti nella
lista delle modiche;
•
se la milestone di cancellazione si trova all'interndo di un header, ci si
comporta come nel caso precedente adattando opportunamente i tag di
ne allo specico header
•
in tutti gli altri casi si copia l'intero testo cancellato, compresi i tag di
paragrafo.
4.3.3
Cambiamenti di formato
I cambiamenti di formato sono tutte le modiche che possano essere apportate
agli attributi di formattazione. La regione dove questi cambiamenti avvengono
viene marcata da milestones di inizio e ne.
Diversamente dai casi precedenti, la specica non prevede la memorizzazione
dei dati di formato modicati all'interno della lista dei cambiamenti.
Ecco lo schema:
<element name="text:format-change">
</element>
</define>
4.4 Le metainformazioni del change tracking
Le metainformazioni del change tracking sono memorizzate all'interno dell'
elemento change-info.
Questo elemento contiene l'autore e la data di creazione di una determinata
modica catturata dai meccanismi di supporto al change tracking. Può anche
contenere commenti opzionali.
Ecco lo schema:
26
<define name="office-change-info">
<element name="office:change-info">
<ref name="dc-creator"/>
<ref name="dc-date"/>
<zeroOrMore>
<ref name="text-p"/>
</zeroOrMore>
</element>
</define>
L'autore e la data sono rispettivamente specicati all'interno di dc-creator e
dc-date. I commenti trovano posto all'interno di paragra.
27
5 Il formato dati del change tracking in OOXML
(Oce Open XML - Microsoft)
Il formato dei le OOXML è descritto nello Standard ECMA-376. Il formato
OOXML è diventato standard ISO (ISO/IEC DIS 29500) nel marzo del 2008.
La versione più recente dello standard, tecnicamente allineata con lo standard
ISO, è la seconda, del dicembre 2008.
La Ecma International è un'associazione di industrie dedicata alla standardizzazione dell'Informazione e dei sistemi di comunicazione.
5.1 Cenni sulla struttura dei documenti OOXML
Lo standard Oce Open XML denisce i formati dei documenti di word-processing,
dei fogli di calcolo e delle presentazioni. Ogni tipo di documento è specicato
attraverso un suo linguaggio di markup primario: WordprocessingML, SpreadsheetML o PresentationML. Ogni linguaggio può comunque incorporare parti
espresse in altri linguaggi primari, ed anche parti espresse in altri linguaggi.
Un documento espresso in linguaggio WordProcessingML è composto di un
insieme di piani (stories ), ognuno dei quali può essere [3]:
•
il documento principale (main document)
•
il glossario
•
un sottodocumento
•
un header
•
un footer
•
un commento
•
un frame
•
una casella di testo
•
una nota a piè di pagina
•
una nota nale
Ognuno di questi piani è generalmente inserito in un documento XML specico.
Tutti i documenti XML dei piani sono inseriti all'interno dello stesso pacchetto
compresso docx.
L'unico piano obbligatorio è il documento principale, sito nel le document.xml.
Gli elementi XML che tipicamente lo compongono sono:
28
•
•
document - l'elemento radice del documento principale
body - il corpo del documento, che può contenere diversi paragra ed una
sezione di proprietà
•
p - il paragrafo. Può contenere una o più run (r). Il run è un brano di testo
contiguo avente le stesse identiche proprietà, senza markup aggiuntivi. E'
generalmente espresso tramite dei range.
•
t - range di testo.
Contiene una quantità arbitraria di testo senza for-
mattazioni, interruzioni di linea, tabelle, immagini o altro materiale non
testuale. La formattazione del testo è ereditata dalle proprietà di run e di
paragrafo.
Sempre in [3]possiamo vedere la parte document di un documento minimale in
WordprocessingML, che ci dà un'idea iniziale di come appaiono i documenti in
OOXML:
<w:document xmlns:w="http://schemas.openxmlformats.org/wordprocessingml/2006/main">
<w:body>
<w:p>
<w:r>
<w:t>Hello, world.</w:t>
</w:r>
</w:p>
</w:body>
</w:document>
Possiamo vedere tutte le parti del documento:
l'elemento radice, il body, il
paragrafo, il run, che, al suo interno, ospita il range.
All'interno di un paragrafo, tutta la formattazione del paragrafo stesso è memorizzata nell'elemento pPr (paragraph properties).
Come i paragra, anche i run possono avere una formattazione specica, che è
specicata all'interno dell'elemento rPr (run properties).
5.2 Le annotazioni
Le annotazioni costituiscono la base della struttura di versionamento dei documenti OOXML. Il termine fa riferimento ai diversi tipi di markup supplementare che possono essere memorizzati attorno o all'interno di una regione di
testo all'interno di un documento (es.: commenti, revisioni, errori grammaticali,
autorizzazioni, etc..)
All'interno di un documento, le annotazioni sono memorizzate in uno dei seguenti metodi:
29
•
Inline
•
Cross Structure
•
Proprietà
5.2.1
Annotazioni Inline
Le annotazioni inline descrivono tutte le annotazioni che non richiedono particolari accorgimenti al ne di mantenere la buona formattazione dell'XML
risultante dall'output del word processor.
In questi casi, un singolo elemento XML deve incapsulare l'intero contenuto del
documento che si sta annotando.
Esempio:
<w:p>
<w:r>
<w:t xml:space="preserve">The quick brown fox jumps over the </w:t>
</w:r>
<w:del ... >
<w:r>
<w:delText>lazy</w:delText>
</w:r>
</w:del>
<w:ins ... >
<w:r>
<w:t>jet lagged</w:t>
</w:r>
</w:ins>
<w:r>
<w:t xml:space="preserve"> dog.</w:t>
</w:r>
</w:p>
L'esempio descrive il change tracking di una modica: la parola lazy viene
sostituita da jet lagged. Gli elementi del e ins sono completamente incapsulati
all'interno delle loro rispettive annotazioni inline (<w:del ...> e <w:ins ...>)
Questa tipologia di annotazioni fa uso di una versione semplicata dell'approccio fragmentation.
La semplicazione deriva dal fatto che non sono presen-
ti, per specica, situazioni nelle quali i segmenti debbano essere ulteriormente
frammentati per mantenere la buona formattazione dell'XML.
5.2.2
Annotazioni Cross Structure
Le annotazioni Cross structure descrivono la classe di annotazioni che si può
estendere su altre porzioni di markup. In questi casi, la regione dell'annotazione
30
è delimitata da due elementi: un elemento di partenza (start-element) ed un
elemento di ne (end-element).
Un esempio:
<w:p>nagy
<w:r>
<w:t>Example</w:t>
</w:r>
<w:bookmarkStart w:id="0" w:name="sampleBookmark" />
<w:r>
<w:t xml:space="preserve"> text.</w:t>
</w:r>
</w:p>
<w:p>
<w:r>
<w:t>Example</w:t>
</w:r>
<w:bookmarkEnd w:id="0" />
<w:r>
</w:r>
</w:p>
Nell'esempio viene assegnato un segnalibro che si estende dalla seconda parola
del primo paragrafo alla prima parola del secondo praragrafo. Gli elementi vuoti
bookmarkStart e bookmarkEnd identicano la parte interessata dal segnalibro.
L'attributo w:id identico specica che si tratta di due elementi correlati.
Si può facilmente notare come questa tipologia di annotazioni applichi approccio
milestones.
5.2.3
Annotazioni di proprietà
Le annotazioni di proprietà sono la classe di annotazioni che sono memorizzate
come proprietà di un oggetto.
In questi casi, la semantica dell'annotazione è
denita dalla proprietà, che può inuire sul contenuto e/o sulla formattazione.
Un esempio:
<w:p>
<w:r>
<w:rPr>
<w:b/>
<w:rPrChange ... >
<w:rPr/>
</w:rPrChange>
</w:rPr>
<w:t>Example</w:t>
</w:r>
<w:r>
</w:r>
</w:p>
31
In questo caso è stata modicata una proprietà dei caratteri della parola Example, che diventa scritta in grassetto.
L'elemento rPrChange contiene l'insieme delle proprietà di revisione applicate
precedentemente ed associate ad un particolare autore in un particolare momento. E' memorizzato come una proprietà sul run padre che è stato modicato.
5.3 il supporto al change tracking e le tipologie di modica
Nella specica OOXML, il supporto al change tracking viene descritto come
un meccansimo per memorizzare informazioni in merito all'evoluzione del documento.
Quando un'applicazione aggiunge delle revisioni ad un documento
WordprocessingML, vengono generalmente memorizzati:
•
lo stato corrente del documento
•
lo stato iniziale del documento
Una revisione consiste di due speciche tipologie di informazione:
•
il tipo di modica (specicato tramite il nome dell'elemento di revisione)
•
un identicatore unico
•
l'autore della revisione (opzionale)
•
la date e l'ora della revisione (opzionale)
I tipi di modica possono essere i seguenti:
•
inserimenti
•
cancellazioni
•
spostamenti
•
modiche di attributi/proprietà
Ognuna di queste tipologie di modica possono essere applicate ai seguenti
contesti:
•
run
32
•
paragra
•
caratteri matematici
•
righe di tabelle
•
celle di tabelle (anche l'operazione di merge)
•
markup XML personalizzato
5.3.1
Inserimento di un run
L'elemento ins racchiude al proprio interno ciò che è stato aggiunto a del testo
esistente durante un'operazione tracciata come revisione.
Consideriamo un paragrafo di testo al quale è stata aggiunta una parola:
<w:p>
<w:r>
<w:t>Some</w:t>
</w:r>
<w:ins w:id="0" w:author="Joe Smith" w:date="2006-03-31T12:50:00Z">
<w:r>
<w:t>text</w:t>
</w:r>
</w:ins>
</w:p>
Nell'esempio, alla parola Some è stata aggiunta la parola text. Il risultato
è un paragrafo unico nel quale sono presenti due run, il secondo dei quali è un
inserimento tracciato dal change tracking con l'elemento ins.
Questo elemento fa uso della tipologia di annotazione inline, applicando quindi
l'approccio fragmentation
5.3.2
Cancellazione di un run
L'elemento del racchiude al proprio interno la parte di testo che è stata cancellata durante una revisione.
Esempio:
<w:p>
<w:r>
<w:t>Some</w:t>
</w:r>
<w:del w:id="0" w:author="Joe Smith" w:date="2006-03-31T12:50:00Z">
<w:r>
<w:delText>text</w:delText>
</w:r>
</w:del>
</w:p>
33
In questo esempio la parola text è stata cancellata, ed in eetti abbiamo un
paragrafo che racchiude al proprio interno un run ed un elemento del, all'interno
del quale si trova il testo cancellato.
Anche in questo caso, l'annotazione applicata è inline, utilizzando l'approccio
fragmentation. Viene anche fatta una sostituzione del tag w:t trasformandolo
in w:delText.
5.3.3
Spostamento di un run
Il change tracking di operazioni di spostamento dà luogo ad uno scenario più
complesso dei precedenti.
Le informazioni di un'operazione di spostamento da memorizzare sono:
•
Un insieme di frammenti di contenuto che sono stati mossi
•
un contenitore (o bookmark) sorgente e uno di destinazione. Questi contenitori specicano che tutto il contenuto al loro interno etichettato come
sorgente/destinazione è parte di una singola operazione di spostamento.
Gli 'attributi name nei due contenitori collegano un gruppo destinazione
al corrispondente gruppo sorgente.
Entrano in gioco 6 elementi, ovvero due coppie di milestone (moveFromRangeStart, moveFromRangeEnd, moveToRangeStart, moveToRangeEnd) e due elementi (moveTo e moveFrom).
Le coppie di milestone moveFromRangeStart/moveFromRangeEnd e moveToRangeStart/moveToRangeEnd specicano l'inizio e la ne dei contenitori, rispettivamente sorgente e destinazione, i cui contenuti sono parte di una singola
operazione di spostamento. Essi sono i contenitori.
Gli elementi moveFrom e moveTo, invece, racchiudono l'insieme di frammenti
oggetto dello spostamento dalla locazione di partenza (moveFrom) alla locazione
di destinazione (moveTo). Essi sono ciò che racchiude i frammenti di contenuto.
Vediamo un esempio:
<w:p>
<w:moveToRangeStart w:id="0" ... w:name="move1" />
<w:moveTo w:id="1" ... >
<w:r>
<w:t>Some moved text.</w:t>
</w:r>
</w:moveTo>
<w:moveToRangeEnd w:id="0" />
34
<w:r>
<w:t xml:space="preserve">Some text.</w:t>
</w:r>
<w:moveFromRangeStart w:id="2" ... w:name="move1" />
<w:moveFrom w:id="3" ... >
<w:r>
<w:t>Some moved text.</w:t>
</w:r>
</w:moveFrom>
<w:moveFromRangeEnd w:id="2" />
</w:p>
In questo esempio il run Some moved text. è stato spostato dalla parte nale
del paragrafo a quella iniziale.
Possiamo vedere la coppia di milestone moveToRangeStart/moveToRangeEnd
che racchiude un elemento moveTo contenente il testo spostato.
Nella zona
centrale del paragrafo vi è il run con il testo rimasto inalterato, seguito dalla
coppia moveRangeStart/moveRangeEnd e dall'elemento moveFrom.
Possiamo notare che vi è ripetizione del testo spostato, sia nella locazione di
destinazione (attiva) che nella locazione di partenza. Ciò sicuramente facilita
la visualizzazione dello spostamento sull'editor, ma è comunque discutibile per
quanto riguarda eventuali problematiche di allineamento tra le due porzioni di
testo.
Le annotazioni utilizzate nello spostamento di un run e, come vedremo, in tutti
gli altri spostamenti, sono di tipo cross structure per i container, e di tipo
inline per gli elementi moveTo/moveFrom.
L'approccio applicato è misto:
milestone e fragmentation.
5.3.4
Modica di attributi/proprietà di un run (run properties)
L'elemento rPrChange indica i dettagli di una revisione ad un insieme di proprietà di un run (elemento rPr).
Questo elemento permette di memorizzare:
•
l'insieme completo delle proprietà originali prima della modica apportata
•
le metainformazioni della modica (quando e da chi è stata apportata).
Vediamo un esempio:
35
<w:rPr>
<w:b/>
<w:i/>
<w:rPrChange w:id="0" w:date="01-01-2006T12:00:00" w:author="John Doe">
<w:rPr>
<w:i/>
</w:rPr>
</w:rPrChange>
</w:rPr>
Nell'esempio, John Doe ha modicato in data 01/01/2006 lo stile del paragrafo
da corsivo (italic) a grassetto (bold).
L'annotazione utilizzata è di tipo proprietà e l'approccio è fragmentation.
5.3.5
Inserimento di un paragrafo
L'operazione di inserimento di un paragrafo in realtà indica non tanto l'inserimento di contenuto (che generalmente fa riferimento alla nozione di run ) quanto
l'inserimento dello specico tag di delimitazione di un paragrafo (p ).
Questa informazione è codicata all'interno delle proprietà di paragrafo (rPr )
per mezzo dell'elemento ins.
L'elemento ins indica che, durante un'operazione soggetta a change tracking, il
tag del paragrafo che lo contiene è stato inserito.
Vediamo un esempio:
<w:p>
<w:pPr>
<w:rPr>
<w:ins w:id="0" ... />
</w:rPr>
</w:pPr>
<w:r>
<w:t>This is paragraph one.</w:t>
</w:r>
</w:p>
<w:p>
<w:r>
<w:t>This is paragraph two.</w:t>
</w:r>
</w:p>
Lo scenario è il seguente: abbiamo un paragrafo che contiene le seguenti frasi:
This is paragraph one.This is paragraph two.
36
Decidiamo di suddividere il paragrafo in due paragra, il primo contenente la
prima frase, il secondo contenente la seconda.
Questa modica viene tracciata creando un nuovo paragrafo ed inserendo, nelle
sue proprietà, l'elemento ins.
In questo caso l'annotazione utilizzata è di tipo proprietà, e l'approccio è frag-
mentation.
5.3.6
Cancellazione di un paragrafo
Come nel caso dell'inserimento, la cancellazione di un paragrafo non ha a che
fare con la cancellazione del contenuto (azione regolata dalle operazioni sui run),
ma del tag di delimitazione del paragrafo stesso.
Partendo dall'esempio del paragrafo precedente (5.3.5), cancelliamo il
paragrafo appena inserito. l'XML della modica è il seguente:
<w:p>
<w:pPr>
<w:rPr>
<w:del w:id="0" ... />
</w:rPr>
</w:pPr>
<w:r>
<w:t>This is paragraph one.</w:t>
</w:r>
</w:p>
<w:p>
<w:r>
<w:t>This is paragraph two.</w:t>
</w:r>
</w:p>
Ovvero il primo paragrafo, nelle sue proprietà, contiene l'elemento del, che lo
marca come cancellato, pertanto deve essere considerato tale a tutti gli eetti.
Anche in questo caso viene utilizzata un'annotazione di proprietà con approccio
fragmentation.
5.3.7
Spostamento di un paragrafo
Il meccanismo di spostamento dei paragra è simile al meccanismo di spostamento dei run (cfr. 5.3.3).
Come per le precedenti operazioni sui paragra, l'operazione di spostamento
non ha a che fare con lo spostamento di contenuto, ma solo con lo spostamento
dei tag che identicano un paragrafo.
37
Vi sono 6 elementi che entrano in gioco, ed in questo caso sono quattro coppie di milestone:
i contenitori moveFromRangeStart/moveFromRangeEnd,
moveToRangeStart/moveToRangeEnd e gli elementi (questa volta vuoti) moveFrom/moveTo.
Gli elementi vuoti moveFrom e moveTo sono tali in quanto, per lo spostamento
dei paragra, fa fede l'elemento rPr, ovvero proprietà di run, contenuto all'interno di pPr, ovvero proprietà di paragrafo, che ci comunica che la marcatura
di paragrafo (facente parte del contenuto) è stata spostata altrove.
Vediamo un esempio:
<w:moveFromRangeStart w:id="0" w:name="aMove"/>
<w:p>
<w:pPr>
<w:rPr>
<w:moveFrom w:id="1" ... />
</w:rPr>
</w:pPr>
...
</w:p>
</w:moveFromRangeEnd w:id="0"/>
....
<w:moveToRangeStart w:id="0" w:name="aMove"/>
<w:p>
<w:pPr>
<w:rPr>
<w:moveTo w:id="1" ... />
</w:rPr>
</w:pPr>
...
</w:p>
</w:moveToRangeEnd w:id="0"/>
Nell'esempio un paragrafo è stato spostato in basso nel documento. Nelle paragraph properties (elemento pPr) è presente un elemento rPr (run properties)
che indica che il paragrafo è stato mosso.
Non viene fatta alcuna menzione del contenuto del paragrafo, in quanto lo
spostamento riguarda esclusivamente la nozione di paragrafo. Nulla vieta che il
contenuto possa essere aggiunto in un momento successivo allo spostamento.
Lo spostamento di paragrafo utilizza annotazioni cross structure (per i contenitori) e proprietà (per gli elementi moveFrom/moveTo).
38
5.3.8
Modica di attributi/proprietà del paragrafo
Analogamente alla modica delle proprietà dei run (cfr.
5.3.4), anche per le
modiche alle proprietà dei paragra esiste un elemento apposito, rPrChange,
che permette di memorizzare:
•
l'insieme completo delle proprietà di paragrafo applicate precedentemente
alla modica
•
le metainformazioni della modica
Vediamone un esempio:
<w:pPr>
<w:jc w:val="center"/>
<w:pPrChange w:id="0" w:date="01-01-2006T12:00:00" w:author="John Doe">
<w:pPr/>
</w:pPrChange>
</w:pPr>
L'elemento pPrChange indica che John Doe, in data 01/01/2006 alle ore 12:00,
ha modicato le proprietà di paragrafo inserendo un allineamento centrato.
Non essendo menzionata alcuna proprietà nell'elemento pPr all'interno del pPrChange, si può concludere che non vi fossero proprietà pre-esistenti.
Questo è un classico caso di annotazione di proprietà con approccio fragmenta-
tion.
39
5.3.9
Inserimento di una cella di tabella
Le operazioni di inserimento di celle all'interno di tabelle sono identicate dall'elemento cellIns.
Vediamo un esempio:
<w:tbl>
...
<w:tr>
<w:tc>
<w:r>
<w:t>One</w:t>
</w:r>
</w:tc>
<w:tc>
<w:r>
<w:t>Two</w:t>
</w:r>
</w:tc>
<w:tc>
<w:tcPr>
<w:cellIns w:id="0" ... />
</w:tcPr>
<w:r>
<w:t>New</w:t>
</w:r>
</w:tc>
</w:tr>
<w:tr>
<w:tc>
<w:r>
<w:t>Three</w:t>
</w:r>
</w:tc>
<w:tc>
<w:r>
<w:t>Four</w:t>
</w:r>
</w:tc>
<w:tc>
<w:tcPr>
<w:cellIns w:id="1" ... />
</w:tcPr>
<w:r>
<w:t>New</w:t>
</w:r>
</w:tc>
</w:tr>
</w:tbl>
Vengono inserite due celle: la Two e la Four. Il sistema di revisione inserisce
il tag cellIns all'interno delle proprietà di cella (elemento tcPr).
In questo caso l'annotazione è di proprietà con approccio fragmentation.
40
5.3.10
Cancellazione di una cella di tabella
La cancellazione di celle ti tabella è indicata dall'elemento cellDel:
<w:tbl>
...
<w:tr>
<w:tc>
<w:r>
<w:t>One</w:t>
</w:r>
</w:tc>
<w:tc>
<w:tcPr>
<w:cellDel w:id="0" ... />
</w:tcPr>
<w:r>
<w:t>Two</w:t>
</w:r>
</w:tc>
</w:tr>
<w:tr>
<w:tc>
<w:r>
<w:t>Three</w:t>
</w:r>
</w:tc>
<w:tc>
<w:tcPr>
<w:cellDel w:id="1" ... />
</w:tcPr>
<w:r>
<w:t>Four</w:t>
</w:r>
</w:tc>
</w:tr>
</w:tbl>
Nell'esempio la prima cella è stata cancellata. Si può notare l'elemento cellDel
all'interno delle proprietà di cella (tcPr).
Anche in questo caso l'annotazione utilizzata è di proprietà con approccio frag-
mentation.
41
5.3.11
Unione di celle
L'operazione di unione di celle in OOXML riguarda esclusivamente l'unione
verticale (celle all'interno di una stessa colonna).
In un contesto di change
tracking, l'unione di due celle viene indicata tramite l'elemento cellMerge nella
seconda (e ultima) cella interessata.
Vediamo un esempio:
<w:tbl>
...
<w:tr>
<w:tc>
<w:r>
<w:t>One</w:t>
</w:r>
</w:tc>
<w:tc>
<w:r>
<w:t>Two</w:t>
</w:r>
</w:tc>
</w:tr>
<w:tr>
<w:tc>
<w:r>
<w:t>Three</w:t>
</w:r>
</w:tc>
<w:tc>
<w:tcPr>
<w:cellMerge w:id="0" w:vMerge="cont"/>
</w:tcPr>
<w:r>
<w:t>Four</w:t>
</w:r>
</w:tc>
</w:tr>
</w:tbl>
La tabella descritta nell'esempio è formata da due righe e due colonne. Nella
prima riga abbiamo le celle One e Two; nella seconda riga trovano posto le
celle Three e Four. Le celle Two e Four sono unite con un'operazione di
unione. All'interno delle proprietà di cella (tcPr) della cella Four si può notare
l'elemento cellMerge.
Il tipo di annotazione utilizzata è proprietà, con approccio fragmentation.
42
5.3.12
Inserimento di una riga di tabella
L'inserimento di una riga di tabella viene indicato tramite l'elemento ins, esattamente come succede per i run e i paragra.
Come succede per i paragra, anche in questo caso l'informazione riguardante
il change tracking dell'inserimento di riga riguarda esclusivamente la nozione di
riga stessa. Non vengono interessati in alcun modo i contenuti della riga e le
eventuali celle all'interno di essa, che devono essere trattati indipendentemente.
Vediamo un esempio:
<w:tbl>
...
<w:tr>
<w:tc>
<w:p/>
</w:tc>
<w:tc>
<w:p/>
</w:tc>
</w:tr>
<w:tr>
<w:trPr>
<w:ins w:id="0" ... />
</w:trPr>
<w:tc>
<w:p/>
</w:tc>
<w:tc>
<w:p/>
</w:tc>
</w:tr>
</w:tbl>
Nell'esempio abbiamo una tabella, originariamente composta da una sola riga,
alla quale viene aggiunta un'ulteriore riga.
Possiamo notare l'elemento ins
all'interno delle proprietà di riga (trPr).
L'annotazione utilizzata è di tipo di proprietà, con approccio fragmentation.
43
5.3.13
Cancellazione di una riga di tabella
La cancellazione di riga di una tabella segue lo stesso schema visto per i paragra ed i run. L'operazione viene identicata con la presenza dell'elemento del
all'interno delle proprietà della riga interessata.
Come per i paragra, l'operazione di cancellazione non ha alcun impatto sugli elementi contenuti all'interno della riga stessa, che dovranno essere eventualmente
trattati con opportune revisioni indipendenti.
Vediamo un esempio:
<w:tbl>
...
<w:tr>
<w:tc>
<w:p/>
</w:tc>
<w:tc>
<w:p/>
</w:tc>
</w:tr>
<w:tr>
<w:trPr>
<w:del w:id="0" ... />
</w:trPr>
<w:tc>
<w:p/>
</w:tc>
<w:tc>
<w:p/>
</w:tc>
</w:tr>
</w:tbl>
Specularmente all'esempio del paragrafo precedente, qui abbiamo una tabella
originariamente composta da due righe, l'ultima delle quali viene cancellata. Si
può apprezzare la presenza dell'elemento del all'interno delle proprietà (trPr)
dell'ultima riga.
Anche in questo caso l'annotazione utilizzata è di proprietà, e l'approccio è
fragmentation
5.3.14
Inserimento di XML custom
Lo standard OOXML permette l'inserimento di frammenti di XML arbitrario,
cosiddetto customXML.
Nel documento, i frammenti di XML arbitrario inseriti durante il tracciamento
delle modiche sono memorizzati tra due milestone: customXmlInsRangeStart
e customXmlInsRangeEnd.
44
Entrambi gli elementi sono identicati tramite un opportuno identicatore, e
non possono esistere l'uno senza l'altro pena la non conformità del documento.
Vediamo un esempio:
<w:p>
<w:customXml ... >
<w:customXmlInsRangeStart w:id="0" />
<w:customXml ... >
<w:r>
<w:t>Text.</w:t>
</w:r>
</w:customXml>
<w:customXmlInsRangeEnd w:id="0" />
</w:customXml>
<w:r>
<w:t>More text.</w:t>
</w:r>
</w:p>
Nell'esempio è stato inserito un frammento aggiuntivo di XML arbitrario.
Si
possono facilmente vedere le milestone di inizio e ne della regione oggetto
dell'inserimento.
Attenzione: anche in questo caso, come per i paragra, la memorizzazione del
change tracking si applica solo all'XML personalizzato, e non al suo contenuto
(il testo Text.).
L'annotazine utilizzata è di tipo cross structure, e l'approccio è milestone.
5.3.15
Cancellazione di XML custom
La cancellazione di un frammento di XML custom segue grossomodo la falsariga dell'inserimento. Abbiamo due milestone che identicano il frammento
cancellato, ovvero customXmlDelRangeStart e customXmlDelRangeEnd.
Vediamo l'esempio:
<w:p>
<w:customXmlDelRangeStart w:id="0" w:author="Devan" />
<w:customXml ... >
<w:customXml ... >
<w:del ... >
<w:r>
<w:delText>Text.</w:delText>
</w:r>
</w:del>
</w:customXml>
<w:customXmlDelRangeEnd w:id="0" />
</w:customXml>
<w:r>
<w:t>More text.</w:t>
</w:r>
</w:p>
45
Nell'esempio possiamo apprezzare una doppia cancellazione:
quella degli el-
ementi XML custom (identicata dalle due milestone) e la cancellazione del
testo contenuto in essi, applicando la cancellazione del run (elementi w:del e
w:deltext).
Il tipo di annotazione utilizzato per la cancellazione di XML custom è cross
structure. L'approccio è pertanto milestone.
5.3.16
Spostamento di XML custom
Come per lo spostamento di run e paragra, anche per l'XML custom si applica
grossomodo lo stesso metodo. Abbiamo due coppie di milestone, ovvero i contenitori moveFromRangeStart/moveFromRangeEnd, moveToRangeStart/moveToRangeEnd.
Contrariamente allo spostamento di run e paragra, non esistono gli elementi
moveFrom e moveTo.
Nel caso dello spostamento di XML custom, i contenitori si chiamano, rispettivamente: customXmlMoveFromRangeStart, customXmlMoveFromRangeEnd,
customXmlMoveToRangeStart, customXmlMoveToRangeEnd.
Vediamo un esempio:
dalla situazione iniziale:
<w:body>
<w:p/>
<w:customXml ... >
<w:p/>
</w:customXml>
<w:p/>
</w:body>
vogliamo spostare il secondo paragrafo alla ne del documento. Ecco il
risultato:
<w:body>
<w:p/>
<w:moveFromRangeStart w:id="0" w:name="move1" w:displacedByCustomXml="next"
w:author="Luna"/>
<w:customXmlMoveFromRangeStart w:id="1"/>
<w:customXml ... >
<w:p/>
</w:customXml>
<w:customXmlMoveFromRangeEnd w:id="1"/>
<w:moveFromRangeEnd w:id="0" w:displacedByCustomXml="prev"/>
<w:p/>
<w:moveToRangeStart w:id="2" w:name="move1" w:displacedByCustomXml="next"/>
<w:customXmlMoveToRangeStart w:id="3"/>
<w:customXml ... >
<w:p/>
</w:customXml>
<w:customXmlMoveToRangeEnd w:id="3"/>
<w:moveFromRangeEnd w:id="2" w:displacedByCustomXml="prev"/>
</w:body>
46
Si può notare non solo la struttura per il movimento dell'XML personalizzato, ma anche quella per il movimento del paragrafo in esso contenuto (elementi
moveFromRangeStart/moveFromRangeEnd e moveToRangeStart/moveToRangeEnd).
Anche per lo spostamento di XML custom viene utilizzata l'annotazione di tipo
cross structure. L'approccio è milestone.
5.3.17
Altre operazioni
La stessa tecnica descritta nei punti 5.3.1 e 5.3.5, ovvero la presenza di un
elemento ins all'interno delle proprietà dell'oggetto (un run, un paragrafo) viene
applicata anche ad altri contesti, ovvero:
•
agli inserimenti di caratteri matematici (l'elemento ins è all'interno delle
proprietà di controllo - ctrlPr)
•
agli inserimenti delle proprietà di numerazione (l'elemento ins è all'interno
dell'elemento numPr)
Anche le cancellazioni seguono lo stesso principio di quanto già enunciato ai
paragra 5.3.2 e 5.3.6. Ritroviamo la presenza dell'elemento del all'interno delle
proprietà dell'elemento da cancellare nei seguenti contesti:
•
cancellazioni di caratteri matematici (elemento del all'interno delle proprietà di controllo - ctrlPr)
47
6 Alcuni esempi in Open Document Format
Ecco alcuni esempi in Open Document Format, con alcune considerazioni.
I documenti sono stati prodotti utilizzando Open Oce 3.1, scompattando
il le .odt risultante, e aprendo il le content.xml.
Verranno riportate solo
le parti signicative del le, ovvero il contenuto dell'elemento body depurato
dell'elemento
<text:sequence-decls>.
Il testo utilizzato negli esempi è tratto da Flatlandia di Edwin A. Abbott,
nell'edizione Adelphi, XII ristampa (2003), ISBN: 88-459-0982-4 [6, 1]
6.1 Inserimento
Eettuiamo un semplice inserimento di un testo.
Prendiamo come esempio il primo paragrafo del capitolo 4 (pagina 41). Esso
recita:
Se i nostri acuminati Triangoli della Classe Militare sono pericolosi, se ne può facilmente dedurre che le nostre Donne lo sono
ancora di più.
Creiamo ora un documento senza le parole della Classe Militare (lo spazio
iniziale non è un refuso), ed aggiungiamo successivamente il testo mancante.
Il contenuto del le content.xml del testo prima dell'inserimento è:
<office:body>
<office:text>
<text:tracked-changes text:track-changes="true"/>
<text:p text:style-name="Standard">Se i nostri acuminati Triangoli sono pericolosi,
se ne può facilmente dedurre che le nostre Donne lo sono ancora di più.</text:p>
</office:text>
</office:body>
Nell'XML della nostra situazione di partenza si può vedere l'elemento che segnala l'attivazione della gestione del change tracking (<text:tracked-changes text:track-
changes="true"/>). Si può notare l'assenza della lista delle modiche.
Vediamo ora il contenuto del le xml dopo l'inserimento:
48
<office:body>
<office:text>
<text:changed-region text:id="ct161242016">
<text:insertion>
<dc:creator>Alessio </dc:creator>
<dc:date>2010-02-02T00:24:00</dc:date>
</text:insertion>
<text:p text:style-name="Standard">Se i nostri acuminati Triangoli
<text:change-start text:change-id="ct161242016"/> della Classe Militare
<text:change-end text:change-id="ct161242016"/> sono pericolosi, se ne può facilmente dedurre
che le nostre Donne lo sono ancora di più.
</text:p>
</office:text>
</office:body>
Possiamo facilmente notare la lista delle modiche (elemento <text:trackedchanges>) contenente un riferimento (id=ct161242016) ed un elemento con le
metainformazioni della modica. Nel testo abiamo due milestone che identicano l'inizio e la ne del brano di testo inserito.
6.2 Cancellazione
Partendo dall'esempio precedente, proviamo a cancellare la parola ancora.
<office:body>
<office:text>
<text:insertion>
<dc:date>2010-02-02T00:24:00</dc:date>
</text:insertion>
<text:deletion>
<dc:date>2010-02-02T22:57:00</dc:date>
<text:p text:style-name="Standard">ancora</text:p>
</text:deletion>
<text:change-start text:change-id="ct142829072"/>
della Classe Militare<text:change-end text:change-id="ct142829072"/> sono pericolosi,
se ne può facilmente dedurre
che le nostre Donne lo sono <text:change text:change-id="ct149665840"/><text:s/>di più.</text:p>
</office:text>
</office:body>
Come si può facilmente notare, alla lista delle modiche si è aggiunta la cancellazione, con la milestone che ne identica la posizione.
49
6.3 Complichiamo un po' le cose: la cancellazione dentro
l'inserimento
Proviamo ora a cancellare i caratteri Militare dalla regione dell'inserimento
iniziale.
Questa modica deve essere apportata da un utente diverso dal precedente,
altrimenti possono esserci dei problemi (cfr. sez. 6.3.1).
Utilizziamo perciò un nuovo utente (Rita).
Riassumiamo la successione delle modiche:
•
Alessio inserisce i caratteri della Classe Militare
•
Alessio cancella i caratteri ancora
•
Rita cancella i caratteri Militare Questo è il risultato nale:
<office:body>
<office:text>
<text:insertion>
<dc:date>2010-02-02T00:24:00</dc:date>
</text:insertion>
<text:deletion>
<dc:creator>Rita </dc:creator>
<dc:date>2010-02-03T00:15:00</dc:date>
<text:p text:style-name="Standard">Militare</text:p>
</text:deletion>
<text:insertion>
<office:change-info office:chg-author="Alessio " office:chg-date-time="2010-02-02T00:24:00"/>
</text:insertion>
<text:deletion>
<dc:creator>Rita </dc:creator>
<dc:date>2010-02-03T00:15:00</dc:date>
<text:p text:style-name="Standard">
<text:s/>
</text:p>
</text:deletion>
50
<text:deletion>
<dc:date>2010-02-02T22:57:00</dc:date>
</text:deletion>
della Classe <text:change-end text:change-id="ct154835096"/>
<text:change text:change-id="ct160968456"/>
<text:change text:change-id="ct160880080"/>sono pericolosi, se ne può facilmente dedurre
</office:text>
</office:body>
Il risultato non è molto dissimile da quanto atteso: nella lista delle modiche
abbiamo tutti gli elementi che ci aspettavamo di avere, e nel testo abbiamo le
rispettive milestone che richiamano le modiche.
La cancellazione dei caratteri Militare da parte dell'utente Rita ha creato due
modiche: una con la parola Militare e una con lo spazio dopo di essa.
Una modica importante rispetto a quanto ci si poteva attendere è che la milestone del primo inserimento nisce dopo i caratteri Classe, subito dopo seguita
dalla milestone dell'utima cancellazione. In realtà sarebbe stato più corretto un
annidamento delle milestone, in quanto il testo cancellato era precedentemente
contenuto all'interno dei tag di inizio e ne dell'inserimento.
6.3.1
Problema (bug?) nella cancellazione con lo stesso utente
Come vediamo, apportando la cancellazione dei caratteri Militare dalla
regione dell'inserimento iniziale con lo stesso utente, si crea un problema:
questa modica non viene memorizzata correttamente, apparendo
semplicemente come se si trattasse di una cancellazione di uno spazio
(<text:s/>). Questo comportamento si verica con il client OpenOce.org 3.1
per Linux:
<office:body>
<office:text>
<text:insertion>
<dc:date>2010-02-02T00:24:00</dc:date>
</text:insertion>
<text:deletion>
51
<dc:date>2010-02-02T23:19:00</dc:date>
<text:p text:style-name="Standard">
<text:s/>
</text:p>
</text:deletion>
<text:deletion>
<dc:date>2010-02-02T22:57:00</dc:date>
</text:deletion>
della Classe <text:change-end text:change-id="ct150743592"/><text:change text:change-id="ct156476480"/>
sono pericolosi, se ne può facilmente dedurre
</office:text>
</office:body>
Ripetendo l'esperimento con Open Oce 3.1 per Windows XP, il risultato è
ancora dierente:
<office:body>
<office:text>
<text:insertion>
<dc:creator>Alessio Rolfini</dc:creator>
<dc:date>2010-02-02T23:50:00</dc:date>
</text:insertion>
<text:deletion>
<dc:creator>Alessio Rolfini</dc:creator>
<dc:date>2010-02-02T23:51:00</dc:date>
</text:deletion>
della Classe<text:change-end text:change-id="ct145865616"/> sono pericolosi, se ne può facilmente dedurre
</office:text>
</office:body>
Come si può vericare, risultano due sole operazioni di modica: un inserimento
(testo: della Classe - senza Militare), ed una cancellazione (ancora). Non vi
è traccia della successiva cancellazione, nè risulta dai timestamp un'operazione
successiva alla seconda operazione.
52
7 Alcuni esempi in OOXML
Nei paragra che seguono verranno presentati alcuni signicativi (benchè semplici) esempi in OOXML.
Le tipologie arontate saranno simili a quelle del capitolo precedente.
I documenti sono stati prodotti con Microsoft Oce 2007 Professional, scompattando il le .docx risultante ed aprendo il le document.xml.
Come nel capitolo precedente, verranno riportate solo le parti signicative del
documento, che, nel caso dell'OOXML, è il contenuto dell'elemento <w:body>
epurato della parte relativa alle proprietà di sezione (w:sectPr).
Una caratteristica molto interessante che emerge dai test è l'assenza dei costrutti
di spostamento, sostituiti dalla sequenza cancellazione/inserimento. Da notare
che, a livello di interfaccia, lo spostamento è segnalato come tale nchè il documento non viene chiuso e riaperto, dopodichè viene segnalato come cancellazione
e inserimento.
Questo comportamento di Oce 2007 è molto signicativo, in quanto diminuisce
sensibilmente la complessità dei documenti prodotti, limitando di molto la
presenza di annotazioni di tipo cross structure.
7.1 Inserimento
Ripetiamo l'inserimento visto nel capitolo precedente. Creiamo un documento
contenente il seguente testo:
Se i nostri acuminati Triangoli sono pericolosi, se ne può facilmente
dedurre che le nostre Donne lo sono ancora di più.
Attiviamo il tracciamento delle revisioni, ed aggiungiamo il testo mancante,
ovvero: della Classe Militare.
Il documento iniziale è il seguente:
<w:body>
<w:p w:rsidR="00812D79" w:rsidRDefault="00935D88">
<w:r>
<w:t>Se i nostri acuminati triangoli sono pericolosi, se ne può facilmente dedurre che le nostre Donne lo sono anco
</w:r>
</w:p>
</w:body>
53
Si può notare il paragrafo, il run, ed il testo in esso contenuto.
Ora apportiamo la modica:
<w:body>
<w:r>
<w:t>Se i nostri acuminati triangoli</w:t>
</w:r>
<w:ins w:id="0" w:author="Alessio" w:date="2010-03-07T23:44:00Z">
<w:r w:rsidR="00185E09">
<w:t xml:space="preserve"> della Classe Militare</w:t>
</w:r>
</w:ins>
<w:r>
<w:t xml:space="preserve"> sono pericolosi, se ne può facilmente dedurre che le nostre Donne lo sono ancora di più.
</w:r>
</w:p>
</w:body>
Qui possiamo vedere il tag w:ins all'interno del paragrafo, che indica che in
data 07/03/2010 è stato inserito dall'autore Alessio un nuovo run contenente
il testo della Classe Militare. Il run successivo riporta semplicemente la parte
di testo seguente.
7.2 Cancellazione
Partendo dall'esempio precedente, dopo l'inserimento proviamo a cancellare la
parola ancora. Questo è il risultato:
<w:body>
<w:r>
</w:r>
<w:r w:rsidR="00185E09">
<w:t xml:space="preserve"> della Classe Militare</w:t>
</w:r>
</w:ins>
<w:r>
<w:t xml:space="preserve"> sono pericolosi, se ne può facilmente dedurre che le nostre Donne lo sono </w:t>
</w:r>
<w:del w:id="1" w:author="Alessio" w:date="2010-03-07T23:55:00Z">
<w:r w:rsidDel="00EC42C4">
<w:delText>ancora</w:delText>
</w:r>
</w:del>
<w:r>
<w:t xml:space="preserve"> di più.</w:t>
</w:r>
</w:p>
</w:body>
Abbiamo sempre l'XML dell'inserimento precedente, ma, in aggiunta ad esso,
abbiamo un elemento di cancellazione w:del che contiene un run con il testo
cancellato. Segue la parte non toccata dalle modiche.
54
7.3 Cancellazione da parte di altri utenti
Introduciamo un livello di complessità aggiuntivo:
a partire dall'esempio del
paragrafo 7.1 proviamo a cancellare i caratteri Militare dalla regione dell'inserimento precedente.
Questa operazione verrà fatta con un nuovo utente
(Alice).
Vediamo i passi:
•
Alessio inserisce i caratteri della Classe Militare
•
Alessio cancella i caratteri ancora
•
Alice cancela i caratteri Militare Ecco l'XML risultante:
<w:body>
<w:r>
</w:r>
<w:r w:rsidR="00185E09">
<w:t xml:space="preserve"> della Classe </w:t>
</w:r>
<w:del w:id="1" w:author="Alice" w:date="2010-03-08T00:04:00Z">
<w:r w:rsidR="00185E09" w:rsidDel="00CC0793">
<w:delText>Militare</w:delText>
</w:r>
</w:del>
</w:ins>
<w:r>
<w:t xml:space="preserve"> sono pericolosi, se ne può facilmente dedurre che le nostre Donne lo sono </w:t>
</w:r>
<w:del w:id="2" w:author="Alessio" w:date="2010-03-07T23:55:00Z">
<w:r w:rsidDel="00EC42C4">
<w:delText>ancora</w:delText>
</w:r>
</w:del>
<w:r>
<w:t xml:space="preserve"> di più.</w:t>
</w:r>
</w:p>
</w:body>
Qui non vi è nessuna sorpresa: all'interno dell'elemento w:ins viene inserito un
nuovo elemento w:del con la cancellazione di Alice.
Il resto del documento è
immutato.
Un'osservazione che può essere fatta è che il documento risulta leggermente più
snello e leggibile del suo omologo in ODT.
55
7.4 Inserimento di paragrafo
Testiamo ora l'inserimento di paragrafo.
Partendo dalla situazione iniziale del paragrafo 7.1, inseriamo due paragra
vuoti: uno in testa al documento, uno in coda.
Ecco il documento dopo l'operazione:
<w:body>
<w:p w:rsidR="00E50517" w:rsidRDefault="00E50517">
<w:pPr>
<w:rPr>
<w:ins w:id="0" w:author="Alice" w:date="2010-03-08T00:56:00Z"/>
</w:rPr>
</w:pPr>
</w:p>
<w:pPr>
<w:rPr>
</w:rPr>
</w:pPr>
<w:r>
</w:r>
</w:p>
<w:p w:rsidR="00E50517" w:rsidRDefault="00E50517"/>
</w:body>
Il primo paragrafo è segnalato come inserito da Alice; il secondo paragrafo
dovrebbe essere immutato, ed in eetti il suo id corrisponde all'originale (id:
00812D79). Tuttavia viene segnalato anch'esso come inserito da Alice. E' poi
presente un paragrafo vuoto nale che ha l'id corrispondente al primo. Si tratta
sicuramente del segno di chiusura del paragrafo iniziale.
La rappresentazione nell'interfaccia ha questo schema:
•
il primo segno di paragrafo viene segnalato come inserimento, ed è in rosso.
Questo è corretto, infatti è un nuovo paragrafo.
•
il secondo segno di paragrafo è segnalato come pre-esistente, ed è in nero.
Questo è corretto, è il segno di paragrafo che precede il testo.
•
il terzo segno di paragrafo, subito dopo il testo, è segnalato come nuovo
inserimento, ed è in rosso
•
il quarto segno di paragrafo è segnalato come pre-esistente, quindi nero.
L'operazione di inserimento del secondo paragrafo dopo il testo, nell'interfaccia,
fa spostare il carattere speciale di paragrafo pre-esistente alla ne del documento, inserendo, tra esso ed il testo, un nuovo carattere di paragrafo rosso (quindi,
nuovo inserimento).
56
7.5 Spostamento di paragrafo vuoto
Veniamo ora agli spostamenti. Come anticipato precedentemente, le strutture di
spostamento della specica, con i loro container ed elementi moveFrom/moveTo,
sono sostituite dalla sequenza cancellazione/inserimento.
Proviamo ad eettuare lo spostamento del primo segno di paragrafo (vuoto)
dell'esempio precedente.
Ecco l'XML risultante:
<w:body>
<w:pPr>
<w:rPr>
</w:rPr>
</w:pPr>
<w:r>
</w:r>
</w:p>
<w:p w:rsidR="00B5562F" w:rsidRDefault="00B5562F" w:rsidP="00B5562F">
<w:pPr>
<w:rPr>
</w:rPr>
</w:pPr>
</w:p>
<w:p w:rsidR="00E50517" w:rsidRDefault="00E50517"/>
</w:body>
Il primo segno di paragrafo è stato cancellato.
Ci si aspetterebbe di trovarlo
inserito in fondo, tuttavia, trattandosi di un paragrafo vuoto, seguendo il comportamento dell'applicazione nel caso precedente, può essere dedotto il fatto che
il segno venga collassato nell'elemento di chiusura corrispondente, che si trova
alla ne del documento.
7.6 Spostamento di un run
Lo spostamento di un run non segue la specica, venendo tradotto in un'operazione di cancellazione/inserimento.
Proviamo a spostare la parola facilmente dalla metà circa del testo ad un
punto successivo.
Questo è il risultato:
57
<w:body>
<w:r>
<w:t xml:space="preserve">Se i nostri acuminati triangoli sono pericolosi, se ne può </w:t>
</w:r>
<w:del w:id="0" w:author="Alice" w:date="2010-03-08T00:50:00Z">
<w:r w:rsidDel="00D552C1">
<w:delText xml:space="preserve">facilmente </w:delText>
</w:r>
</w:del>
<w:r>
<w:t xml:space="preserve">dedurre che le nostre Donne lo sono </w:t>
</w:r>
<w:ins w:id="1" w:author="Alice" w:date="2010-03-08T00:50:00Z">
<w:r w:rsidR="00D552C1">
<w:t xml:space="preserve">facilmente </w:t>
</w:r>
</w:ins>
<w:r>
<w:t>ancora di più.</w:t>
</w:r>
</w:p>
</w:body>
E' presente una cancellazione (elemento w:del ) di caratteri facilmente ed un
inserimento degli stessi in un punto successivo (elemento w:ins ). Si può notare
che il codice del run spostato è identico in entrambe le operazioni (00D552C1),
e questo le mette in relazione, così come gli id progressivi (<w:del w:id=0 ...>
e <w:ins w:id=1...>).
58
Riferimenti bibliograci
[1] art. 70, legge 22 aprile 1941 n. 633 - legge sul diritto d'autore.
[2] Ecma international web site - www.ecma-international.org.
[3] Open xml white paper.
[4] Tei - text encoding initiative - p5: Guidelines for electronic text encoding and interchange - chapter 20 http://www.tei-c.org/release/doc/tei-p5doc/en/html/nh.html.
[5] Tei - text encoding initiative web site http://www.tei-c.org/index.xml,
2009.
[6] Edwin A. Abbott. Flatlandia. Adelphi edizioni, xii edition, 2003.
[7] Claus HuitFeldt C. M. Sperberg-McQueen. Goddag: A data structure for
overlapping hierarchies. Proc. of DDEP/PODDP, pages 139160, 2000.
[8] Angelo Di Iorio, Silvio Peroni, and Fabio Vitali. Taming wild overlaps in a
disciplined way with earmark. 2010.
[9] ECMA International.
Oce Open XML - Part 1:
Fundamentals And
Markup Language Reference, in Standard ECMA-376, Second Edition Oce Open XML File Format, second edition, December 2008.
[10] Paolo Marinelli, Fabio Vitali, and Stefano Zacchiroli. Towards the unication of formats for overlapping markup. New Rev. Hypermedia Multimedia,
14(1):5794, 2008.
[11] OASIS - Organization for the Advancement of Structured Information
Standards.
ument)
Open Document Format for Oce Applications (OpenDoc-
v1.1
http://docs.oasis-open.org/oce/v1.1/OS/OpenDocument-
v1.1-html/OpenDocument-v1.1.html, 1.1 edition, 2007.
[12] OASIS Committee.
RELAX NG Specication http://relaxng.org/spec-
20011203.html, 12 2001.
[13] Jeni Tennison. Representing overlap in xml. Article from Jeni's Musings
blog: http://www.jenitennison.com/blog/node/97, 2008.
59

Il problema dell`overlapping nel change tracking dei

Transcript

Documenti analoghi

inglese

inglese - iis bachelet

programma di lingua e civilta` inglese anno

3AL_ Inglese_ Barion - Istituto di Istruzione Superiore

The Enchanted Island: The Libretto

EDITORIAL RULES SISMEL · EDIZIONI DEL GALLUZZO Following

ITAL. FOL. 154 Binding: Bound in parchment over paper boards

Corso WordPress IASF - Pegotest

Text 6 Social Psychology

Documento Finale del Consiglio di Classe della