Voor een Proof of Concept voor Real-time comments binnen FontoXML
3.1 Elementen toevoegen/verwijderen
Als het document wordt aangepast, heeft dit niet direct effect op de positie van de opmerkingen. Dankzij XPath is het mogelijk dat de pointers van de opmerking niet vaak hoeven te wijzigen. De pointers van een opmerking zullen hierdoor alleen veranderd moeten worden als een sibling van een van de elementen in het pad wordt toegevoegd of
verwijderd. En dit komt dan ook weer alleen voor als dit voor de huidige positie van de opmerking plaatsvind. Zodra er iets achter de opmerking wordt toegevoegd, heeft dit geen effect op de positie van de opmerking.
<root> <a id=”a_01”> <b id=”b_01”></b> <b id=”b_02”> <c id=”c_01”></c> <c id=”c_02”></c> <c id=”c_03”></c> </b> </a> </root>
Fig 1. Dit is een voorbeeld van een XML document.
/root/a[1 and @id=”a_01”]/b[2 and @id=”b_02”]/c[3 and @id=”c_03”] Fig 2. Dit is een voorbeeld van een XPath pad op basis van figuur 1.
In figuur 2 is een XPath pad te zien op basis van het voorbeeld wat weergegeven wordt in figuur 1. Dit pad begint bij het root element, vervolgens komt het a element. Dit element is het eerste a element, dit wordt binnen XPath weergegeven door a[1]. Binnen dit ontwerp is gekozen om ook id’s te gebruiken bij de XPath paden, dit wordt aangegeven door
a[1 and @id=”a_01”]. Dit geldt voor ieder element binnen het pad, behalve voor het root element, aangezien dat maar één keer voor zal komen in het document.
Zodra een element wordt toegevoegd, wordt er gezocht naar opmerkingen die een zelfde sibling in het pad hebben. Alle opmerkingen die een sibling hebben die na het nieuwe element voorkomen, worden verhoogd met 1. Het toevoegen van een element is
geïllustreerd in figuur 3, waarbij tussen de twee bestaande b elementen een nieuw element wordt toegevoegd. Hierdoor verandert het XPath van het geselecteerde element, dit is terug te zien in figuur 4. <root> <a id=”a_01”> <b id=”b_01”></b> <b id=”b_03”></b> <b id=”b_02”> <c id=”c_01”></c> <c id=”c_02”></c> <c id=”c_03”></c> </b> </a> </root>
Fig 3. Dit is een voorbeeld van een XML document na de toevoeging van een b element.
/root/a[1 and @id=”a_01”]/b[3 and @id=”b_02”]/c[3 and @id=”c_03”] Fig 4. In het voorbeeld is een b element toegevoegd voor het b element van de opmerking, waardoor de waarde met 1 is verhoogd.
Bij het verwijderen van een of meerdere elementen wordt er eerst gezocht naar de
opmerkingen binnen deze elementen. Deze opmerkingen worden vervolgens geplaatst op de dichtstbijzijnde parent uit het XPath pad. Verder wordt er gezocht naar siblings van de verwijderde elementen. Alle opmerkingen die een sibling hebben die na de verwijderde elementen voorkomen, worden verlaagd met het aantal verwijderde siblings. Hiervan is een voorbeeld te zien in figuur 5.
<root> <a id=”a_01”> <b id=”b_01”></b> <b id=”b_03”></b> <b id=”b_02”> <c id=”c_03”></c> </b> </a> </root>
Fig 5. Dit is een voorbeeld van een XML document na de verwijdering van twee c elementen.
/root/a[1 and @id=”a_01”]/b[3 and @id=”b_02”]/c[1 and @id=”c_03”] Fig 6. In dit voorbeeld zijn twee c elementen verwijderd die voor het c element met de opmerking stonden.
Na het toevoegen of verwijderen van elementen worden mogelijk de paden van de
opmerkingen gewijzigd. Zonder dat de gebruiker het doorheeft, worden ook de aangepaste posities naar de externe service gestuurd. Zoals later in dit document wordt besproken, heeft een externe service geen prioriteit.
3.2 Diff algoritme
Het algoritme zoekt de verschillen tussen twee XML documenten, dit kan gedaan worden met DeltaXML, wat binnen FontoXML al wordt gebruikt. Binnen FontoXML wordt dit gebruikt voor Document History, waarbij in detail naar de verschillen tussen twee versies van een XML-document wordt gekeken. De kennis die reeds beschikbaar is kan als basis worden gebruikt voor dit project.
Zodra een document gewijzigd is door een externe editor, wordt er een diff algoritme uitgevoerd op de oude versie van het document en de nieuwe versie. Het verschil tussen deze documenten wordt opgeslagen in een los document. Op basis van dit document kunnen de posities van de opmerkingen aangepast worden.
3.2.1 DeltaXML
Bij DeltaXML wordt het diff document opgesteld op basis van het algoritme wat ze hebben ontwikkeld. Dit houd in dat er per element een attribuut wordt toegevoegd met de wijzigingen die hebben plaatsgevonden tussen de verschillende documenten. Ook is het mogelijk dat er elementen van DeltaXML zelf worden toegevoegd. Dit zullen voornamelijk
deltaxml:textGroup en deltaxml:text elementen zijn.
Bij elementen die niet van DeltaXML zelf zijn worden deltaxml:deltav2 attributen toegevoegd. Deze kunnen verschillende waardes hebben en deze waardes zullen binnen dit project elk een eigen actie krijgen die uitgevoerd moet worden als het voorkomt in het document. In de tabel hieronder staan de verschillende waardes met de acties die verricht moeten worden als het voorkomt in het diff document. Bij deze tabel wordt er vanuit gegaan dat document A het oude document is en document B de nieuwste versie.
Attribuut waarde Betekenis Actie
A=B Dit element is hetzelfde in beide versies.
Geen actie.
A Dit element staat alleen in document A.
Element is verwijderd, paden met siblings moeten worden aangepast. B Dit element staat alleen in
document B.
Element is toegevoegd, paden met siblings moeten worden aangepast. A!=B Dit element is hetzelfde, maar
een van de (klein)kinderen is gewijzigd.
Geen actie op dit element. (Uitleg in paragraaf 3.2.1.1)
Tabel 1. Attribuut waardes van DeltaXML met betekenis en actie voor de applicatie.
Binnen tabel 1 worden de te nemen acties beschreven van de attribuut waardes binnen een DeltaXML delta document. Hierbij hoeft er bij ‘A=B’ geen actie ondernomen te worden, aangezien dit aangeeft dat er geen wijzigingen zijn. Bij ‘A’ en ‘B’ is een element toegevoegd of verwijderd, wat gedaan moet worden staat beschreven binnen het algemene deel van dit document.
3.2.1.1 A!=B
Bij de waarde ‘A!=B’ hoeft in eerste instantie geen actie te worden ondernomen, het geeft aan dat het element hetzelfde is gebleven, maar dat er binnen wel iets is gewijzigd. Deze wijziging kan plaatsvinden in de tekst of in een ander element binnen dit element.
Zodra er tekst gewijzigd wordt, zal DeltaXML hier eigen elementen voor toevoegen om dit aan te geven. Dit is het <deltaxml:textGroup> element, binnen dit element komt echter ook nog het <deltaxml:text> voor. Dat laatste element geeft het verschil in tekst aan binnen het delta document. Dit element komt twee keer voor in een <deltaxml:textGroup> element, een keer voor het deltaxml:deltaV2 attribuut met waarde ‘A’ en een keer met waarde ‘B’.
3.3 Situaties
Voor dit project zijn meerdere situaties beschreven die effect kunnen hebben op de locatie van een opmerking. Deze situaties zijn beschreven door meerdere kolommen waarin is vastgelegd wat de originele en huidige staat is en wat er dan moet veranderen. De kolommen die behandeld worden in het document zijn:
● ID ● Omschrijving ● Origineel ○ XML ○ Pointers ● Huidig ○ XML
○ Pointers (ideale situatie) ● Diff
● Algoritme
○ Pseudo code ○ Fallbacks
● Opmerkingen/Toelichting
Allereerst heeft iedere situatie een ID, dit maakt het mogelijk om gemakkelijk te refereren naar een situatie. Dit gebeurd voornamelijk bij de algoritmes van bepaalde situatie. Verder heeft een situatie een korte omschrijving, dit is een zin met wat de situatie inhoudt. dit geeft algemene informatie over de beschreven situatie.
Vervolgens wordt de originele situatie beschreven. Hierbij wordt de originele XML gegeven waar een opmerking aan hangt. Deze opmerking is in het document aangegeven door rode, vetgedrukte tekst. Verder worden de pointers gegeven waar de opmerking op staat. Deze pointers staan aan het begin en het einde van de selectie, deze selectie wordt door de rode tekst gevisualiseerd.
Daarna wordt de huidige situatie geschetst. Eerst komt hierbij de gewijzigde XML aan bod, deze bevat nog steeds een stuk rode, vetgedrukte tekst. Deze rode tekst is de selectie waar de opmerking op staat na de wijzigingen die zijn doorgevoerd in het document. Ook de pointers van deze selectie worden gegeven.
Naast de huidige situatie staat de diff die is uitgevoerd tussen de twee stukken XML.
Hiervoor is gebruik gemaakt van DeltaXML. Dit algoritme wordt beschreven in paragraaf 3.2 van dit document, het deel specifiek over DeltaXML staat beschreven in paragraaf 3.2.1 van dit document. Voor deze stukken XML is gebruik gemaakt van de demo/sandbox die
beschikbaar is op de website van DeltaXML, waarbij de parameter Word by word is gebruikt voor een beter resultaat.
Vervolgens wordt een mogelijk algoritme beschreven binnen dit document. Het algoritme is opgesteld in code zonder enige implementatie. De implementatie van deze algoritmes zal worden gedaan in de ontwikkelfase van dit project. Naast de code wordt er voor een aantal situaties ook een fallback beschreven. Deze fallback treedt op in situaties waar het
gewenste resultaat niet gehaald kan worden, wat voorkomt door de technische limitaties van het diff algoritme. Al kan het ook voorkomen dat de positie helemaal niet meer bestaat, waardoor de fallback gebruikt wordt.
Tenslotte is er een kolom voor een verdere toelichting van de situatie. Hier is ook ruimte voor eventuele opmerkingen die nodig zijn bij de situatie. Deze opmerkingen kunnen bijvoorbeeld betrekking hebben op het resultaat van het algoritme en hoe dit af kan wijken van de ideale situatie. De scenario’s zijn terug te vinden in bijlage A.
3.3.1 Categorieën
De situaties zijn uiteindelijk te verdelen in een aantal categorieën. Deze categorieën zijn gemaakt door overeenkomsten tussen bepaalde situaties. Er zijn categorieën met een aantal beschreven situaties of met maar een enkele situatie. Het gaat binnen dit project om de volgende categorieën:
● Toevoegen van tekst ● Verwijderen van tekst ● Toevoegen van een sibling ● Verwijderen van een sibling ● Kopiëren van een stuk tekst ● Verplaatsen van een stuk tekst ● Bewerken rondom een opmerking ● Splitsen van een stuk tekst
● Verdwijnen van een ophangpunt
De eerste twee categorieën hebben alleen betrekking op het wijzigen van tekst binnen elementen. Bij de pointers veranderd bij deze situaties alleen de tekstposities. In vergelijking met de andere situaties zijn deze het minst complex, doordat het alleen gaat om deze tekstuele wijzigingen. Deze situaties maken tevens gebruik van hetzelfde algoritme bij de wijzigingen rondom de selectie van de opmerking.
De volgende twee categorieën hebben ook met elkaar te maken en hebben betrekking op wijzigingen met siblings. Hierbij moet gedacht worden aan wijzigingen met de directe siblings van het element, maar ook met de parents of zelfs nog elementen verder terug van het element. Ook deze categorieën zullen gebruik gaan maken van hetzelfde algoritme. Het kopiëren van een stuk tekst staat los als categorie en heeft geen banden met andere categorieën. Deze categorie beschrijft hoe een stuk tekst of een deel ervan wordt
gekopieerd en vervolgens twee keer voorkomt in het document. Met een diff algoritme is het echter moeilijk om te bepalen dat het stuk tekst is gekopieerd. Het kopiëren van een stuk tekst waar een opmerking aan blijft hangen is alleen mogelijk binnen een editor waar andere logica gebruikt kan worden om zo’n bewerking te kunnen detecteren.
Het verplaatsen van een stuk tekst bevat ook meerdere situaties, echter is het niet in alle situaties mogelijk om een opmerking op de gewenste situatie te mappen. In de situaties waar de tekst of een deel ervan wordt verplaatst en een ander id krijgt, is deze tekst niet meer goed om te mappen. Als het originele id nog blijft bestaan, kan het deel dat zich hierin bevind nog wel worden gemapt.
Bij het bewerken rondom een opmerking wordt in het document beschreven wat er gebeurd als een element wordt toegevoegd of wordt verwijderd rondom een selectie van een
opmerking. Ook hierbij wordt gebruik gemaakt van het id om de nieuwe positie goed in kaart te kunnen brengen.
Vervolgens wordt het splitsen van een stuk tekst besproken. Deze categorie bevat maar één situatie, waarbinnen wordt beschreven wat er moet gebeuren als een stuk tekst waar een opmerking aanhangt wordt gesplitst in twee delen. Hierbij heeft het tweede deel een ander id gekregen, waardoor het niet goed gemapt kan worden.
Tenslotte wordt er gesproken over het verdwijnen over het start- of eindpunt. Hierbij is een selectie aanwezig over meerdere elementen waarbij een van deze elementen wordt
verwijderd. Bij deze situaties wordt de selectie aangepast aan het deel wat nog wel bestaat.
3.3.2 Combinaties
Binnen het document worden ook combinaties gegeven van een aantal situaties. Door meerdere situaties te combineren wordt er een beter beeld gegeven van een realistische situatie. Deze combinaties geven een complexere uitkomst van de diff, waar de algoritmes op moeten gaan werken. Bij een van de combinaties is gekozen om veel verschillende situaties te combineren om zo een complexe situatie te creëren.
Zodra een XML-document gewijzigd is in een andere editor, zullen er waarschijnlijk meerdere wijzigingen hebben plaatsgevonden. Om dit na te bootsen zijn er hier situaties gecreëerd waarin meerdere situaties worden gecombineerd. Hierdoor is er een realistischer beeld gecreëerd van het resultaat dat DeltaXML geeft zodra er gewerkt wordt met veel wijzigingen tussen versies.
3.3.3 ID’s
Uit de situaties is gebleken dat het gebruik van id’s voor de mapping essentieel is. Zonder deze id’s is het in veel gevallen niet mogelijk om een correcte mapping te maken en zal teruggevallen moeten worden op de beschreven fallbacks. De mapping is gebaseerd op een stuk tekst binnen een element met een uniek id. Dit id is terug te vinden in de pointers die naar het start- en eindpunt van de opmerking wijzen.
Voor het prototype wordt er uitgegaan van vaste id’s die uniek zijn per document. De id’s zullen dus niet zomaar wijzigen, dit is belangrijk voor het correct kunnen mappen van de opmerkingen. Ook is het niet mogelijk dat een id binnen hetzelfde document meerdere keren voorkomt. Hierdoor zouden opmerkingen op de verkeerde locatie gemapt kunnen worden als er een diff wordt uitgevoerd.
Het gebruik van id’s is in veel gevallen geen probleem, al zijn er natuurlijk uitzonderingen. Zodra er een schema voorkomt zonder id’s, zal er terug worden gevallen op de posities die ook in de XPath aanwezig. Dit heeft alleen minder accurate resultaten dan het gebruik van id’s.
4. Diagrammen
Voor het ontwerp wordt niet alleen nagedacht over algoritmes, maar ook over de verdere structuur van de applicatie. Hiervoor zijn diagrammen gemaakt om dit ontwerp schematisch weer te geven. Deze diagrammen zijn ontwikkeld voor een mogelijke database, al heeft dit voor het prototype geen prioriteit. Tevens wordt de architectuur van de applicatie
beschreven binnen dit hoofdstuk.
4.1 Architectuur
Voor het prototype is er een bepaalde architectuur opgesteld, binnen deze architectuur zijn verschillende componenten te vinden die met elkaar zullen communiceren. De belangrijkste componenten binnen de architectuur zijn de client, de backend en DeltaXML. Verder is een database ook opgenomen in de architectuur, al zal deze niet gebruikt worden binnen het prototype.
Fig. 7. Architectuur van het prototype, waarbij een mogelijke database ook in is opgenomen.
De client is in dit geval een webbrowser waar een webpagina in draait. In praktijk zal dit gaan om FontoXML wat in de browser draait, echter is er voor dit prototype gekozen voor een minimale interface met alleen de benodigde functionaliteiten. De webpagina vraagt de client op bij de server, tevens zal de client door middel van websockets in contact blijven staan met de backend. Door deze websockets is het mogelijk om real-time te communiceren tussen de client en de backend.
In figuur 7 verbindt de server met meerdere clients. Dit komt door de real-time collaboration binnen dit project, het moet mogelijk zijn om met meerdere personen tegelijk opmerkingen te plaatsen. Hier gaan websockets een belangrijke rol spelen, aangezien deze gaan zorgen voor de communicatie tussen de server en de clients.
Binnen de backend worden alle algoritmes uitgevoerd. Deze algoritmes staan beschreven in hoofdstuk 3 van dit document. De backend kan communiceren met DeltaXML voor de toepassing van het diff algoritme. Tevens heeft de backend de mogelijkheid om de
opmerkingen op te slaan. Binnen het prototype zal dit binnen de backend gebeuren, maar later zal dit in een database worden opgeslagen.
4.2 Database
In de database wordt de inhoud en de locatie van de opmerkingen opgeslagen. Een opmerking bestaan uit meerdere posities en hier is ook rekening mee gehouden in het ontwerp van de database. Zo heeft een opmerking een 1-op-veel relatie met een positie. Deze positie heeft een uniek id en een begin- en eindpunt.
Binnen dit project ligt de focus echter niet op het ontwikkelen van een database. Voor het prototype is het niet van belang waar de opmerkingen opgeslagen zullen worden. Hier zal dus ook geen tijd aan worden besteed, al betekent dit niet dat er niet nagedacht wordt over een bepaalde structuur waar de opmerkingen in worden opgeslagen. Hiervoor is een diagram gemaakt om dit schematisch te kunnen weergeven.
Fig 8. Schematische weergave van de opslag van de opmerkingen.
Dit diagram geeft aan dat een opmerking meerdere posities kan hebben. Ook kan een opmerking meerdere reacties hebben. Deze reacties hebben verder geen positie, omdat deze verbonden zijn aan een opmerking, die wel een positie zou kunnen hebben. Het is mogelijk voor een opmerking om geen positie te hebben. Hiervoor wordt een attribuut opgeslagen in het object van de opmerking. Dit attribuut wordt ook gewijzigd als de originele ophangpunten niet meer bestaat en de opmerking wordt teruggezet op de dichtstbijzijnde parent.