Binariseren van XML. Faculteit Toegepaste Wetenschappen Vakgroep Elektronica en Informatiesystemen Voorzitter: prof. dr. ir. J.

Transcriptie

1 Faculteit Toegepaste Wetenschappen Vakgroep Elektronica en Informatiesystemen Voorzitter: prof. dr. ir. J. Van Campenhout Binariseren van XML door Sebastiaan Samyn Promotor: prof. dr. ir. R. Van de Walle Thesisbegeleider: Wim Van Lancker Afstudeerwerk ingediend tot het behalen van de graad van Licentiaat in de Informatica Academiejaar

2 Dankwoord Ik wens iedereen te bedanken die mij geholpen heeft. Vooreerst bedank ik mijn begeleider Wim Van Lancker, om zijn stimulans om mij zelfstandig en op eigen tempo te laten werken. Ook bedank ik Dieter Vekeman, die vorig jaar reeds een grondige studie deed naar BiM en met zijn decoder de basis voor mijn werk heeft voorzien. Daarnaast bedank ik ook de juryleden, die mij tijdens de proefverdedigingen vriendelijk wezen op mijn tekorten, zodat ik wist in welke richting ik verder moest evolueren. Graag wil ik ook een dankwoordje uiten aan mijn ouders, schoonouders, omdat zij mij steunden bij alles wat bij deze thesis kwam kijken. Ik dank ook heel speciaal Ellen omdak ik zonder haar dit nooit tot een goed einde had kunnen brengen. Toelating tot bruikleen De auteur geeft de toelating deze scriptie voor consultatie beschikbaar te stellen en delen van de scriptie te kopiëren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit deze scriptie. i

3 Binariseren van XML door Sebastiaan Samyn Afstudeerwerk ingediend tot het behalen van de graad van Licentiaat in de Informatica Academiejaar Universiteit Gent Faculteit Toegepaste Wetenschappen Vakgroep Elektronica en Informatiesystemen Voorzitter: prof. dr. ir. J. Van Campenhout Promotor: prof. dr. ir. R. Van de Walle Thesisbegeleider: Wim Van Lancker Samenvatting Mobiele toestellen duiken overal op en worden vandaag de dag gebruikt voor een heleboel uiteenlopende taken. De applicaties die voor deze taken instaan steunen meer en meer op het gebruik van XML. Het is een zeer flexibel formaat dat heel wat voordelen heeft. XML heeft echter ook een aantal grote nadelen, het is bv. niet erg efficiënt om in te zoeken en bij de opslag van data gaat nogal wat overhead gepaard waardoor XML bestanden erg groot durven uitvallen. Om net deze problemen aan te pakken is BiM ontwikkeld, een binair formaat voor XML. BiM zorgt niet enkel voor een hoge graad van compressie, maar heeft ook een heleboel voorzieningen om het werken met XML fragmenten efficiënter te maken. Deze thesis sluit aan op de thesis van Dieter Vekeman waarin de ontwikkeling van een BiM Decoder in het.net Compact Framework centraal stond. Er wordt eerst en vooral een studie gedaan van de BiM standaard, om inzicht te verwerven in de werking ervan. Daarna is er vanuit de BiM Decoder bibliotheek overgegaan tot de ontwikkeling van een BiM Encoder. Om later werk te bevorderen is er tenslotte een uitgebreide beschrijving uitgewerkt en ingesloten van de huidige toestand van de bibliotheek. Trefwoorden: BiM, MPEG-B, XML ii

4 Inhoudsopgave 1 Inleiding Probleemstelling Overzicht Het beoogde doel Methodologie Het BiM Formaat Inleiding Situering Overzicht van de opbouw van een BiM stroom Gebruik van BiM Initialisatie Access Unit Fragment Update Unit Fragment Update Command Fragment Update Context Fragment Update Payload Fragment Update Payload Inleiding SimpleTypes ComplexTypes Finite State Automatons Opbouw van de FSA, Fase 1: Type content realization Opbouw van de FSA, Fase 2: Genereren van de syntaxboom Opbouw van de FSA, Fase 3: Normalisatie van de syntaxboom Opbouw van de FSA, Fase 4: Finite state automaton generation Opbouw van de FSA, Een uitgewerkt voorbeeld iii

5 4 Compressie Aanpak Fragment Update Context Fragment Update Payload Conclusie Beschrijving van de BiM decoder Inleiding Mogelijkheden Initialisatie Access Unit Fragment Update Unit Fragment Update Command Fragment Update Context Fragment Update Payload Gebruik Decoderen met behulp van de klasse DOMParser.DOMTree Decoderen met behulp van manuele instellingen Overzicht van de belangrijkste klassen Beschrijving van de BiM encoder Mogelijkheden Initialisatie Access Unit Fragment Update Command Fragment Update Context Fragment Update Payload Gebruik Initialisatie Access Unit Toekomst Implementatie van belangrijke tekorten Attributen en Mixed Content Schema locatie Path Type Codes iv

6 7.1.4 Position Codes Any Element Decoding Basistypes Optimalisatie Voorstelling van een bitstring Schema-analyse fase Besluit 62 Bibliografie 67 v

7 Hoofdstuk 1 Inleiding 1.1 Probleemstelling XML is een technologie die nu reeds geruime tijd een grote opgang maakt als document-en dataformaat. Het is een transparante manier van opslag, doordat de volledige structuur van het document en meestal ook alle data in tekstuele vorm wordt opgeslagen. Dit zorgt voor een zeer uniforme verwerking die uitwisseling van bestanden tussen verschillende applicaties een stuk eenvoudiger maakt. Wat het gevolg is van het gebruik van XML Schema s, deze schema s zijn eveneens XML bestanden, die als functie hebben de structuur van een XML bestand te beschrijven. Zolang er veel data en slechts een beperkte hoeveelheid structuur zit in het document, zal de overhead beperkt blijven (vb.html). Tegenwoordig is dit echter niet meer het geval en wordt deze overhead een belangrijk probleem bij XML. Meer en meer applicaties wisselen XML-bestanden uit die zeer veel structuur bevatten en erg groot zijn, wat leidt tot zeer veel overhead. Daarbovenop komt nog eens dat er meer en meer toepassingen zich bevinden in mobiele omgevingen en embedded toepassingen. Dit zijn typisch omgevingen die over een beperkte bandbreedte beschikken en steunen op streaming. Hiervoor is XML duidelijk niet erg geschikt en zal een oplossing moeten worden gevonden om gebruik van XML toe te laten. 1.2 Overzicht Het beoogde doel Het doel van deze thesis bestaat erin om een BiM encoder te implementeren in het.net Compact Framework. Deze kan dan in combinatie met de BiM decoder, die werd geschreven door Dieter Vekeman [3], aangewend worden om effectief de problemen die voor 1

8 komen bij XML in een mobiele omgeving op te lossen. De bedoeling zal zijn om zowel de decoder functionaliteit als de encoder functionaliteit te bundelen in één bibliotheek. Hierdoor kunnen we de hoeveelheid code die gedeeld wordt tussen encoder en decoder maximaliseren, zodat de footprint van de bibliotheek zeer klein gehouden wordt. Dit zou ook de stabiliteit ten goede moeten komen, aangezien er zo een kleinere kans is op fouten. Een ander voordeel is dat optimalisaties op de decoder automatisch een positief effect zullen hebben op de encoder Methodologie Om kennis op te doen omtrent BiM, zal het noodzakelijk zijn eerst de BiM standaard te bestuderen, gebruik makend van de ISO beschrijving en de thesis van Dieter Vekeman. Ook een grondige studie van de code van de decoder is nodig. Eens dit is gebeurd, kan overgegaan worden tot de implementatie, gebruik makend van de bestaande code. Wanneer het niveau van implementatie van de encoder gelijk is aan dat van de decoder, zal het nodig zijn om simultaan encoder en decoder te implementeren. Over de BiM standaard zelf is nogal wat onduidelijkheid, doordat de referentie software er al eens van durft afwijken. Om alle verwarring te vermijden, zal de bibliotheek geïmplementeerd worden om strikt compatibel te zijn met de ISO beschrijving. 2

9 Hoofdstuk 2 Het BiM Formaat 2.1 Inleiding Situering Het Binary MPEG format for XML, of kortweg BiM, maakt deel uit van het MPEG-7 framework. Dit framework is een standaard voor het beschrijven van audio- en videofragmenten. Deze beschrijvende data wordt onder de vorm van XML opgemaakt, opgeslagen en verstuurd. Doordat deze beschrijvingen over het algemeen vrij groot zijn, komen de nadelen van XML heel sterk naar voor. Het Binary MPEG format for XML is ontwikkeld om net deze nadelen aan te pakken op de plaatsen waar ze een probleem vormen. Op figuur 2.1 zien we een eenvoudig XML fragment, daaruit vertrekkende merken we een aantal nadelen van XML op die BiM tracht op te lossen. In het voorbeeld zien we een mogelijke voorstelling van een klant, hierbij wordt de voornaam, naam en leeftijd opgeslagen. Een eerste eigenschap, die zeer duidelijk in het oog springt, is de verbositeit van XML. Wanneer we tellen hoeveel karakters instaan voor de structuur, dan merken we dat dit maar liefst 78 van de 120 karakters zijn. Net iets minder dan twee derde van de totale grootte is dus louter te wijten aan structuur. Anders dan klassieke compressie-technieken, gaat BiM uit van kennis opgedaan uit een XML Schema[2] en niet van zuivere redundantie. XML Schema is een techniek die de mogelijkheid biedt, om op een gestandaardiseerde manier de structuur van de XML data vast te leggen. Doordat het mogelijk is om aan de hand van een XML schema een accuraat beeld te krijgen van hoe een XML fragment, die aan het schema voldoet, er moet uit zien, zal het, bij het binariseren van dat fragment, dan ook mogelijk zijn deze structuur op een zeer efficiënte manier op te slaan. 3

10 <Klant> <Voornaam>Voornaam van de Klant</Voornaam> <Naam>Naam van de Klant</Naam> <Geboortejaar>1980</Geboortejaar> </Klant> Figuur 2.1: Een eenvoudig XML fragment. Een ander probleem is dat een groot stuk XML data moeilijk is om te streamen. Wanneer in ons voorbeeld een aanpassing zou gebeuren, bijvoorbeeld correctie van de geboortedatum, dan is het noodzakelijk om het volledige fragment opnieuw door te sturen. Alle 120 karakters moeten dus opnieuw worden verstuurd, terwijl in essentie er maximaal 4 kunnen veranderen. Het is ook zo dat, wanneer iemand de voornaam van een klant opvraagt, opnieuw de volledige klant wordt verstuurd. Het monolithisch karakter van XML zal trouwens nog zwaarder doorwegen bij een realistisch voorbeeld waar het geheel, zowel de data als de structuur, nog vele malen groter zal zijn. BiM zal dit probleem aanpakken door veel dynamischer om te gaan met de XML boom. Het komt erop neer dat de elementaire bouwstenen van een BiM datastroom zullen bestaan uit bewerkingen op de XML boom, aan de zijde van de BiM decoder. Hierover meer in sectie Overzicht van de opbouw van een BiM stroom Een BiM stroom zal steeds beginnen met een initialisatie, deze zal een heleboel belangrijke parameters van de decoder instellen. Het gaat om de parameters die gebruikt zijn om de XML te encoderen en deze zullen voor een deel bepalen hoe de verdere stroom eruit ziet. Na de initialisatie bestaat de stroom enkel nog uit een opeenvolging van access units. De decoder zal een XML boom bijhouden. De verwerking van iedere access unit zal een aantal operaties uitvoeren op de boom, zoals knopen toevoegen, wijzigen of verwijderen. Tussen de verwerking van twee access units door, moet de XML boom geldig zijn (volgens de XML Schema s die aangegeven zijn door de initialisatie). Een access unit bestaat op zijn beurt uit nul of meer schema update units en één of meer fragment update units. Een voorziening binnen BiM is de dynamische uitbreiding van de gekende datatypes en toevoegen van nieuwe datatypes. Dit gebeurt door middel van de Schema Update Units die worden opgenomen in de Access Units. Deze mogelijkheden zorgen voor een extra flexibiliteit binnen het formaat. Het is bijvoorbeeld mogelijk om slechts een zeer beperkt XML Schema op te stellen en mee te geven in de initialisatie en dan, volgens de noden van de access unit, dit schema uit te breiden met behulp van schema update 4

11 unit. Doordat eerst de schema update units worden verwerkt en daarna pas de fragment update units kan de nieuwe schemakennis bovendien onmiddellijk worden toegepast bij de verwerking van de fragment update units. De fragment update units zijn de eigenlijke bouwstenen die de te decoderen XML gegevens bevatten. Een fragment update unit zal uit meer bestaan dan gegevens alleen, het beschrijft in feite een operatie die moet worden uitgevoerd op de XML boom in de decoder. Binnen een fragment update unit zijn drie verschillende onderdelen te onderscheiden, eerst en vooral is er de fragment update command. Dit commando zal de actie beschrijven die de fragment update unit op de XML boom kan uitvoeren. Een tweede onderdeel is de fragment update context, de context zal beschrijven op welke node in de boom de fragment update unit zal inwerken. Het laatste deel is de fragment update payload, de payload bevat de eigenlijke data die zal nodig zijn om het commando uit te voeren. Wanneer we het voorbeeld uit figuur 2.1 terugnemen, dan zou een mogelijke fragment update unit volgende elementen kunnen hebben: Command: CHANGE Context: Klant/Voornaam Payload: nieuwe voornaam Gebruik van BiM Belangrijk om aan te duiden is dat BiM eigenlijk een intermediair formaat is. Het is gericht op een efficiënte opslag en overdracht van XML, het is helemaal niet de bedoeling dat BiM XML vervangt, wel dat beide elkaar aanvullen. Figuur 2.2 geeft een schematisch overzicht van het gebruik van het binair formaat. Zowel de encoder als de decoder moeten beschikken over het XML Schema. Eerst zal de encoder het schema, die de te verzenden XML beschrijft, analyseren en de nodige interne structuren opbouwen om de XML te kunnen verwerken. Vervolgens zal het deze kennis aanwenden om de XML data om te zetten naar een binaire BiM stroom die wordt verstuurd naar de andere zijde. Aan de andere zijde zal de BiM Decoder eveneens het schema analyseren en aan de hand van die kennis de binaire stroom opnieuw decoderen tot zuivere XML. 5

12 Figuur 2.2: Overzicht van het gebruik van BiM. MPEG stelt een architectuur voor, voor de verwerking van BiM data en legt de voorwaarden vast waaraan de diverse elementen moeten voldoen. Er wordt uitgegaan van 3 grote lagen: de delivery of ontvangstlaag, de systeemlaag en de applicatielaag. De met BiM gecomprimeerde gegevens komen binnen via de ontvangstlaag en worden doorgegeven naar de systeemlaag. De abstracte voorstelling van de ontvangstlaag kan in een echte situatie heel wat mogelijke gedaanten aannemen, bijvoorbeeld een gewoon binair bestand, een tcp-stream, enzovoort. Deze laag moet echter wel aan enkele voorwaarden voldoen. Een aantal daarvan zijn vrij vanzelfsprekend, zoals bijvoorbeeld De ontvangstlaag moet een manier van communicatie voorzien tussen de zijde die de stroom produceert en de zijde die ervan leest, daarom sommen we hier enkel de relevantste regels op: De access units moeten in de volgorde kunnen gedecodeerd worden, waarin ze geencodeerd zijn, wanneer dit vereist is vanuit de encoder. De access units moeten vrij zijn van bitfouten, of er moet een indicatie van de fout zijn. Het moet mogelijk zijn de systeem laag de initialisatie te leveren, vóór de eerste access unit wordt verwerkt. Als een toepassing access units van gelijke grootte vereist, dan is het de verantwoordelijkheid van de ontvangstlaag om deze functionaliteit transparant aan de systeem laag te voorzien. 6

13 De systeemlaag zal de eigenlijke BiM-functionaliteit implementeren. Deze laag zal, op vraag van de applicatielaag, de stroom decoderen en de XML doorgeven. Ook het ophalen en verwerken van onder andere de XML Schema s en eventueel de Fragment References 1 is een taak voor de systeemlaag. Deze opstelling is geïllustreerd in figuur 2.3. In de figuur is duidelijk te zien dat de opstelling aan zowel encoder zijde als aan decoder zijde zeer gelijkaardig is. Hoewel dit niet noodzakelijk zo hoeft te zijn (MPEG spreekt immers totaal niet over hoe de bits op de delivery layer moeten terecht komen), zal het toch de situatie zijn die in de praktijk vaak voorkomt. Figuur 2.3: De Application layer, BiM of System layer en Delivery Layer. De essentie van deze figuur is dat de applicatielaag enkel gegevens uitwisselt met de systeemlaag onder de vorm van XML en de systeemlaag vervolgens enkel gegevens uitwisselt met de ontvangstlaag onder de vorm van BiM. Op deze manier komt de applicatie volledig los te staan van BiM en moet ze zich enkel nog aantrekken van XML. 1 Fragment References worden verder uitgebreider beschreven. Het is voldoende te weten dat dit stukken uit de stroom zijn die vervangen worden door een locatie die aanduidt waar het stuk in kwestie te vinden is. 7

14 2.2 Initialisatie Een BiM stroom begint steeds met de initialisatie van de decoder, per document mag er slechts één initialisatie zijn. De initialisatie is een blok bits die belangrijke parameters instellen, die nodig zijn voor het decoderen van de inkomende data. De ingestelde parameters zullen een grote invloed hebben op hoe de stroom eruit zal zien en hoe ze verwerkt wordt, zowel bij de encoder als bij de decoder. Een volledige opsomming van alle instellingen zou hier niet veel zin hebben, daarom verwijzen we hiervoor naar de standaard [1]. Toch is het zeker nuttig om enkele belangrijke parameters toe te lichten. De initialisatie begint met een hele reeks zogenaamde Feature Flags, deze vlaggen geven zaken aan zoals hoe de payload (zie sectie 2.4.3) moet worden gedecodeerd, of er bij het decoderen rekening moet worden gehouden met additionele schema s en of er onderweg updates kunnen binnenkomen voor deze schema s. Het volgende deel van de initialisatie is vooral gericht op de URI s van de schema s en de locaties ervan (vb. schemauri: thesis, schemalocation: Het is wellicht het belangrijkste stuk van de hele initialisatie en zal ervoor zorgen dat de XML Schema s kunnen ingelezen en geanalyseerd worden door de decoder. Deze analyse zal later nodig zijn om het contextpath en de payload te kunnen opbouwen en decoderen (zie resp. sectie en 2.4.3). Verder wordt in dit stuk van de initialisatie ook ingelezen of er wordt gewerkt met zgn. Type Codecs, welke Type Codecs worden gebruikt en op welke datatypes ze zullen inwerken. Type Codecs, of optimised decoders, specifiëren hoe een bepaald datatype gecodeerd wordt zonder gebruik te maken van de generische voorzieningen, vb. ZLib. De initialisatie eindigt met de configuratie van de Fragment References en eventueel het initieel document. Fragment References zijn verwijzingen naar een payload (zie sectie 2.4.3) die ofwel onmiddellijk, ofwel later kunnen worden opgehaald om gedecodeerd te worden, maar die zich dus niet in de stroom zelf bevinden, maar op een externe locatie. Het is wel zo dat het uitstel voor het decoderen van een node enkel kan gebeuren indien het XML document nog steeds geldig is, als de node weggelaten wordt. De oorzaak hiervan ligt in het feit dat de applicatie de nodes, waarvan het decoderen uitgesteld is, niet te zien krijgt en het XML document geldig moet zijn (volgens de opgegeven XML Schema s) op het einde van het decoderen van elke access unit (zie sectie 2.3). 2.3 Access Unit De access units vormen de eerste logische opsplitsing van een BiM stroom. Het zijn als het ware capsules die de fragment update units en schema update units groeperen, meer 8

15 dan dit doet een access unit niet. Bij de verwerking van een access unit worden eerst alle schema update units verwerkt. De schema update units bevatten nieuwe datatypes en uitbreidingen van bestaande datatypes. De aanwezigheid van schema update units is niet verplicht, het kan dus best dat een access unit enkel uit fragment update units bestaat. Bij fragment update units is dit uiteraard niet het geval er is steeds minstens één fragment update unit aanwezig per access unit. Een beschrijving van de werking van de schema update units wordt in deze thesis niet gegeven, dat komt omdat in deze studie van BiM de overdracht van data centraal staat. De werking van de schema update units valt dus buiten het bestek van deze thesis. Een uitgebreide beschrijving van de werking van de fragment update units volgt in sectie Fragment Update Unit Het is vrij duidelijk dat een XML document een tekstuele voorstelling van een boomstructuur is, dit is ook de voorstelling die zal gekozen worden bij het decoderen en encoderen van de access units. Zoals in de inleiding reeds werd aangehaald zal elke fragment update unit eigenlijk een operatie representeren op die boom, die de Current Document Tree (CDT) genoemd wordt. Hierbij zal het niet de root van het document zijn die root node is, maar wel een speciale selector node, dit is een fictieve node waar de root van het document aan zal worden opgehangen (zie figuur 2.4). Deze manier van werken zal zijn voordelen hebben bij het opbouwen van het contextpad (zie sectie 2.4.2). Figuur 2.4: Illustratie van de selector node. Daarnaast bestaat ook de Binary Format Document Tree (BFDT), die wordt opgebouwd aan de hand van de elementen uit het schema. De BFDT maakt het mogelijk om alle geldige paden, uit het schema, voor te stellen en te adresseren. Deze paden hoeven 9

16 niet noodzakelijk aanwezig te zijn in de CDT, maar het is wel zo dat alle paden in de CDT ook terug te vinden zijn in de BFDT. Het is met andere woorden een voorstelling van de schema-kennis omtrent de mogelijke paden in het XML document Fragment Update Command Een fragment update unit kan één van de momenteel vier mogelijk commando s aanwenden om uit te voeren op de boom. Het commando wordt beschreven door een bitstring van vier bits, naar de toekomst toe is uitbreiding dus nog mogelijk naar maximaal 16 commando s. Een overzicht van de mogelijkheden: AddContent voegt het fragment, die in de payload zit, toe aan de CDT op de plaats aangeduid door het contextpad. De nieuwe node in de CDT zal de laatste node zijn van het contextpad (zie sectie 2.4.2). ReplaceContent vervangt de node in de CDT, die aangewezen wordt door het contextpad, door het fragment die bevat zit in de huidige payload. DeleteContent verwijdert de node aangewezen door het contextpad uit de CDT. Deze fragment update unit hoort geen payload te hebben. Reset verwijdert alle nodes uit de CDT Fragment Update Context Inleiding De context van een fragment update unit specifieert de node waarop het fragment update command moet worden uitgevoerd. Daarbovenop zal de fragment update context ook aanduiden wat het datatype is van de node die gecodeerd is in de payload (zie hiervoor bespreking van een TBC op pg 12). De context zal bestaan uit een sequentie bits die een pad definiëren doorheen de BFDT. Voor deze omzetting worden, bij de analyse van het schema, tabellen opgesteld die bitstrings bevatten voor de navigatie doorheen de BFDT. Per type is er een tabel en elke lijn in de tabel staat voor een volgende stap in de boom. Voor de verwerking worden dus bits van de context genomen en gematched tegen de strings in de tabellen om zo de volgende stap in de boom te nemen. De tabellen worden Tree Branch Code tabellen of TBC tabellen genoemd, een lijn wordt een Tree Branch Code of TBC genoemd. Elke tabel wordt geassocieerd aan een 10

17 complextype en opgesteld door voor elk kind van dat complextype een TBC aan te maken. Ook wordt een TBC tabel voorzien voor de selector node die overeenkomt met alle globale elementen gedefiniëerd in het schema. Uiteindelijk komt men, na de interpretatie van de fragment update context, tot het contextpad, dit is dan het eigenlijke pad door de boom. Er bestaan twee types van contextpaden. De eenvoudigste zijn de absolute contextpaden, hierbij zal steeds gestart worden bij de selector node. Een tweede soort is het relatieve contextpad, dit vraagt van de decoder dat een current node wordt bijgehouden. De current node is de node waar de laatste operatie op werd uitgevoerd, initieel is dit eveneens de selector node. Uitgaande van deze current node kan dan een relatief pad worden opgesteld, dit pad kan hierdoor veel korter zijn dan een absoluut pad. Het is trouwens ook zo dat in de TBC tabellen ook steeds een TBC bestaat naar de ouder van het huidige element in de boom, het is vanzelfsprekend dat dit een belangrijke TBC zal zijn bij relatieve adressering. Een voorbeeld van deze verschillende contextpaden wordt geïllustreerd in figuur 2.5. De keuze tussen relatieve en absolute adressering wordt doorgegeven net voor het decoderen van het contextpad dmv. de contextmodecode. Figuur 2.5: Links een voorbeeld van absolute adressering, rechts een voorbeeld van relatieve adressering. 11

18 Tree Branch Codes Een TBC bestaat uit vier delen: 1. De SBC of Schema Branch Code is de bitstring die moet worden teruggevonden in de fragment update context om deze TBC te selecteren. 2. Een Substitutiecode die wordt gebruikt wanneer de declaratie van het element eigenlijk een referentie is naar een substitutiegroep. 3. Path type code zal belangrijk zijn wanneer de SBC en de subtitutiecode een element aanwijzen die een basistype is van andere afgeleide types (dit komt uiteraard enkel voor wanneer een extension of restriction in het XML Schema zit). 4. Position code is een code die, in het geval van een element met occurrence 2 groter dan één, nodig is om aan te duiden op welk kind van de node, die van het type is dat wordt aangeduid door de SBC en substitutiecode, de context slaat. De TBC tabellen Voor elke complextype in het schema zijn er twee TBC tabellen, de ContextTBC tabel en de OperandTBC tabel. De ContextTBC tabel zal enkel verwijzingen (TBC s dus) bevatten naar zijn kinderen die eveneens complextype zijn. Daarnaast zal ook nog een TBC in de tabel staan die verwijst naar zijn ouder en een TBC die de Path Termination Code (PTC) noemt, deze duidt aan wanneer het navigeren doorheen de boom zal stoppen. De tweede tabel, die toegekend is aan alle complextypes uit het schema, is de OperandTBC tabel. Deze tabel zal alle kinderen bevatten van de complextype, dus ook alle simpletype elementen, elementen met simplecontent en alle attributen. De OperandTBC tabel bevat noch een PTC, noch een verwijzing naar zijn ouder. Het is wel zo dat, in het geval van een element met mixed content 3, de tabel een TBC bevat voor de data die zich tussen de elementen kan bevinden. Ook zijn er voorzieningen voor User Data Extension 4. 2 Occurence is een eigenschap die voorkomt in XML Schema en uitdrukt hoe vaak een bepaald element kan voorkomen. De waarde ervan gaat van nul tot oneindig. 3 Een element met mixed content is een complextype element die, zoals gedefiniëerd in het schema, naast andere elementen ook nog gegevens tussen zijn tags kan hebben 4 De SBC die wordt toegekend aan de User Data Extension bestaat altijd enkel uit nullen. User Data Extension brengt de mogelijkheid aan om om het even welke data in te voegen. Wanneer deze functie door de decoder niet wordt ondersteund, wordt gewoon overgegaan naar de volgende fragment update unit. 12

19 Genereren van de TBC tabellen Bij het genereren van de tabellen worden eerst twee standaard TBC s vastgelegd. In de ContextTBC tabel zijn dit de verwijzing naar de ouder (allemaal nullen) en de PTC (allemaal nen). Voor de OperandTBC tabel zijn dit de User Data Extension code (allemaal nullen) en de TBC voor de data van een complextype met een mixed content model (allemaal nullen en een eentje, vb. 001). Deze laatste is echter optioneel en zal dus niet steeds voorkomen! Vervolgens worden alle kinderen alfabetisch gerangschikt, hiervoor legt de standaard heel wat regels op, maar deze vermelden we hier niet expliciet. Eens de kinderen gesorteerd zijn, worden de SBC s in die volgorde sequentieel toegekend. Een uitgewerkt voorbeeld Om het opbouwen van de tabellen en het gebruik ervan toe te lichten, werken we hier even een voorbeeld uit. Hiervoor zullen we een complextype definiëren met een vrij eenvoudige structuur, zie het XML Schema uit figuur 2.6. Ter illustratie is een voorbeeld van een instantie van dit complextype te zien in figuur 2.7. Voor dit eenvoudig voorbeeld stellen we nu de tabellen op voor het complextype boek. We beginnen bij het opstellen van de ContextTBC tabel. Eerst bepalen we hoe lang de SBC s moeten zijn in de TBC tabel, dit kan op een eenvoudige wijze door gebruik te maken van log 2. ceil(log 2 (aantal elementen + 2)) = ceil(log 2 ( )) = 3 De reden waarom bovenop het aantal elementen nog eens twee wordt opgeteld, is uiteraard omdat er ook SBC s voorzien moeten worden voor de PTC en de verwijzing naar de ouder. Eens we uitgerekend hebben hoe lang de bitstrings moeten zijn, herschikken we de kinderen van de complextype. In ons voorbeeld is dit een gewone sequence, hierdoor moeten we er geen speciale operaties op uitvoeren, behalve dan alfabetisch rangschikken. Eens dit is gebeurd delen we de SBC s uit, te beginnen bij de ouderverwijzing, vervolgens het eerste element van de gerangschikte reeks, enz. tot het laatste element van de reeks en tenslotte de PTC. Wanneer dit is gebeurd, krijgen we voor de Context TBC tabel tabel

20 SBC Boomsprong 000 ouder 001 auteur 010 isbn 011 jaar 100 titel 101 uitgever 111 PTC Tabel 2.1: De ContextTBC tabel. Het opstellen van de OperandTBC tabel is eigenlijk op quasi dezelfde manier. In ons voorbeeld is er geen sprake van mixed content en ook niet van User Data Extension, hiermee moet worden rekening gehouden bij het berekenen van de lengte van de SBC s. Concreet wordt deze lengte als volgt berekend: ceil(log 2 (aantal elementen + aantal attributen + simplecontent + 1)) = ceil(log 2 ( )) = 3 De berekening wijkt dus licht af van deze van de ContextTBC tabel, hierbij is simplecontent een booleaanse variabele die nul zal zijn wanneer het complextype enkel over complexcontent beschikt en één zal zijn wanneer het complextype over simplecontent beschikt (dit is dus in het geval met mixed content). Hier wordt eerst de User Data Extension aan de tabel toegevoegd. In het geval van een mixed content model krijgt ook de verwijzing naar de data tussen de elementen zijn vaste SBC en dan worden alle kinderen in volgorde toegevoegd. Dit geeft voor ons voorbeeld de tabel 2.2. SBC boomsprong 000 user data extension 001 auteur 010 isbn 011 jaar 100 titel 101 uitgever Tabel 2.2: De OperandTBC tabel. De tabellen voor de selector node en het complextype van de auteur zijn eveneens bijgesloten op het einde van het hoofdstuk (resp. tabel 2.3 en tabel 2.4). Navigatie door de tabellen Ook het gebruik van de tabellen kunnen we toelichten aan de hand van het uitgewerkte voorbeeld. Stel dat we een contextpad willen encoderen naar de voornaam van een auteur 14

21 van een boek. Het contextpad is dan dus selector/boek/auteur/voornaam. We starten in de ContextTBC tabel van de selector, daaruit selecteren we de SBC van boek, namelijk 01. Vervolgens nemen we de ContextTBC tabel van boek en selecteren dan de SBC van auteur, namelijk 001. Uit de ContextTBC tabel van auteur wordt dan de SBC van de PTC geselecteerd, namelijk 11, om de navigatie hier te bëeindigen en duidelijk te maken dat het element dat we moeten hebben een kind is van auteur. Tenslotte nemen we de OperandTBC tabel van auteur en selecteren we daaruit de SBC van het element voornaam, met name 10. De encodering van het contextpad levert dus de bitstring op. Het decoderen van een bitstring tot een contextpad verloopt op analoge wijze. Laten we de gevonden bitstring uit vorige paragraaf eens decoderen. Bij het decoderen komt het erop neer om steeds de bitstring te laten matchen op elementen van de ContextTBC tabellen tot we aan een PTC komen en overgaan op de OperandTBC tabel. We beginnen opnieuw in de ContextTBC tabel van de selector. Daar zijn de strings twee bits lang, we moeten dus 01 matchen. Dit levert het element boek op. In de ContextTBC tabel van boek zijn de elementen drie bits lang, dus nemen we nu het element met SBC 001, dit is auteur. In de tabel van auteur zijn de elementen opnieuw twee bits lang, de string 11 selecteert de PTC, dus hier gaan we over op de OperandTBC tabel van auteur. We lezen tenslotte de laatste twee bits in, 10 en deze duiden nu voornaam aan. Wanneer we nu al onze stappen door de boom in een contextpad gieten, bekomen we selector/boek/auteur/voornaam Fragment Update Payload Het encoderen en decoderen van fragment update payloads gebeurt aan de hand van finite state automatons, vanwege de complexiteit van het opbouwen van deze automatons zullen we dit in een afzonderlijk hoofdstuk (Hoofdstuk 3) behandelen. 15

22 <?xml version="1.0" encoding="utf-8"?> <xs:schema xmlns="boekns" xmlns:xs=" targetnamespace="boekns" elementformdefault="qualified"> <xs:element name="boek"> <xs:complextype> <xs:sequence> <xs:element name="titel" type="xs:string"/> <xs:element name="auteur"> <xs:complextype> <xs:sequence> <xs:element name="voornaam" type="xs:string" /> <xs:element name="naam" type="xs:string" /> </xs:sequence> </xs:complextype> </xs:element> <xs:element name="uitgever" type="xs:string"/> <xs:element name="isbn" type="xs:string"/> <xs:element name="jaar" type="xs:int"/> </xs:sequence> </xs:complextype> </xs:element> </xs:schema> Figuur 2.6: Het schema die we zullen analyseren tot TBC tabellen. <boek xmlns="boekns"> <titel>modern compiler implementation in C</titel> <auteur> <voornaam>andrew</voornaam> <naam>w. Appel</naam> </auteur> <uitgever>cambridge University Press</uitgever> <isbn> </isbn> <jaar>1998</jaar> </boek> Figuur 2.7: Een instantie van het complextype gedefiniëerd in het schema uit figuur 2.6. ContextSBC Boomsprong 00 ouder 01 naam 10 voornaam 11 PTC OperandSBC boomsprong 00 user data extension 01 naam 10 voornaam Tabel 2.3: De TBC tabellen voor auteur. 16

23 ContextSBC Boomsprong 00 ouder 01 boek 11 PTC OperandSBC boomsprong 00 user data extension 01 boek Tabel 2.4: De TBC tabellen voor de selector. 17

24 Hoofdstuk 3 Fragment Update Payload 3.1 Inleiding Na de verwerking van het commando en het contextpad van de fragment update unit is er genoeg informatie verzameld om tot de verwerking van de payload over te gaan. Belangrijk is om op te merken dat er twee grote klassen van payloads bestaan, payloads die enkel een simpletype bevatten (bijvoorbeeld het element voornaam uit figuur 2.7) en payloads die een complextype bevatten (bijvoorbeeld het element boek uit figuur 2.7). De verwerking van deze twee soorten gebeurt op een volledig andere manier, doordat een simpletype enkel data bevat, terwijl een complextype naast data ook structuur bevat. Bij het decoderen van een payload die uit een simpletype bestaat, zal enkel data op de stroom staan. We weten ook van welk type de data is, doordat de fragment update payload reeds is verwerkt. Het aantal types is beperkt tot deze die gedefiniëerd zijn binnen de XML Schema standaard. De MPEG-B standaard legt voor elk van deze types een manier van decoderen (en dus ook van encoderen) vast. Bij complextypes ligt de verwerking moeilijker, doordat er ook structuur mee in de payload zit, daarom maken we hiervoor gebruik van finite state automatons (FSA s) om een abstracte voorstelling te maken van deze structuur. Deze voorstelling zal pas kunnen worden bereikt na een schema-analyse van het element in kwestie. De voordelen, die verbonden zijn aan het gebruik van FSA s, zijn ondermeer schaalbaarheid, eenvoud en een uniforme aanpak. Eens de automatons zijn opgebouwd, zal het bij de verwerking van de bitstroom (of encodering van een bitstroom) erop neerkomen enkel nog bits te consumeren wanneer het echt nodig is (b.v. bij een choice), op deze manier blijft het aantal bits, die naar structuur gaat, beperkt tot een absoluut minimum. 18

25 3.2 SimpleTypes Voor de volledigheid geven we hier een kort overzicht van de simpletypes en hoe ze gecodeerd worden. boolean een 1 voor waar, een 0 voor vals float als IEEE 754 floating point, single precision double als IEEE 754 floating point, double precision hexbinary en base64binary worden zo (in binaire vorm dus) op de stroom gezet, met daaraan voorafgegaan de grootte van de data in bits. integers, enumerations, lists en unions hebben een manier van encoderen die wordt gedefiniëerd door MPEG-B zelf, we verwijzen dan ook daarnaar voor de details hiervan. De rest 1 wordt gecodeerd als een UTF-8 string die wordt voorafgegaan door zijn lengte in bytes. Wanneer een lengte moet worden gecodeerd, dan is dit in de bovenstaande opsomming steeds door middel van VLUIMSBF5, deze manier van coderen staat eveneens uitgebreid beschreven in de standaard. Aangezien dit voorzieningen zijn om efficiënt deze datatypes te coderen, spreekt het ook voor zich dat ook bij het coderen van de complextypes daarvan zal worden gebruik gemaakt. 3.3 ComplexTypes Zoals hierboven reeds vermeld, worden complextypes gecodeerd en gedecodeerd door middel van finite state automatons. Het opbouwen van deze automatons is geen eenvoudige zaak, dit pogen we als volgt uit te leggen. We beginnen met even kort te verklaren wat een finite state automaton is en hoe ze wordt gebruikt. Vervolgens bespreken we de schema-analyse die voorafgaat aan de opbouw van de automatons. Uiteindelijk komen we zo bij hoe de automatons opgebouwd worden. Tenslotte bespreken we nog een uitgewerkt voorbeeld, waarin de zaken zoveel mogelijk worden toegepast. 1 Wegens het grote aantal types verwijzen we hier naar MPEG-B, al deze types hier opnoemen zou de opsomming toch niet ten goede komen. 19

26 We gaan voor de rest van het hoofdstuk ervan uitgaan dat we aan het decoderen zijn, we gaan dus steeds bits lezen van de stroom. De manier van werken in het geval van het coderen gebeurt volledig analoge wijze. De automatons worden doorlopen en telken we op een plaats komen waar de decoder bits zou lezen zal de encoder die bits naar de BiM stroom schrijven Finite State Automatons De verwerking van een complextype wordt geleid aan de hand van finite state automatons (FSA). Een FSA, of eindige toestands automaat, bestaat uit transities en toestanden. Het is een gerichte graaf waarbij de toestanden de knopen uit de graaf zijn en de transities de paden tussen de knopen. Figuur 3.1: Voorbeeld van een FSA. Een FSA heeft exact één begintoestand en één eindtoestand, er is ook slechts één token die kan navigeren doorheen de FSA. Bij het begin van de verwerking zal het token starten in de begintoestand, het zal dan door de FSA stappen langs de transities, van de ene toestand naar de andere. Hierbij zal het in sommige toestanden nodig zijn om bits in te lezen en te verwerken voor de volgende transitie kan worden genomen. Wanneer het token de eindtoestand, bereikt zal de verwerking klaar zijn. Wanneer een transitie wordt genomen en het token in een nieuwe toestand terecht komt, dan wordt die toestand geactiveerd. Bij het activeren van een toestand of het nemen van een transitie kan een actie worden uitgevoerd, bijvoorbeeld bij de activering van een toestand waar meerdere transities mogelijk zijn (zoals in de tweede toestand uit figuur 3.1) kunnen er bits worden ingelezen om te beslissen welke de volgende transitie zal zijn. Soorten transities Tussen de toestanden bestaan verschillende soorten transities die elk hun eigen doel hebben, hier volgt een kort overzicht: 20

27 Element Transitions specificeren welk element nu komt in het document. Wildcard Transitions specificeren dat nog geen type gekend is, van het element die nu komt in het document. Loop Transitions worden gebruikt om lussen te modelleren, deze lussen komen voor bij elementen die in het schema gedefinieerd zijn met een occurrence groter dan één. Er zijn drie soorten Loop Transitions, namelijk Loop Start, die genomen wordt aan het begin van een lus, Loop Continue, die genomen wordt als er nog minstens één element volgt in de lus en Loop End, die wordt genomen wanneer geen elementen meer in de lus moeten worden verwerkt. Code Transitions worden genomen wanneer hun overeenkomstige binaire code werd gelezen van de stroom. Ze komen voor wanneer er keuze is tussen meerdere transities vanuit een bepaalde toestand. Er zijn twee speciale code transitions, namelijk Shunt Transition, die steeds als binaire code 0 heeft en de Mixed Transition, die als binaire code steeds 1 heeft. Een mixed transition duidt aan dat er zich tussen het vorige en het volgende element een string bevindt. Simple Transitions zijn enkel bedoeld ter ondersteuning van de structuur van de FSA en hebben geen specifieke functionaliteit wanneer ze worden genomen. Soorten toestanden Type States zullen, bij het activeren, zorgen voor de verwerking van het huidige element. Bij het decoderen houdt dat bijvoorbeeld in dat de decoder voor het type wordt opgeroepen. Simple States zullen, net als een simple transition, enkel dienen ter ondersteuning van de structuur van de FSA, maar geen specifiek gedrag hebben Opbouw van de FSA, Fase 1: Type content realization In de type content realization fase analyseren we de type definitie uit het schema van het complextype in kwestie om tot een realized type definition te komen. Een realized type definition is een type definitie waar geen enkele referentie meer in zit. Om te beginnen worden afgeleide types aangepakt, bij een extension wordt de referentie naar het basistype vervangen door een sequence met de inhoud van het basistype. De inhoud van een restriction blijft gewoon behouden. Daarna worden alle referenties (naar zowel elementen als groepen) vervangen door de definitie waarnaar verwezen wordt. 21

28 Als laatste worden alle namen van zowel elementen als types geëxpandeerd tot de vorm ns:naam, waarbij ns staat voor de namespace en naam voor de naam van het element of type Opbouw van de FSA, Fase 2: Genereren van de syntaxboom De syntaxboom die hier wordt opgebouwd is een andere voorstelling van de type definitie uit het schema. Het opbouwen vertrekt vanuit het gerealiseerde type uit de eerste fase. De syntaxboom zal ook onmiddellijk onderhevig zijn aan een aantal vereenvoudigingen. Deze worden doorgevoerd, omdat ze voor een verbetering zorgen van de compressie efficiëntie. Definitie van de syntaxboom De syntaxboom bestaat uit verschillende soorten knopen, hierbij zullen de element en wildcard knopen de bladeren vormen van de boom. Element declaratie knopen associëren element namen met types. (notatie: element- Naam{elementType}) Wildcard knopen stellen wildcards op elementen voor. Group knopen stellen een groep voor, dus een sequence, een choice of een all. (notatie: sequence, choice, all) Ocurrence knopen worden afgeleid van elementen met een minoccurs of maxoccurs attribuut. (notatie: [minoccurs,maxoccurs]) Ter illustratie van de vereenvoudigingen die volgen, zijn enkele figuren aanwezig. Hierbij zal de notatie gehandhaafd worden die hierboven vermeld staat. Vereenvoudiging van groepen Elke groep die slechts één element, of een andere groep, bevat waarvan de minoccurs gelijk is aan één of nul, wordt vervangen door de inhoud van die groep. De waarden van minoccurs en maxoccurs worden uiteraard vermenigvuldigd met de waarden van bovenliggende occurrence knopen, zodat de correctheid bewaard blijft (zie figuur 3.2). 22

29 Figuur 3.2: Vereenvoudiging van groepen. Vereenvoudiging van een lege choice Wanneer een choice een element bevat waarvan de minoccurs gelijk is aan nul, dan wordt de minoccurs van dat element vervangen door één en de minoccurs van de choice wordt nul (zie figuur 3.3). Figuur 3.3: Vereenvoudiging van een lege choice. Choice vereenvoudiging Als een choice een andere choice bevat (met een occurrence gelijk aan één), dan worden de knopen uit de binnenste choice toegevoegd aan de buitenste choice en wordt de binnenste choice verwijderd (zie figuur 3.4) Opbouw van de FSA, Fase 3: Normalisatie van de syntaxboom De bedoeling van de derde fase is de toekenning van een unieke naam aan elke element declaratie knoop, groep knoop en wildcard knoop. Deze toekenning zorgt ervoor dat 23

30 Figuur 3.4: Vereenvoudiging van een choice. knopen op een eenduidige wijze kunnen geordend worden, dit is nodig omdat er moeten binaire codes moeten worden uitgedeeld die dan bij coderen en decoderen worden gebruikt. De unieke naam wordt de signatuur genoemd. De regels voor de benaming zijn vrij eenvoudig. We beginnen bij een element declaratie knoop, de signatuur van deze knoop is gelijk aan de geëxpandeerde benaming (zoals vermeld in sectie 3.3.2). De signatuur van een ocurrence knoop is gewoon gelijk aan de signatuur van zijn kind. Bij de groep knopen wordt de signatuur als volgt opgebouwd, :groep_naam kind kind kind..., hierbij is de groep_naam gelijk aan sequence, choice of all. Na de groepnaam worden alle signaturen van de kinderen opgesomd, gesplitst door middel van spaties. De signatuur van een wildcard knoop zal steeds beginnen met :wildcard, daarna volgt de waarde van het processcontents attribuut die opnieuw wordt voorafgegaan door een :. Nu volgt enkel nog de voorstelling van de inhoud van het namespace attribuut. Daarbij zullen not, any en absent opnieuw voorafgegaan worden door een :. Eerst komen de sleutelwoorden :any of :not, dan volgen alfabetisch gesorteerd de namespaces en, als het aanwezig is, het :absent sleutelwoord, gesplitst door middel van spaties Opbouw van de FSA, Fase 4: Finite state automaton generation De constructie van de automatons gebeurt op een recursieve manier, uitgaande van de syntaxboom. Elke knoop uit de boom zal een zogenaamde node automaton genereren. De automatons afkomstig van knopen die geen blad zijn in de syntaxboom worden gevormd door het samenvoegen van de automatons van hun kinderen, hoe dit gebeurt, is afhankelijk van het soort knoop. De node automaton van de wortel van de syntaxboom zal uiteindelijk 24

31 de automaat zijn van het complextype. Wanneer het content type van een complextype mixed is, dan moet de final state worden aangepast om de verwerking van de extra karakters tussen elementen mogelijk te maken. Dit gebeurt door een nieuwe final state aan te maken en een shunt transitie en een mixed transitie toe te voegen tussen de oude final state en de nieuwe. Element declaratie knoop automaat Wanneer het content type van de complextype niet mixed is, bestaat de node automaton uit twee toestanden en een transitie. De transitie zal een element transition zijn, die gebruikt wordt om een element naam en type te specificeren. De eintoestand van de automaat is een type state, die de verwerking van het element activeert en die werd doorgegeven door middel van de element transition (zie figuur 3.5). Figuur 3.5: Element declaratie knoop automaat (bij een complextype zonder mixed content type). Als het complextype een content type heeft die mixed is, dan zal er een toestand meer zijn dan bij het andere geval. De start toestand is nu verbonden met twee code transities aan een intermediaire toestand, een shunt transitie en een mixed transitie. De intermediaire toestand is dan verbonden via een element transitie aan de eind toestand die een type state is. De werking van deze automaat is gelijkaardig aan het vorige, enkel zal nu de mixed transitie genomen worden als het element wordt voorafgegaan door karakters, is dit niet zo, dan wordt de shunt transitie genomen (zie figuur 3.6). Wildcard knoop automaat De wildcard knoop automaat is zeer gelijkaardig aan de element knoop automaat. Er zijn opnieuw twee soorten automaten, afhankelijk of het complextype al dan niet een mixed content model heeft. In het geval waarin er geen sprake is van een mixed content model, zal de automaat bestaan uit twee toestanden en een transitie. Er is een start toestand en een eind toestand, die met elkaar verbonden zijn via een wildcard transitie. 25

32 Figuur 3.6: Element declaratie knoop automaat (bij een complextype met mixed content type). In het ander geval is er een extra intermediaire toestand die opnieuw met de eind toestand is verbonden door middel van een wildcard transitie. Tussen de start toestand en de intermediaire toestand zijn er twee transities, namelijk een mixed transitie en een shunt transitie. Choice knoop automaat Er wordt een nieuwe start en eind toestand aangemaakt en een code transitie voor elk kind van de choice knoop. Elk van deze code transities verbindt de start knoop met de start knoop van een kind, hierbij wordt de signatuur van de code transitie gelijk gesteld aan de signatuur van het overeenkomstige kind. Vanuit de eind toestand van de kinderen wordt tenslotte een simple transitie toegevoegd naar de eindtoestand van de choice knoop automaat (zie figuur 3.7). Figuur 3.7: Choice knoop automaat. 26

33 Sequence knoop automaat Een sequence knoop automaat is zeer eenvoudig, het is gewoon een opeenvolging van de knoop automaten van zijn kinderen. De start toestand van de automaat is de start toestand van het eerste kind en de eind toestand van de automaat is de eind toestand van het laatste element. Tussen de elementen onderling zit steeds een simple transitie die de eind toestand van het ene element verbindt met de start toestand van het volgende element (zie figuur 3.8)). Figuur 3.8: Sequence knoop automaat. All knoop automaat Bij een all knoop automaat wordt op een recursieve manier een boom van choices aangemaakt. Wanneer in een XML schema een all voorkomt, wil dat zeggen dat elk element van de all éénmaal (of zoveel keer zijn occurrence aangeeft) zal worden gekozen. De volgorde waarin wordt echter niet opgelegd. Voor het opbouwen van de automaat wordt eerst een nieuwe start en eind toestand aangemaakt. Vanuit die start toestand wordt dan voor elk kind een code transitie aangemaakt, die de start toestand zal verbinden met de automaat van de kind knoop. Dit vormt het eerste niveau van de boom. In de volgende stap maken we vanuit de eind toestanden van de kinderen opnieuw code transities aan, deze code transities worden verbonden met de begin toestanden van de automaten van de overige kinderen, enz. Dit gaat zo door tot geen kinderen meer over zijn. Dan worden alle eind toestanden van het laagste niveau verbonden, aan de hand van simple transitions, met de eind toestand van de all knoop automaat. In figuur 3.9 wordt geïllustreerd hoe een all knoop automaat eruit ziet, als de all knoop drie kinderen heeft. Hier worden de automaten van de kinderen voorgesteld door vierkantjes omdat de figuur anders nogal overdadig zou worden. 27

34 Figuur 3.9: All knoop automaat. Occurrence knoop automaat Deze automaat zal er anders uitzien, afhankelijk van de waarden van de minoccurs en maxoccurs attributen van de occurrence node. Er is één geval waarbij de automaat gewoon dat is van het kind van de knoop en dat is bij een minoccurs = 1 en een maxoccurs = 1. Het zal er in de rest van de gevallen op neerkomen om van de automaat van het kind te vertrekken en loop en code transisties toe te voegen. minoccurs = 0 en maxoccurs = 0 De automaat bestaat simpelweg uit een start toestand en een eind toestand met daartussen een simple transitie. minoccurs = 0 en maxoccurs = 1 De automaat wordt uitgebreid met een nieuwe start en eind toestand. Vanuit de start toestand vertrekken twee code transities, namelijk een shunt transitie, van de nieuwe start toestand naar de nieuwe eind toestand en een code transitie, die de nieuwe start toestand verbindt met de start toestand van de automaat van de kind knoop. maxoccurs > 1 Opnieuw wordt een nieuwe start toestand en eind toestand toegevoegd aan de automaat. Van deze nieuwe start toestand wordt een code transitie toegevoegd naar een 28

35 nieuwe toestand, een simple state. Tussen deze simple state en de start toestand van de automaat, van het kind van de occurence node, wordt dan een loop start transitie toegevoegd. Tenslotte worden nog twee transities toegevoegd, die beide vertrekken vanuit de eind toestand van de automaat van het kind, namelijk een loop end transitie, die wordt verbonden met de nieuwe eind toestand en een loop continue die wordt verbonden met de simple state tussen de nieuwe start toestand en de oude. Als de minoccurs = 0 wordt er ook nog een shunt transitie toegevoegd tussen de nieuwe start toestand en de nieuwe eind toestand (zie figuur 3.10). Figuur 3.10: Occurrence knoop automaat Opbouw van de FSA, Een uitgewerkt voorbeeld Om de opbouw van de automaten goed te kunnen illustreren, hebben we het schema uit figuur 2.6 aangepast, zodat meer aspecten van het proces toepasbaar zijn. Dit aangepaste schema is te zien in figuur In dit voorbeeld bouwen we een automaat op uit het complextype isbnboektype. Type inhoud realisatie Ons complextype isbnboektype is een extension van het type boek, we gaan dus de verwijzing naar het type boek vervangen door de inhoud van boek zelf. Dit levert de type definitie op uit figuur

36 <?xml version="1.0" encoding="utf-8"?> <xs:schema xmlns="boekns" xmlns:xs=" targetnamespace="boekns" elementformdefault="qualified"> <xs:element name="boek" type="isbnboektype" /> <xs:complextype name="boektype"> <xs:sequence> <xs:element name="titel" type="xs:string"/> <xs:element name="auteur" type="auteurtype"/> <xs:element name="uitgever" type="xs:string"/> <xs:element name="jaar" type="xs:int"/> </xs:sequence> </xs:complextype> <xs:complextype name="auteurtype"> <xs:choice> <xs:choice> <xs:element name="naamvoornaam" type="xs:string" /> <xs:element name="voornaamnaam" type="xs:string" /> </xs:choice> <xs:element name="pseudoniem" type="xs:string" /> </xs:choice> </xs:complextype> <xs:complextype name="isbnboektype"> <xs:complexcontent> <xs:extension base="boek"> <xs:sequence> <xs:element name="isbn" type="xs:string"/> </xs:sequence> </xs:extension> </xs:complexcontent> </xs:complextype> </xs:schema> Figuur 3.11: Dit is het schema die zal worden geanalyseerd als voorbeeld op de constructie van FSA s. 30

37 <xs:complextype name="isbnboektype"> <xs:sequence> <xs:element name="titel" type="xs:string"/> <xs:element name="auteur" type="auteurtype"/> <xs:element name="uitgever" type="xs:string"/> <xs:element name="jaar" type="xs:int"/> <xs:element name="isbn" type="xs:string"/> </xs:sequence> </xs:complextype> Figuur 3.12: De eerste stap in de type realisatie: het wegwerken van de extension. Om de volledige type definitie nu nog verder vrij te maken van referenties, moet ook auteur worden vervangen door zijn type definitie. Als dat is gebeurd, hoeven enkel nog de namen geëxpandeerd te worden, dit houdt dus in dat alle namen worden voorafgegaan door boekns:. Na deze twee stappen krijgen we de gerealiseerde type definitie, die te zien is in figuur <xs:complextype name="boekns:isbnboektype"> <xs:sequence> <xs:element name="boekns:titel" type="xs:string"/> <xs:element name="boekns:auteur"> <xs:complextype> <xs:choice> <xs:choice> <xs:element name="boekns:naamvoornaam" type="xs:string" /> <xs:element name="boekns:voornaamnaam" type="xs:string" /> </xs:choice> <xs:element name="boekns:pseudoniem" type="xs:string" /> </xs:choice> </xs:complextype> </xs:element> <xs:element name="boekns:uitgever" type="xs:string"/> <xs:element name="boekns:jaar" type="xs:int"/> <xs:element name="boekns:isbn" type="xs:string"/> </xs:sequence> </xs:complextype> Figuur 3.13: De gerealiseerde type definitie. 31

38 Genereren van de syntaxboom Nu we over de gerealiseerde type definitie beschikken wordt de syntaxboom gegenereerd. Aangezien de occurrence van alle nodes gelijk is aan 1, laten we voor de overzichtelijkheid de occurrence nodes weg. Wanneer we vanuit de type definitie onmiddellijk de syntaxboom opbouwen, krijgen we de boom uit figuur Figuur 3.14: De syntaxboom zonder vereenvoudigingen. Aangezien er geen enkele node een minoccurs heeft van 0, is het niet mogelijk om hierop de regel van de lege choice uit te voeren. Wat wel van toepassing is, is de vereenvoudiging voor de choice die als kind een choice heeft. Doordat we hier steeds met occurrences van één werken, moeten geen occurrences worden vermenigvuldigd, aangezien deze vermenigvuldiging toch weer één uitkomt. Wanneer er echter occurrence nodes in de syntaxboom zouden zitten met als minoccurs en/of maxoccurs andere waarden dan één, is dit natuurlijk wel nodig. Na het uitvoeren van deze vereenvoudiging bekomen we de syntaxboom uit figuur Figuur 3.15: De syntaxboom met vereenvoudigingen. Genereren van de eindige toestandsautomaat Voor de opbouw van de automaat beginnen we bij de bladeren van de syntaxboom, dit zijn allemaal element knopen. Het is ook mogelijk dat hier wildcard knopen tussen zitten, maar 32

39 in ons voorbeeld is dit niet van toepassing. In figuur 3.16 is de eindige toestandsautomaat te zien die het resultaat is van het blad xs:string{boekns:titel}. Voor elk van de bladeren zal zo n automaat (die bestaat uit een element transition en een type state) worden gegenereerd. Om de figuur niet overdadig te maken, is hier enkel de automaat voor het element boekns:titel geïllustreerd. Figuur 3.16: De eindige toestandsautomaat voor de elementknoop xs:string{boekns:titel} De verdere verwerking van de syntaxboom naar een eindige toestandsautomaat zal nu niveau per niveau gebeuren. We zijn gestart bij de bladeren en nu pakken we de choice knoop aan. Voor deze choice wordt een nieuwe start toestand en een nieuwe eind toestand aangemaakt. Vertrekkende vanuit deze nieuwe start toestand maken we drie code transities aan, die elk de verbinding leggen naar één van de start toestanden van de kinderen van de choice, nl. xs:string{boekns:voornaamnaam}, xs:string{boekns:naamvoornaam} en xs:string{boekns:pseudoniem}. Uit de eind toestanden van de kind automaten laten we simple transitions vertrekken, die aankomen in de nieuwe eind toestand van de choice automaat. Het resultaat is te zien in figuur Figuur 3.17: De eindige toestandsautomaat voor de choiceknoop. Op het volgende niveau vinden we de bladeren waarvoor we al automaten hebben aangemaakt en de knoop boekns:auteur. Zoals altijd maken we hier opnieuw een nieuwe start en eind toestand aan. De oude eind toestand wordt aan de hand van een simple transition met de nieuwe verbonden en tussen de nieuwe begin toestand en de oude komt 33

40 een element transition, die aangeeft dat de verwerking van het element boekns:auteur begint. De bekomen automaat wordt afgebeeld in figuur Figuur 3.18: De eindige toestandsautomaat voor boekns:auteur. Het enige dat ons nu nog rest, is het samenvoegen van het geheel tot een sequence automaat. Hiervoor wordt een nieuwe start en eind toestand toegevoegd met daartussenin alle toestandsautomaten van de kind knopen, waarbij elke eind toestand met de volgende start toestand wordt verbonden door middel van simple transitions. 34

41 Figuur 3.19: De eindige toestandsautomaat voor het complextype boekns:isbnboektype. 35