Gebruik en aanmaak van XML Schema voor validatie van externe data

DEPARTEMENT INDUSTRIELE WETENSCHAPPEN EN TECHNOLOGIE Associatie

K. U. L e u v e n

Basisopleiding van 2 cycli

Academiejaar : 2004 - 2005 Opleiding :

ELEKTRONICA

Optie :

INFORMATIE- EN COMMUNICATIETECHNIEKEN

Eindwerk

Gebruik en aanmaak van XML Schema voor validatie van externe data

door

Koen Annys

onder leiding van Dr.Sc. J. Calu, KHBO Ing. P. Clarysse, TELE ATLAS DATA GENT NV

Eindwerk aangeboden tot het behalen van het diploma

INDUSTRIEEL INGENIEUR IN ELEKTRONICA Katholieke Hogeschool Brugge - Oostende Zeedijk 101 , 8400 Oostende tel +32 59 56 90 00 - fax +32 59 56 90 01

MEDEDELING “Deze eindverhandeling was een examen; de tijdens de verdediging vastgestelde fouten werden niet gecorrigeerd. Gebruik als referentie in publicaties is toegelaten na gunstig advies van de KHBO-promotor, vermeld op het titelblad.”

WOORD VOORAF Bij de aanvang van deze eindverhandeling wil ik mijn dank betuigen aan alle mensen die bijgedragen hebben tot de realisatie van dit werk. Vooreerst mijn oprechte dank aan TELE ATLAS DATA GENT NV die mijn stage mogelijk maakte. In het bijzonder aan mijn buitenpromotor, Ing. Pascal Clarysse en aan Ing. Christel Fiers die beiden voor een uitstekende begeleiding hebben gezorgd. Eveneens verdient mijn binnenpromotor Dr. Johan Calu een woord van dank voor de geleverde begeleiding. Tenslotte wil ik nog mijn naaste familieleden danken voor hun vele steun. Ik hoop dat mijn eindwerk u boeit en wens u veel leesplezier! Annys Koen

4

SAMENVATTING Tele Atlas is een bedrijf dat digitaal kaartmateriaal aanmaakt voor uiteenlopende navigatieproducten en databankoplossingen. Om de grote hoeveelheid data die daarbij te pas komt te verwerken, heeft de firma een eigen formaat ontwikkeld: het Tele Atlas Intern Formaat of TIF. De data om die kaarten aan te maken wordt enerzijds aangemaakt door Tele Atlas zelf, anderzijds wordt er ook externe data aangekocht bij plaatselijke bedrijven. Vanzelfsprekend zal die externe data nooit in TIF-formaat geleverd worden, hierdoor moet er data- en formaatconversie toegepast worden. Dit wordt gedaan met behulp van UNITRAN, een programma dat ook door Tele Atlas ontwikkeld werd. Er is voor XML gekozen als tussenformaat om formaatafhankelijke ontwikkeling te vermijden. Er wordt altijd eerst een proefbestand geleverd en dan pas het volledige bestand. Het configuratiebestand, een bestand dat nodig is om het XML-bestand om te zetten naar TIF-formaat, wordt aangemaakt op basis van dit proefbestand. Als het configuratiebestand niet geldig is voor het volledige bestand is er een probleem. Om dit probleem te vermijden is er gekozen om controles uit te voeren op het volledige data- en configuratiebestand. Deze controles worden uitgevoerd met behulp van een XML Schema-bestand, dat aangemaakt wordt aan de hand van het proefbestand. Het XML Schema-bestand is een beschrijving van het databestand. Het programma dat instaat voor de aanmaak van het XML Schema-document en de controles, wordt in deze eindverhandeling besproken.

5

INHOUDSOPGAVE WOORD VOORAF SAMENVATTING................................................................................................................................................ 4 INHOUDSOPGAVE............................................................................................................................................. 5 INLEIDING........................................................................................................................................................... 7 1

Tele Atlas .................................................................................................................................................... 8 1.1 1.2

2

VOORSTELLING TELE ATLAS .............................................................................................................. 8 PROBLEEMSTELLING ........................................................................................................................... 9

XML ............................................................................................................................................................ 13 2.1 2.2 2.3 2.4 2.5 2.6

3

WORLD WIDE WEB CONSORTIUM .................................................................................................... 14 XML SCHEMA .................................................................................................................................... 15 XML-PARSER .................................................................................................................................... 16 XML-PROCESSOR ............................................................................................................................. 17 WELGEVORMDE XML-DOCUMENTEN ................................................................................................ 18 GELDIGE XML-DOCUMENTEN ........................................................................................................... 18

SAX............................................................................................................................................................. 19 3.1 3.2

GEHEUGENGEBRUIK BIJ SAX EN DOM............................................................................................ 20 EEN BEKNOPTE GESCHIEDENIS VAN SAX ........................................................................................ 20

4

Java API for XML Processing (JAXP) van Sun ............................................................................... 21

5

Xerces-J parser ....................................................................................................................................... 22 5.1 5.2 5.3 5.4 5.5

6

ONDERSTEUNING ............................................................................................................................... 22 BEPERKINGEN VAN XERCES ............................................................................................................. 22 OVERZICHT KENMERKEN VAN XERCES ............................................................................................. 23 OVERZICHT EIGENSCHAPPEN VAN XERCES ...................................................................................... 25 IDEALE BUFFERCAPACITEIT VAN DE PARSER .................................................................................... 26

Het ontwikkelde programma: External Data Investigator ............................................................ 27 6.1 AANMAAK VAN EEN XML SCHEMA-BESTAND .................................................................................. 27 6.1.1 Parsen van het document ...................................................................................................... 27 6.1.2 Verwerking van de informatie ............................................................................................... 42 6.1.2.1 6.1.2.2

6.1.3 6.1.4

Objecten............................................................................................................................................ 43 Aanmaak van een standaard type en filter............................................................................... 47

Opbouw van een weergave.................................................................................................... 48 Uitschrijven van het XML Schema-bestand....................................................................... 49

6.1.4.1

Opbouw van een XML Schema-bestand................................................................................... 49

6.2 VALIDATIE VAN HET XML-BESTAND ................................................................................................. 59 6.2.1 Overzicht van foutmeldingen ................................................................................................ 60 6.3 VALIDATIE VAN HET CONFIGURATIEBESTAND ................................................................................... 68 6.3.1 Het configuratiebestand ......................................................................................................... 68 6.3.2 Parsen van het configuratiebestand ................................................................................... 71 6.3.3 Het CaseElement object ......................................................................................................... 76 6.3.4 De controles............................................................................................................................... 76 BESLUIT ............................................................................................................................................................. 79 BIJLAGEN ......................................................................................................................................................... 80 LITERATUURLIJST ........................................................................................................................................ 96

6

ALFABETISCHE LIJST VAN GEBRUIKTE SYMBOLEN EN AFKORTINGEN DOM: Document Object Model DTD: Document Type Definition EDI: External Data Investigator I/O: input output JAXP: Java API for XML processing SAX: Simple API for XML SGML: Generalized Markup Language TIF: Tele Atlas Internal Format HTML: Hypertext Markup Language UNITRAN: Universal Translator URL: Uniform Resource Locator URI: Uniform Resource Indicator XML: Extensible Markup Language

7

INLEIDING XML is een algemeen aanvaard formaat om gegevens op te slaan en wordt in vele toepassingen gebruikt. Een voordeel van het gebruik van XML om data te bewaren is dat de inhoud gecontroleerd kan worden aan de hand van een DTD of een XML Schema-document. XML Schema geniet de voorkeur omdat het veel krachtiger is. Om die controle uit te voeren moet er natuurlijk eerst een XML Schema-bestand opgesteld worden. Dit zou kunnen gebeuren via een XML-editor zoals XMLSpy. Het gebruik van een zuivere XML-editor impliceert volledige kennis van het bestand waarvan u het XML Schema-bestand wil opstellen. U moet ook weten hoe een XML Schema-bestand aangemaakt wordt. Een bijkomende factor is de tijd die in beslag genomen wordt om het document op te stellen. Indien het gaat om eenvoudige documenten die niet al te groot zijn kan de tijdsduur nog meevallen. Betreft het integendeel grote documenten, dan kan er veel tijd in beslag genomen worden. Een programma dat het XML Schema-bestand voor u opstelt kan de oplossing bieden. In opdracht van Tele Atlas Data Gent NV heb ik een dergelijk programma ontwikkeld: External Data Investigator of kortweg EDI. Het omvat de aanmaak van een XML Schema-bestand en twee opties om controles uit te voeren. Indien u geïnteresseerd bent in hoe dit programma aangemaakt wordt en meer wil weten over de controles die uitgevoerd kunnen worden, moet u beslist verder lezen.

8

1 Tele Atlas 1.1

Voorstelling Tele Atlas

Tele Atlas is marktleider in de realisatie van digitale kaarten voor uiteenlopende navigatieproducten en databankoplossingen. Hun databank bevat de meest nauwkeurige data van bestaande straatnetwerken. Dit maakt stapsgewijze routebegeleiding mogelijk voor bijna alle Europese en Noord-Amerikaanse wegen. Ook Singapore, Hong Kong en grote delen van Australië bevinden zich in de databank. Dankzij de compatibiliteit met alle grote navigatiesystemen en een ‘open systeem’ ontwerp wordt Tele Atlas over de hele wereld teruggevonden bij zowel consumenten als bij business to business toepassingen. Siemens VDO, Daimler Chrysler, BMW, Blaupunkt, ESRI, Microsoft, Michelin, TomTom en Ericsson zijn slechts een aantal van de vele bedrijven die op de databanken van Tele Atlas vertrouwen. We kunnen dus besluiten dat de digitale kaarten van Tele Atlas miljoenen mensen de weg wijzen. Tele Atlas vond in 1985 het eerste voertuignavigatiesysteem uit. In het begin van de jaren 80, toen de compactdisc nog maar net was uitgevonden en het digitale tijdperk nog maar een gerucht was, besefte een kleine pioniersgroep dat digitale kaarten een fundamentele impact zouden hebben op de manier waarop mensen reizen en zaken doen. Een twintigtal jaren later worden mensen over de hele wereld begeleid naar de bestemming van hun keuze met behulp van Tele Atlas navigatieproducten voor GPSautonavigatiesystemen, handheld personal digital assistants, derde generatie mobiele telefoons enzovoort. Zowel de zakenwereld als de privé-gebruikers vertrouwen op de nauwkeurigheid, rijkheid en efficiëntie van de Tele Atlas databanken. Enkele van de mijlpalen uit de geschiedenis van Tele Atlas worden hieronder beschreven. 1984 Oprichting Tele Atlas Nederland. 1988 Oprichting Tele Atlas België. 1994 Oprichting Tele Atlas Italië & Frankrijk. 1995 Oprichting Tele Atlas BV: Joint Venture van Janivo en Bosch. 1995 Oprichting Tele Atlas Duitsland, Oostenrijk, Zwitserland en Scandinavië. 1998 Oprichting Tele Atlas Japan, Spanje, Portugal en India. 2000 Overname van het digitale kaartenbedrijf ETAK uit de US, een divisie van Sony Corporation. Oprichting van Tele Atlas Noord-Amerika & UK. 2000 Tele Atlas gaat naar de beurs: IPO op 26 mei 2000. Er werden fondsen bijeengezocht om de ontwikkeling van de Noord-Amerikaanse gegevensbank te financieren. 2001 Overname van Phonetic Topographics, het eerste bedrijf dat spraaktechnologie combineert met geografische-, redactionele- en andere databanken. 2001 Kantoren die gegevens verzamelen worden geopend in de US. 2002 Tele Atlas tekent contracten met Siemens VDO Automotive en Harman International Industries (US), beter bekend onder de merknaam Becker. Tele Atlas levert navigatie cd's voor bijna alle grote navigatieplatformen. 2002 Gegevens van Canada worden beschikbaar door een alliantie met DMTI Spatial Inc 2002 Hutchinson 3G gebruikt de Tele Atlas kaarten voor zijn 3G telefoondienst in UK en Italië. 2003 (januari) Lancering van Tele Atlas MultiNetTM Noord-Amerika, de meest krachtige Turnby-Turn kaartendatabank ooit gebouwd voor Noord-Amerika. Inclusief de locatiecodes van het verkeer (die gevoed worden met real-time verkeersinformatie via de exclusieve samenwerking met Westwood One/Metro Networks).

9

Tele Atlas MultiNet is wellicht een van de belangrijkste prestaties van Tele Atlas. Het is een hoogstaande vector database die zeer gedetailleerd een uitgebreid stratennetwerk beschrijft. De gegevens tonen een zeer accuraat beeld van grote verkeerswisselaars tot en met de kleinste straten, zelfs tot op het niveau van huisnummers. De gegevens zijn beschikbaar voor de meeste Europese landen en kunnen worden gebruikt voor verschillende toepassingen.

MultiNet bevat de volgende gegevens: • • • • • • • • • •

1.2

wegen: acht wegenklassen, centrumlijnen, verkeersattributen, wegnummers, straatnamen en huisnummers; spoorwegen; adresgebieden; administratieve gebieden; postcodegebieden; bebouwde gebieden; bewoonde gebieden; water; landgebruikklassen: parken, bossen, vennen, industriële zones; interessepunten: benzinestations, hotels/motels, restaurants, parkings, stations, vliegvelden, autoverdelers per merk, huurautoverdelers, winkelcentra, stadions, ziekenhuizen, overheidsgebouwen, enzovoort.

Probleemstelling

In Tele Atlas wordt veel digitaal kaartmateriaal aangekocht om hun databank te verbeteren. Dit kaartmateriaal wordt geleverd in verschillende formaten: • ArcView shp; • ArcInfo Coverage; • MapInfo Interchange format; • Text; • MsAcces. Het Tele Atlas Intern Formaat of kortweg TIF is het formaat waarmee Tele Atlas werkt. Het formaat omvat alle geografische informatie zoals straten, waterwegen, gemeentegrenzen maar ook optionele informatie zoals de ligging van benzinestations. Het vormt de basis om tot een eindproduct te komen. Vanzelfsprekend zal dit materiaal nooit in het formaat geleverd worden dat Tele Atlas zelf gebruikt. Hierdoor moet er een formaatconversie en zonodig een dataconversie gedaan worden. Er is gekozen om XML als tussenformaat te gebruiken om formaatafhankelijke ontwikkeling te vermijden. De keuze viel op XML juist omdat iedere kaart uit velden en waarden bestaat. Het XML-bestand wordt omgezet naar het TIF-formaat met behulp van een configuratiebestand. De problemen die Tele Atlas tot nu toe ondervindt, is dat het configuratiebestand opgesteld wordt aan de hand van een proefdatabestand. Er wordt namelijk eerst een gedeelte van het kaartmateriaal geleverd en later pas het volledige kaartmateriaal. Zo is het mogelijk dat er velden en /of waarden niet correct vertaald worden.

10

Om dit probleem op te lossen zal er gebruik gemaakt worden van XML Schema. Van het proefdatabestand wordt er een XML Schema-bestand opgesteld die gebruikt zal worden om het volledige kaartmateriaal en het configuratiebestand te valideren. Overzicht: 1. Zonder gebruik van XML Schema

Figuur 1: verwerking extern proefbestand (zonder toekomstige controles).

Het proefdatabestand wordt geanalyseerd om zo een stel regels te verkrijgen die een correcte formaatovergang moeten garanderen. Aan de hand van de opgestelde translatietabel wordt er een configuratiebestand in XML-formaat opgesteld.

Figuur 2: aanmaak TIF formaat.

Eenmaal het volledige kaartmateriaal ter beschikking is, wordt het omgezet naar het TIFformaat. Dit gebeurt door UNITRAN, een programma door Tele Atlas ontwikkeld om formaatconversie en dataconversie uit te voeren. UNITRAN staat voor universele vertaler. Indien het configuratiebestand of het databestand een fout bevat, zal dit leiden tot een foute conversie. Zo kan het bijvoorbeeld zijn dat de verkeerde waarden opgevraagd worden of dat de opgevraagde waarden niet bestaan. Het is duidelijk dat een fout niet altijd onmiddellijk wordt opgemerkt.

11 2. Met gebruik van XML Schema

Figuur 3: verwerking extern proefbestand (met toekomstige controles).

Naast het configuratiebestand wordt er nu een XML-bestand van de proefdata gemaakt. Dit bestand zal gebruikt worden om een XML Schema-bestand op te stellen. Aan de hand van het opgestelde XML Schema-bestand kunnen er controles uitgevoerd worden (zie figuur 4 en 5).

Figuur 4: controle op het XML-configuratiebestand.

Figuur 5: controle op het XML-databestand.

Bemerk dat er een dubbele controle wordt uitgevoerd bij het configuratiebestand en een enkele bij het databestand. Deze controles moeten voorkomen dat er een foute conversie gebeurt. Eenmaal de controles uitgevoerd zijn, kan er opnieuw een conversie naar het TIFformaat uitgevoerd worden (zie figuur 2).

12

Conclusie: Het programma dat deze controles mogelijk moet maken, moet in staat zijn om de volgende drie punten te behandelen. 1. Aan de hand van een XML-proefbestand een XML Schema-bestand aanmaken, dat van toepassing is voor het overeenkomend volledig XML-datadocument. 2. Het datadocument valideren tegen het gegenereerde XML Schema-bestand. 3. Controles uitvoeren op een configuratiebestand met behulp van hetzelfde XML Schema-bestand.

13

2 XML XML of Extensible Markup Language wordt in de XML 1.0 W3C recommandatie beschreven als een subset van SGML (Generalized Markup Language). De reden voor de ontwikkeling was dat HTML beperkte mogelijkheden bezit. SGML is nooit goed doorgebroken omdat het te ingewikkeld en te uitgebreid was. Vanaf december 1998 werd ‘Voyager’ de codenaam van het W3C voor HTML die als een XML-toepassing geformuleerd werd. XML is een universeel formaat voor gestructureerde documenten en data. Het is volledig geïnternationaliseerd voor alle Europese en Aziatische talen met de nodige conforme processors om het Unicode karakterset zowel in UTF-8 als in UTF-16 codering te ondersteunen. Hoewel de ‘M’ in XML voor ‘Markup’ staat is XML in feite een meta-markuptaal. Een taal om een beschrijving van een beschrijving te maken. De basiselementen van XML zijn: • elementen; • attributen; • entiteiten; • DTD’s. Een element is iets dat een stukje gegevens beschrijft. Een element bestaat uit markup-tags en de inhoud van het element. Elementen hebben zowel een start- als een eindtag (behalve lege elementen). Ieder XML-document heeft een hoofdelement dat alle gegevens voor het hele document bevat. Een attribuut kan een eigenschap van een element bepalen of het kan nog meer specifieke informatie bieden over het element. Entiteiten zijn virtuele opslageenheden in een XML-document. In een entiteit slaat u allerlei soorten informatie op. Dat gaat van een afbeeldingbestand tot een stukje tekst dat u vaak gebruikt of XML-markup. XML ondersteunt twee soorten entiteiten: algemene entiteiten en parameters. Een entiteit is gewoon een willekeurig stuk gegevens, ongeacht of dat tekstgegevens of binaire gegevens zijn, die u als referentie in een document wilt gebruiken. Geparste entiteiten (dat zijn verzamelingen van tekst en markup) worden verwerkt door de XML-processor als onderdeel van het document. Een voorbeeld van een geparste entiteit is ‘<’ dat het ‘<’ teken voorstelt. Entiteiten die binaire gegevens of een afbeeldingbestand bevatten worden ongeparste entiteiten genoemd. Parameter entiteiten bevatten specificaties van parameters die bij het verwerken en presenteren van bestanden gebruikt moeten worden (bijvoorbeeld de sets speciale symbolen). Deze entiteiten zijn herkenbaar doordat ze tussen ‘%’ en ‘;’ staan. Een DTD of een Document Type Definition is een aparte eenheid van het XMLhoofddocument, waarin een set regels aangeboden wordt voor het XML-document waaraan de DTD gekoppeld is.

14

2.1

World Wide Web Consortium

Het World Wide Web Consortium (W3C) kan het best omschreven worden als de regering van het web. Deze organisatie stelt de standaarden op voor de talen die gebruikt worden om informatie aan webgebruikers te leveren. Het W3C was verantwoordelijk voor het formuleren van HTML en doet hetzelfde met XML. Doordat er een enkel regerend orgaan is dat besluit hoe de taal zich moet ontwikkelen, wordt er een standaard gecreëerd waarnaar softwareontwikkelaars zich kunnen richten. Veel bedrijven en personen hebben bijgedragen aan de creatie van de XML-specificatie. Een korte lijst van deze personen en bedrijven bevat: Jon Bosak van Sun, Tim Bray van Textuality en Netscape, Jean Paoli van Microsoft, Dave Hollander van Hewlet-Packard, Eve Maler van ArborText en Joel Nava van Adobe. Al deze mensen en bedrijven hebben ideeën en informatie geboden en de programmaondersteuning geschreven die nu bekend staat als de XML-specificatie versie 1.0. Deze specificatie is een relatief klein document (ongeveer vijftig pagina’s) waarin de schrijfregels van XML staan. De XML-specificatie is het belangrijkste document dat u moet bestuderen als u XML van binnen en van buiten wilt leren kennen. Het is de officiële definitie van hoe XML werkt en hoe u XML gebruikt om DTD’s, elementen, attributen en entiteiten te ontwerpen. Eind 1998 richtte men vijf werkgroepen op die zich bezighouden met XML. Deze zijn: 1. de XML Schema werkgroep; 2. de XML Fragment werkgroep; 3. de XML Linking werkgroep; 4. de XML Information Set werkgroep; 5. de XML Syntax werkgroep. Deze werkgroepen werken nauw samen met de Extensible Stylesheet werkgroep en de Document Object Model werkgroep.

15

2.2

XML Schema

XML Schema is een taal om een XML-bestand te beschrijven met een objectgebaseerde aanpak. Deze schema’s kunnen gebruikt worden voor documentatie, validatie of verwerking. XML Schema laat u net als bij een DTD toe om een set regels toe te passen op een XMLdocument maar kan dat veel specifieker. De elementen die gebruikt worden om een beschrijving aan te maken behoren tot de W3C XML Schema namespace (http://www.w3.org/2001/XMLSchema) en bevat ‘xs’ als prefix. Belangrijk om te weten is wat inhoudmodellen zijn. Een inhoudmodel beschrijft de soort inhoud die elementen kunnen hebben. Er wordt geen rekening gehouden met eventuele attributen.

Er kunnen vier soorten inhoudmodellen aangenomen worden: 1. 2. 3. 4.

‘empty’, wanneer het element geen kindelementen of tekst kan bevatten; ‘simple’, als er enkel tekst aanwezig kan zijn; ‘complex’, als er enkel kindelementen aanwezig kunnen zijn; ‘mixed’, als er kindelementen en tekst als inhoud aangenomen kunnen worden.

Elementen die ‘simple’ als inhoudmodel hebben en geen attributen bezitten, worden beschouwd als een ‘simple type’, alle andere als ‘complex type’. Attributen zijn altijd een ‘simple type’ omdat ze enkel tekst kunnen bevatten, ‘simple types’ beschrijven inhoud terwijl ‘complex types’ zich eveneens op de structuur richten. Bij het beschrijven van het type kan er gebruik gemaakt worden van facetten, bijvoorbeeld minOccur, maxLength, minInclusive. De inhoudmodellen die van toepassing zijn op onze XML-bestanden zijn het ‘complex’ en ‘simple’ inhoudmodel. Een uitgebreide uitleg van XML Schema wordt hier niet gegeven, wel enkele belangrijke begrippen. Voor meer uitleg wordt er verwezen naar de XML Schema primers van het W3C. Er zijn drie delen beschikbaar: ‘XML Schema: Primer’, ‘XML Schema: Structures’ en ‘XML Schema: Datatypes’.

16

2.3

XML-parser

Nadat u een XML-bestand gemaakt hebt, is de volgende stap het controleren van het bestand om na te gaan of u de juiste XML-grammatica gebruikt heeft. Dat gebeurt door een softwareprogramma, parser genaamd. Dat programma zoekt uit wat de verschillende delen van het bestand betekenen en gaat na of de juiste grammatica gebruikt werd. Op het eenvoudigste niveau reproduceren de parsers de boomstructuur van het XML-document, zodat de processor of een andere toepassing iets met de inhoud kan doen. Voordat u iets met de inhoud van het XML-bestand kan doen, moet het document en het XML Schema-bestand door een parser gaan. De parser leest de elementtags evenals alle andere documentonderdelen. Hij controleert alles zodat de grammaticale structuur van het document overeenkomt met de standaard in de XML-specificatie. Indien er problemen zijn met de grammatica, zal de processor fouten rapporteren. Parsers zijn kleine programma’s die de grammatica en de welgevormdheid van het XMLbestand controleren en mogelijks de geldigheid van het document. Parsers nemen de vorm aan van een soort codebibliotheek, vaak geschreven in C++, Java of een andere taal. De codebibliotheek bevat alle benodigde programmering om geldige en welgevormde documenten te parsen.

We onderscheiden twee soorten parsers. • •

Niet-validerende parsers. Dit zijn softwareprogramma’s die de XML-documenten controleren op welgevormdheid, maar niet op geldigheid. Dit type parser negeert informatie die geboden wordt door een externe DTD of XML Schema-bestand. Validerende parsers. Hier worden de XML-documenten gecontroleerd op geldigheid, wat betekent dat ze nakijken of de DTD of het XML Schema-bestand bij het document zit en of het document eraan voldoet. Als het niet voldoet, wordt het document als niet geldig beschouwd.

17

2.4

XML-processor

Nadat het XML-document geparst is, neemt een XML-processor het over. Hij leest het document en biedt andere toepassingen toegang tot de XML-onderdelen die zich in het XMLdocument bevinden. Als een processor de geparste informatie onderschept, kan de softwareprogrammeur snel de structuur van een XML-document zien en met de onderdelen werken. Alle elementen, attributen, entiteiten en notaties worden dan als objecten gezien, die verder gemanipuleerd kunnen worden. Bij de meeste XML-processors en XML-parsers overlapt de rol van de processor de rol van de parser. De parser is verantwoordelijk voor het controleren van de syntaxis, de processor voor het bieden van toegang tot de inhoud en de structuur van het document. Application Programming Interfaces (API’s, programmeerinterfaces voor toepassingen) zijn hulpmiddelen die werken met XML-processors. Er zijn twee basistypen van processors: boomgebaseerde en gebeurtenisgebaseerde. 1. Een boomgebaseerde processor De processor parst het document om een hiërarchische boomstructuur in het geheugen aan te maken. Deze processor kan ook een DTD of een XML Schema-bestand aanvaarden om het document te valideren. Applicatielogica heeft toegang tot de datastructuur door middel van een ‘Application Programming Interface’ (API). Het Document Object Model (DOM) is een W3C recommandatie dat de karakteristieken van de boomstructuur van het document definieert en de API om het te manipuleren. Boomgebaseerde processors zijn erg effectief voor applicaties die willekeurige toegang tot een document nodig hebben. De applicatie kan de API gebruiken om te navigeren naar het gewenste stuk data. Een nadeel is dat er een redelijk groot aantal geheugen nodig is. 2. Een gebeurtenisgebaseerde processor In de plaats van een datastructuur te creëren en de applicatielogica te gebruiken om er toegang tot te krijgen, zenden gebeurtenisgebaseerde processors gebeurtenisbeschrijvingen naar de applicatielogica. Deze gebeurtenissen bevatten het begin en het einde van elk element maar niet de attributen en de inhoud. Als de applicatielogica geïnteresseerd is in deze informatie moet die om extra informatie vragen. Als de applicatielogica een gebeurtenis ontvangt die het begin van een element aanduidt, moet die extra informatie aanvragen om de inhoud te verkrijgen. Deze aanpak is interessant voor applicaties die elk element sequentieel benaderen of die maar een gedeelte van de elementen nodig hebben.

18

2.5

Welgevormde XML-documenten

Wanneer een document correct gelezen moet worden door een XML-processor, moet het document welgevormd zijn. Dat betekent dat het document en de markup-code conform de regels van de XML-syntaxis zijn. Een welgevormd XML-document heeft geen DTD of XML Schema-bestand nodig om een correct XML-bestand te zijn. Maar dat is niet alles, er zijn regels die bepalen of een document welgevormd is. • • • • • • • •

Het document moet omgeven zijn door één enkel basiselement of documentelement. Geen enkel attribuut mag meer dan één keer verschijnen in dezelfde starttag. Elementen moeten op de juiste manier genest zijn en moeten overeenstemmende starten eindtags hebben (tenzij het een leeg element betreft). Parameterentiteiten moeten gedeclareerd worden voordat ze gebruikt kunnen worden. Alle entiteiten moeten gedeclareerd worden, behalve die entiteiten die van te voren door XML gedeclareerd zijn. Het is alleen mogelijk ongeparste entiteiten te gebruiken als u ze als ENTITY of ENTITIES gedeclareerd hebt. Er kan niet naar verwezen worden in de inhoud. Alle entititeiten, elementen en attributen zijn gevoelig voor hoofdletters en kleine letters. Er moet dus op de juiste manier naar verwezen worden. Waarden van stringattributen mogen geen verwijzingen naar externe bronnen bevatten. Gebruik altijd ‘<’ om letterlijk het teken ‘<’te gebruiken, ‘&’ voor ‘&’, ‘"’ voor een letterlijk aanhalingsteken in een waarde van een attribuut of element en ‘'’ voor een letterlijke apostrof binnen de waarde van een attribuut of een element.

Indien uw document niet voldoet aan deze conventies, dan is het niet welgevormd. Het wordt dan niet als XML-document beschouwd. Indien u een van deze regels overtreedt, geeft de processor een fatale fout aan. De XML-processor zal de fout aan de XML-toepassing doorgeven en stoppen met de verwerking van het document.

2.6

Geldige XML-documenten

Een geldig XML-document is een welgevormd document dat ook overeenstemt met de specificaties van een DTD of een XML Schema-bestand. Een geldig document heeft volgende eigenschappen: • • •

geldige documenten volgen de regels van de XML-specificatie (regels van welgevormdheid); het document heeft een bijbehorende DTD-bestand of XML Schema-bestand; het document komt overeen met de regels van de bijbehorende DTD of XML Schemabestand.

Alle geldige XML-documenten zijn welgevormd maar niet alle welgevormde documenten zijn geldig.

19

3 SAX De Simple API voor XML (SAX) is een algemeen gebruikte gebeurtenisgebaseerde API voor XML-processors. Het is een parser-API met unieke eigenschappen in de zin dat SAX alle keuzes op het gebied van de gegevensstructuur overlaat aan de hogere niveaus. SAX is geen officiële standaard maar het is wel een defacto standaard, een standaard door het vele gebruik ervan. SAX-parsers kennen een aantal belangrijke voordelen: • • • •

SAX-parsers kunnen compact en snel zijn omdat ze beperkt zijn. SAX levert de belangrijkste XML-gegevens en verder niets; omdat SAX een streaming-API is, wordt vaak pipelineverwerking toegepast, waarbij de I/O plaatsvindt terwijl u de processor voor ander werk gebruikt; SAX biedt de nodige flexibiliteit bij het omgaan met fouten. Er kunnen ook andere fouten dan fatale fouten worden gerapporteerd, diagnostische gegevens zijn eenvoudig toegankelijk; het is eenvoudig eigen SAX-gebeurtenisproducers te definiëren. Dat betekent, u kunt SAX gebruiken wanneer de invoer geen letterlijke XML-tekst is. Dit is een techniek die veel mogelijkheden biedt en die u in staat stelt met gegevens te werken op het niveau van verwerkte XML-informatie (de XML-Infoset). Zo kan je SAXgebeurtenissen achteraf naar XML-tekst omzetten.

Een SAX-API is natuurlijk ook niet perfect, het belangrijkste probleem bij SAX is waarschijnlijk dat het zelf geen willekeurige toegang tot XML-gegevens biedt. De gebeurtenissenstroom beweegt slechts in voorwaartse richting. U kunt niet terugspringen of de gebeurtenissen herschikken zonder die gebeurtenissen eerst zelf vast te leggen. Het is belangrijk op te merken dat de beperkingen van SAX met opzet zijn aangebracht. SAX vormt slechts de kern van een bibliotheek voor ondersteuning van XML. De ‘s’ van SAX staat niet voor niets voor ‘simple’. Complexe functionaliteit hoort thuis in lagen bovenop SAX en maakt geen deel uit van SAX zelf. Er is gekozen om met de SAX-API te werken vanwege volgende redenen: 1) grote documenten zullen veel geheugen innemen; 2) de snelheid van gebeurtenisgebaseerde parsers; 3) het is niet de bedoeling om het ganse XML-document weer te geven, enkel een beschrijving van het bijhorende XML Schema-bestand.

20

3.1

Geheugengebruik bij SAX en DOM

Bij documenten met een gemiddelde ‘dichtheid’ van markup-gegevens worden bij veel DOMimplementaties in Java ongeveer 10 bytes geheugen gebruikt voor elke byte aan XML-tekst (BROWNELL, 2001, 7). Een middelgroot document van drie megabyte kan gemakkelijk uitdijen tot dertig megabyte! Bij grotere documenten leidt het gebruik van DOM regelmatig tot geheugentekorten, zowel een tekort aan virtueel geheugen als aan ruimte op de Java-heap. Bij SAX wordt echter alleen geheugen gebruikt als u daar uitdrukkelijk voor kiest. U kunt het grootste deel van dat document van drie megabyte in eerste instantie geheel buiten beschouwing laten. Door de structuur van de API worden automatisch alleen de significante gegevens opgehaald. Hierdoor moet niet zoveel geheugen worden toegekend en hoeft het systeem ook niet zoveel aandacht te besteden aan het opruimen van het geheugen.

3.2

Een beknopte geschiedenis van SAX

De ontwikkeling van SAX 1.0 begon eind december 1997, kort na de publicatie van het laatste concept van de XML 1.0-specificatie. De aanvankelijke doelstelling was Javaapplicaties onafhankelijk te maken van de gebruikte parser. Men beoogde ook uniformiteit te bevorderen in de gegevensmodellen die voor applicaties beschikbaar zijn, zonder een specifieke gegevensrepresentatie voor te schrijven. Op dat moment bestonden al diverse Javaparsers (zoals AElfred, Lark, MSXML en XP), elk met verschillende API’s en kenmerken. Er werd snel vooruitgang geboekt en de discussie speelde zich voornamelijk af op het internet, binnen de open mailinglist ‘xml-dev’. Het proces om SAX te starten ontstond door de vastberadenheid van Peter Muray-Rust. Hij startte een discussie met Tim Bray, redacteur van de XML 1.0-aanbeveling en auteur van Lark, evenals met David Megginson, de oorspronkelijke auteur van AElfred. De openheid stond op hetzelfde niveau als gebruikelijk was bij de Internet Engineering Task Force (IETF) en bij veel ontwikkelingsprogramma’s waarvan de broncode publiek gesteld wordt. De conversaties die plaats vonden kunnen nagelezen worden in de archieven: http://lists.xml.org/archives/xml-dev/’. Het eerste concept van de API verscheen in januari 1998, minder dan een maand na de aanvang. De SAX-API werd voltooid in mei 1998, slechts drie maanden nadat XML zelf was voltooid. In de uiteindelijke versie van SAX1 ontbraken een aantal voorzieningen. Wanneer u SAX probeert te gebruiken voor een rondgang van XML-gegevens, zult u merken dat belangrijke informatie wordt weggelaten. (Bij een rondgang van een SAX-gebeurtenissenstroom worden de gegevens weer geconverteerd naar XML-tekst en wordt het resultaat hiervan naar de parser gestuurd, zonder dat daarbij gegevens verloren gaan.) Ook als u met SAX een DOM-structuur probeert op te bouwen, zult u merken dat niet alles past. DOM verwacht namelijk meer dan de informatie die wordt geleverd. Dit is vooral een conformiteitprobleem. Door het ontbreken van DTD-declaraties was het daarnaast niet praktisch arbitrair geldige documenten te onderhouden met een exclusieve SAX1-parser. Bovendien was het niet mogelijk te bepalen of een parser kon valideren. Men realiseerde zich ook dat het goed zou zijn om de XML- namespace specificatie te ondersteunen in de parserAPI. Eind 1998 begon men verder te werken en in mei 2000 was SAX2 klaar.

21

4 Java API for XML Processing (JAXP) van Sun Vanaf JDK 1.4 is SAX2 opgenomen in de Java2 Standaard Editie (J2SE) als resultaat van het Java Community Process van Sun. SAX is onderdeel van versie 1.1 van sun’s Java API for XML Processing (JAXP). Bij de JDK-1.4 releases wordt een JAXP-implementatie geleverd. Voor de andere Java-platforms (JDK 1.1 en later) is JAXP afzonderlijk verkrijgbaar. De Java API voor XML verwerking dient voor de verwerking van XML-bestanden door toepassingen die in de Java taal geschreven zijn. JAXP ondersteunt zowel SAX (Simple API for XML) als DOM (Document Object Modeling). JAXP laat toe om fabrikantonafhankelijke XML conforme parsers te gebruiken. Dit is mogelijk omdat het gebruik maakt van een zogenaamde ‘pluggabiltity laag’ zodat een SAX of DOM-applicatie interface ingevoegd kan worden. De hoofd JAXP-API’s zijn gedefinieerd in het javax.xml.parsers package. Deze bevatten twee neutrale fabriekklassen. • •

SAXParserFactory DocumentBuilderFactory

Deze zorgen voor respectievelijk een SAXParser en een DocumentBuilder. Een DocumentBuilder maakt een DOM conforme Document object aan. Het laat eveneens toe om een parser van een ander merk te gebruiken zonder de programmacode te wijzigen. De parser die gebruikt wordt, is afhankelijk van de eigenschappen die je aan de fabriekklassen toekent. Voor ons is de SAXParserFactory van belang om een parser die SAX ondersteunt te verkrijgen.

22

5 Xerces-J parser Deze parser van Apache wordt gebruikt en is gratis verkrijgbaar van de Apache website: http://xml.apache.org/.

5.1

Ondersteuning

Xerces ondersteunt volgende standaarden: • • • • • • • •

Extensible Markup Language (XML) 1.0, derde editie recommandatie; Namespaces in XML-recommandatie; Extensible Markup Language (XML) 1.1 eerste editie recommandatie; Namespaces in XML 1.1 recommandatie; Document Object Model Level 2 ‘Core’, ‘Events en Traversal’ en ‘Range’ recommandaties; Simple API for XML (SAX) 2.0.1 kern en uitbreidingen; Java API’s for XML Processing (JAXP) 1.2; XML Schema 1.0 ‘Structures’ en ‘Datatypes’ recommandaties.

De versie die gebruikt wordt is de Xerces-J 2.6.2 uitgave. Zoals eerder vermeld bevat het een implementatie van de W3C XML Schema taal, een recommandatie van het World Wide Web Consortium. De implementatie is volledig conform, afgezien van de volgende beperkingen.

5.2 • • • •

Beperkingen van Xerces De Length, minLength en maxLength facetten zijn beperkt tot de waarde 2147483647. Waarden hoger dan deze limiet zullen niet correct gevalideerd worden. De waarden van minOccurs en maxOccusr attributen zijn beperkt tot dezelfde waarde. Opnieuw zullen hogere waarden niet correct gevalideerd worden. De waarden om een minimum of een maximum vast te leggen in een reguliere expressie voor een pattern zijn beperkt tot 2147483647. Het gedeelte na de komma bij datum/tijd datatypen is beperkt tot 2147483647.

Enkel de laatste beperking speelt in ons geval geen rol. Bij grote waarden voor het maxOccurs facet kan er een OutOfMemory exceptie optreden. Dit kan vermeden worden door voor deze waarden ‘unbounded’ als waarde te nemen.

23

5.3

Overzicht kenmerken van Xerces

De manier waarop de parser werkt, kan vastgelegd worden door kenmerken en eigenschappen te definiëren. Kenmerken worden vastgelegd met de setFeature(String id,boolean waarde) methode. Het ‘id’ is de URI, die bepaalt welk kenmerk bedoeld wordt. De boolean kan ‘true’ of ‘false’ als waarde aannemen. Het kenmerk dat gebruikt wordt in het programma is: - http://apache.org/xml/features/validation/schema.

Kenmerk ‘http://xml.org/sax/features/validation’ wordt niet gebruikt. In de plaats hiervan wordt de setValidating() methode gebruikt; De volledige lijst met kenmerken kan geraadpleegd worden op de website van Apache XML project. Hier worden enkel de belangrijkste weergegeven. http://xml.org/sax/features /namespaces True

False Standaardwaarde

Prefixes worden van elementen en attributen gehaald en worden vervangen door de overeenkomende URI’s. Standaard zullen de twee samengevoegd worden, maar de namespacesepcore eigenschap laat toe om het URI gedeelte en het locale gedeelte te scheiden. Namespaces worden niet verwerkt. True

Tabel 1: kenmerk ‘namespaces’ van de Xerces parser.

http://xml.org/sax/features /validation True False Standaardwaarde

Het document wordt gevalideerd en fouten worden gerapporteerd. Er worden geen fouten gerapporteerd. False

Tabel 2: kenmerk ‘validation’ van de Xerces parser.

http://apache.org/xml/features /validation/dynamic Het document zal enkel gevalideerd worden als er een True grammatica is gespecificeerd. Validatie wordt bepaald door de staat van het ‘validation’ False kenmerk. False Standaardwaarde Tabel 3: kenmerk ‘dynamic’ van de Xerces parser.

24

http://apache.org/xml/features /validation/schema XML Schema-validatie wordt geactiveerd door een XML True Schema-validator in de pijpleiding toe te voegen. Er zullen enkel foutmeldingen aangemaakt worden als het ‘validation’ kenmerk op true staat. Er wordt geen foutmelding vanwege de validatie tegen een False XML Schema gegenereerd. False Standaardwaarde Tabel 4: kenmerk ‘schema’ van de Xerces parser.

http://apache.org/xml/features /validation/schema-fullchecking De schemagrammatica wordt gecontroleerd op aanvullende True fouten. Dit kan een extra hoeveelheid tijd in beslag nemen. Geen extra controle. False False Standaardwaarde Tabel 5: kenmerk ‘schema-full-checking’ van de Xerces parser.

http://apache.org/xml/features/continueafter-fatal-error True False Standaardwaarde

Er wordt geprobeerd om verder te parsen na een fatale fout. Er wordt gestopt na een fatale fout. False

Tabel 6: kenmerk ‘continue-after-fatal-error’ van de Xerces parser.

http://apache.org/xml/features/augmentpsvi True False

Standaardwaarde

De Post-Schema-Validation-Infoset wordt verhoogd. Het wordt niet verhoogd. Het kan afgezet worden om de snelheid van het parsen te verhogen. True

Tabel 7: kenmerk ‘augment-psvi’ van de Xerces parser.

http://xml.org/sax/features/string-interning Alle elementnamen, prefixen, attribuutnamen, True namespace-URI en locale namen worden geïnternaliseerd met behulp van de ‘java.lang.String#intern(String)’ methode. Namen worden niet noodzakelijk False geïnternaliseerd. True. Dit kenmerk kan enkel op true geplaatst Standaardwaarde worden. Tabel 8: kenmerk ‘string-interning’ van de Xerces parser.

25

5.4

Overzicht eigenschappen van Xerces

Eigenschappen worden met de setProperty(String id, Object waarde) methode vastgelegd. Het “id” is de URI die de soort eigenschap bepaalt. Het “Object” argument is de waarde die eraan gegeven wordt. De eigenschappen die in het programma gebruikt worden zijn: - http://apache.org/xml/properties/schema/external-noNamespaceSchemaLocation; - http://apache.org/xml/properties/input-buffer-size. Ook hier worden enkel de interessantste weergegeven.

http://apache.org/xml/properties/ schema/external-schemaLocation Beschrijving

Type

Deze eigenschap laat toe om een aantal XML Schemabestanden te definiëren. Er moet een namespace gebruikt worden. Vb: http://voorbeeld.com bestandsnaam.xsd Java.lang.String

Tabel 9: eigenschap ‘external-schemaLocation’ van de Xerces parser.

http://apache.org/xml/properties/ schema/externalnoNamespaceSchemaLocation Beschrijving

Type

Hetzelfde als de vorige eigenschap maar nu zonder namespace. Vb: bestandsnaam.xsd Java.lang.String

Tabel 10: eigenschap ‘external-noNamespaceSchemaLocation’ van de Xerces parser.

http://apache.org/xml/properties /input-buffer-size Beschrijving

Type

Dit definieert de buffercapaciteit van de lezer, met andere woorden het aantal bytes per stuk. Sommige tests geven aan dat een grotere buffercapaciteit het behaalde resultaat van de parser kan verhogen bij relatief grote documenten. De standaard buffercapaciteit voor Xerces is 2 kB. Dit is goed voor kleine documenten (kleiner dan 10 kB). Voor grotere documenten kan 4 kB of 8 kB een beter resultaat teweegbrengen. Groter dan 16 kB wordt niet aangeraden. Java.lang.Integer

Tabel 11: eigenschap ‘input-buffer-size’ van de Xerces parser.

26

http://xml.org/sax/properties/ declaration-handler Beschrijving Type

Bepaalt de handler voor de DTD-declaraties. Org.xml.sax.ext.DecHandler

Tabel 12: eigenschap ‘declaration-handler’ van de Xerces parser.

http://xml.org/sax/properties /lexical-handler Beschrijving Type

Bepaalt de handler voor woordenschat parsing gebeurtenissen. Org.xml.sax.ext.LexicalHandler

Tabel 13: eigenschap ‘lexical-handler’ van de Xerces parser.

5.5

Ideale buffercapaciteit van de parser

Om de best mogelijke buffercapaciteit te vinden, werd bij onderstaande bestanden gekeken hoe lang het duurt om alle informatie te verkrijgen. De documenten werden geparst en daarna werden de objecten aangemaakt. Om een representatief resultaat te verkrijgen, werd dit bij ieder document honderdmaal uitgevoerd. Voor elk bestand werd er een gemiddelde berekend.

Naam

link.xml Lines.xml lux_import_gc_3.xml LUX_POI.xml POI_Update_DataBase.xml POI_Update_DataBase_IT4.xml POI_Update_PL1.xml Polygon Test_Region1.xml Update Fealing.xml LUX_Road_Polyline.xml

Capaciteit Tijd (msec.), Tijd (msec.) Tijd (msec.) (kB) buffercapaciteit: Buffercapaciteit: Buffercapaciteit: 2 kB. 4 kB. 8 kB. 557 7802 8297 627 99 7198 1225 62 69 6619

2254 92379 90519 6844 2163 112126 19248 417 1077 69523

2265 89936 89490 6718 2124 110007 18877 411 1069 61126

Tabel 14

Uit de resultaten kan besloten worden dat de ideale buffercapaciteit 4 kilobyte (4096 byte) is. Bij een buffercapaciteit van 8 kilobyte zijn de resultaten slechter dan bij een standaardinstelling van 2 kilobyte.

2427 94634 96805 7094 2217 114827 19739 431 1112 64028

27

6 Het ontwikkelde programma: External Data Investigator De applicatie omvat drie opties: 1. het aanmaken van een XML Schema-document aan de hand van een XML-bestand (het proefbestand); 2. valideren van een XML-bestand met behulp van een XML Schema-bestand; 3. valideren van een configuratiebestand met behulp van een XML Schema-bestand.

6.1

Aanmaak van een XML Schema-bestand

De aanmaak van een XML Schema-bestand kan gebeuren aan de hand van een XML-bestand of via een reeds aangemaakt XML Schema-bestand. In beide gevallen gebeurt de aanmaak in verschillende fasen. Men onderscheidt de volgende stappen: • • • •

parsen van het XML-document en verzamelen van de eigenschappen; analyseren van de informatie; een grafische voorstelling aanmaken van het XML Schema; een XML Schema uitschrijven.

6.1.1 Parsen van het document Om tot een XML Schema te komen, moet vanzelfsprekend de structuur en de inhoud van het document gekend zijn. Om de structuur te kennen, moet men van elk element zijn kindelementen en attributen kennen. Om de soort inhoud van een element of een attribuut te bepalen, worden al hun waarden verzameld.

Het verzamelen van deze informatie gebeurt in drie fasen: 1. het verzamelen van alle elementnamen; 2. van elk element de namen van de kindelementen, de attributen en de inhoud verzamelen; 3. voor elk element berekenen hoeveel keer het minimum en het maximum aantal keer het onder zijn ouderelement kan voorkomen. Het parsen van het document gebeurt via een parser die volgens het SAX-principe werkt. De gebruikte parser is de Xerces-J parser. Parsen zelf bestaat enkel uit het lezen van het document. Om informatie uit het document te halen, moet de parser daarvan op de hoogte gebracht worden. Dit wordt gedaan door een DefaultHandler klas toe te kennen aan de instantie van de parser. De DefaultHandler klas is een SAX2-helperklas die de meeste interfaces die in de SAX2-eventhandlers zijn ondergebracht bevat.

28

SAX2- gebeurtenissen zijn onderverdeeld in diverse interfaces. Op twee na worden ze allemaal geïmplementeerd door de DefaultHandler klas. Elke interface omvat een groep gebeurtenissen. Het behandelen van de gebeurtenissen wordt gedaan door: •

de ContentHandler die elementen callbacks, tekengegevens callback en de callback’s voor de meeste andere SAX2-gebeurtenissen behandelt;

•

de DeclHandler die DTD-declaraties die niet naar buiten worden gebracht door DTDHandler callbacks behandelt. Dit zijn declaraties van elementen, attributen en geparste entiteiten;

•

de DTDHandler die instaat voor het rapporteren van DTD-declaraties die de XML 1.0 specificatie van alle processors verlangt, namelijk declaraties voor notaties en voor niet-geparste entiteiten;

•

de ErrorHandler die een interface is om fouten en waarschuwingen te rapporteren. Doordat deze gebeurtenissen in één interface zijn ondergebracht is het mogelijk de behandeling van XML-fouten in de applicatiecode te centraliseren;

•

de LexicalHandler die vooral gegevens naar buiten brengt die geen semantische betekenis moeten hebben, zoals commentaar en de grenzen van de CDATA-secties, entiteiten en DTD’s.

Men spreekt van een callback als er een referentie aan een methode wordt doorgegeven die dan een bericht terugstuurt naar de referentie. SAX stelt niet de eis om van een DefaultHandler gebruik te maken, maar omdat de parser via JAXP aangemaakt wordt is dit wel een vereiste.

Gebeurtenissen die DefaultHandler behandelt: void characters(char[] ch, int start, int length)

Om notie van karakters binnen een element te ontvangen. void endDocument()

Om notie van het einde van een document te ontvangen. void endElement(String uri, String localName, String qName)

Om notie van het einde van een element te ontvangen. void endPrefixMapping(String prefix)

Om bericht van het einde van een namespace te ontvangen.

29

void error(SAXParseException e)

Om bericht van een fout te ontvangen. void fatalError(SAXParseException e)

Om bericht van een fatale fout te ontvangen. void ignorableWhitespace(char[] ch, int start, int length)

Om bericht van witruimte die gemeden moet worden in de elementinhoud te ontvangen. void notationDecl(String name, String publicId, String systemId)

Om bericht van commentaar te ontvangen. void processingInstruction(String target, String data)

Om bericht van een procesinstructie in het document te ontvangen. InputSource resolveEntity(String publicId, String systemId)

Een externe entiteit analyseren. void setDocumentLocator(Locator locator)

Om een Locator object te ontvangen. void skippedEntity(String name)

Om notie van een overgeslagen entiteit te ontvangen. void startDocument()

Om bericht bij het begin van een document te ontvangen. void startElement(String uri, String localName, String qName, Attributes attributes)

Om bericht bij het begin van een element te ontvangen. void startPrefixMapping(String prefix, String uri)

Om bericht bij het begin van een namespace te ontvangen. void unparsedEntityDecl(String name, String publicId, String systemId, String notationName)

Om bericht van een ongeparste entiteit te ontvangen. void warning(SAXParseException e)

Om bericht van een waarschuwing te ontvangen. Tabel 15: DefaultHandler gebeurtenissen.

30

De gebeurtenissen die opgevangen moeten worden voor het verzamelen van de informatie worden hieronder opgesomd. •

characters(char[] ch, int start, int length)

‘char[] ch’ is een tekenrij die de geleverde tekst bevat. Tekens uit deze buffer die buiten het opgegeven bereik vallen worden genegeerd. Het bereik wordt bepaald door ‘start’ en ‘length’, beide van type integer. De waarde ‘length’ is de offset tegenover ‘start’. • •

startElement(String uri, String localName, String qName, Attributes attributes) endElement(String uri, String localName, String qName)

De inhoud van een element wordt hier tussen haakjes geplaatst, waarbij startElement het begin van het element aanduidt. De attributen zijn meegegeven als parameter en zijn dus eenvoudig opvraagbaar. Normaal gezien wordt startElement gevolgd door een reeks andere gebeurtenissen om de onderliggende inhoud te rapporteren, bijvoorbeeld tekengegevens en andere elementen. Nadat alle onderliggende inhoud van het element is vermeld, geeft endElement aan dat het element is beëindigd. ‘String uri’ bevat de namespace-URI van het element. Indien het element niet gekoppeld is aan een namespace is dit een lege waarde. ‘String localName’ stelt, indien het element gebonden is aan een namespace, de elementnaam waarvan het prefix verwijderd is voor. ‘String qName’ is de elementnaam zoals die in de XML-tekst voorkomt. • •

startDocument() endDocument()

Deze twee duiden respectievelijk het begin en einde van een document aan.

31

A) Starten vanuit een XML- Document Het verzamelen van de elementnamen wordt beschreven in figuur 6.

Figuur 6: ophalen van de elementnamen uit het XML-bestand.

Bij het begin van een element ontstaat er een startElement-gebeurtenis, deze wordt opgevangen en zo kan de naam van het element verkregen worden. Het is mogelijk dat een element meerdere malen voorkomt en zo ook meerdere malen deze gebeurtenis veroorzaakt, maar de naam zal maar éénmaal bewaard worden. Om al de namen te verzamelen moet het document maar één keer geparst worden.

32

Figuur 7: gebruik van de startElement-gebeurtenis om gegevens over elementen te verzamelen.

Om van elk element de namen van zijn kindelementen, zijn attributen en alle inhoud te verzamelen, moet het document helaas evenveel geparst worden als er verschillende elementen zijn. Ook nu wordt er gebruik gemaakt van de startElement-gebeurtenis. De gebeurtenissen worden genegeerd totdat we het element, waarvan we de informatie zoeken, tegenkomen. Op dat moment wordt er een vlag (Kindelementvlag) gezet zodat de volgende gebeurtenissen niet meer genegeerd worden. Vanaf dan wordt er bij elke gebeurtenis de naam van het element bewaard, indien het element zich één niveau lager bevindt ten opzichte van het ouderelement. De attributen worden verzameld op het moment dat het ouderelement tegengekomen wordt. Tijdens de gebeurtenis die ontstaan is door het ouderelement wordt er ook een vlag gezet (Inhoudvlag), die aanduidt dat de inhoud opgehaald kan worden.

33

Figuur 8: gebruik van de characters-gebeurtenis om extra gegevens over elementen te verzamelen.

De inhoud kan opgehaald worden tijdens een characters-gebeurtenis en tijdelijk bewaard worden.

Figuur 9: gebruik van de endElement-gebeurtenis om extra gegevens over elementen te verzamelen.

Op het einde van elk element ontstaat er een endElement-gebeurtenis. Door deze gebeurtenis op te vangen kan de diepte van een element bepaald worden. Indien het ouderelement deze gebeurtenis veroorzaakt, wordt de vlag die toelaat om kindelementen te verzamelen (Kindelementvlag) geannuleerd. De vlag om de inhoud te bepalen (Inhoudvlag) wordt bij elke gebeurtenis geannuleerd.

34

Tenslotte wordt voor elk element berekend hoeveel keer een element onder zijn ouderelement kan voorkomen. Hiervoor moet het document evenveel geparst worden als er verschillende elementen zijn.

Figuur 10: gebruik van de startElement-gebeurtenis voor de berekening van het aantaal keer een element onder zijn ouderelement voorkomt.

De startElement-gebeurtenis is opnieuw de gebeurtenis die van belang is. Deze gebeurtenissen worden genegeerd totdat we het ouderelement tegenkomen. Op dat moment wordt er een vlag gezet die aanduidt dat de volgende gebeurtenissen afkomstig zijn van zijn kindelementen (Oudervlag). Vanaf dan wordt er gekeken of het element dat de gebeurtenis veroorzaakte het kindelement is die we zoeken. Wordt het kindelement tegengekomen dan wordt er een teller verhoogd (Diepte). Om te garanderen dat het een kindelement is en geen kleinkindelement, wordt er opnieuw naar de diepte gekeken.

35

De gebeurtenis die ontstaat op het einde van een element wordt gebruikt om de diepte te bepalen en om de gebruikte vlaggen te annuleren. Indien de gebeurtenis afkomstig is van het ouderelement wordt de waarde van de teller bewaard en op nul gezet.

Figuur 11: gebruik van de endElement-gebeurtenis voor de berekening van het aantal keer een element onder zijn ouderelement voorkomt.

36

B) Starten vanuit een XML Schema-document Om de informatie te verzamelen wordt ook nu in drie fasen gewerkt. Het ganse proces gebeurt nu wel vlugger omdat het document kleiner is. Het moet nu ook minder geparst worden. De drie fasen zijn: • verzamelen van de elementnamen; • ophalen van de namen van de kindelementen, het aantal keer een kindelement voorkomt, het type met eventueel een filter, de namen van de attributen en de referentie naar het type of het type zelf van de attributen; • ophalen van het type en filter van de attributen.

Het verzamelen van de elementnamen wordt in figuur 12 beschreven.

Figuur 12: gebruik van de startElement-gebeurtenis om de elementnamen te verzamelen uit een XML Schema-bestand.

37

Figuur 13: gebruik van de endElement-gebeurtenis om de elementnamen te verzamelen.

Ontstaat er een gebeurtenis die het begin van een element aanduidt, dan wordt er gecontroleerd of het element twee niveaus lager is dan het basiselement. Is dit het geval, dan wordt de waarde van attribuut ‘naam ‘en attribuut ‘type’ opgevraagd van het element met naam ‘element’ en met prefix ‘xs’. De gebeurtenis die ontstaat tengevolge van het einde van een element wordt gebruikt om de diepte te bepalen.

38

Om de tweede stap te voltooien moet het document evenveel geparst worden als er verschillende elementen zijn.

Figuur 14: gebruik van de startElement-gebeurtenis om extra gegevens over de elementen te verzamelen.

De gebeurtenis kenmerkend voor het begin van een element wordt genegeerd, totdat we het te behandelen element tegenkomen. Op dat moment wordt er een vlag gezet (Elementvlag) om dit bij te houden. Aan de hand van deze vlag kunnen de kindelementen opgehaald worden. Zolang deze vlag gezet is wordt er bij elke gebeurtenis gecontroleerd of het element die de gebeurtenis veroorzaakte de naam ‘element’ met prefix ‘xs’ bezit. Is dit zo, dan wordt de waarde van het attribuut ‘name’ opgehaald samen met de waarde van attribuut ‘minOccur’ en ‘maxOccur’. De laatste twee waarden geven aan hoeveel keer het kindelement onder zijn ouderelement kan voorkomen.

39 Er wordt eveneens een vlag gezet die bepaalt of er kindelementen zijn (Kindvlag). Is deze vlag gezet dan wordt er bij elke gebeurtenis een object aangemaakt dat het aantal keer een element kan voorkomen bevat (een ‘Elementmaxmin’ object). Indien het element dat de gebeurtenis veroorzaakte geen element is met naam ‘element’ en prefix ‘xs’, wordt er gekeken of het element dat wordt behandeld attributen bevat. Dit wordt gedaan door te controleren of de gebeurtenis die veroorzaakt werd, afkomstig is van een element met naam ‘attributeGroup’ en prefix ‘xs’. Indien dit het geval is, wordt de referentie naar de beschrijving van die attributen opgehaald en wordt er een vlag gezet die aanduidt dat het element attributen bevat (Bezitattribuutvlag). Eenmaal deze vlag gezet is, wordt er bij elke gebeurtenis gecontroleerd of het element dat het veroorzaakte de naam ‘attributeGroup’ met prefix ‘xs’ bezit en of de waarde van attribuut ‘name’ gelijk is aan de eerder opgehaalde referentie. Indien hieraan voldaan is, wordt er een vlag gezet die deze gebeurtenis aanduidt (Attribuutvlag). Is deze vlag gezet dan wordt er gewacht totdat een gebeurtenis ontstaat door een element met naam ‘attribute’ en prefix ‘xs’. Doet deze gebeurtenis zich voor, dan wordt de waarde van attribuut ‘name’ en ‘type’ opgehaald. Deze bevatten de naam van het attribuut en de referentie naar het type van het attribuut. Indien er geen filter toegepast werd is dit geen referentie, maar het type zelf. Bij elke gebeurtenis wordt er gecontroleerd of de plaats waar de inhoud van het element beschreven staat tegenkomen is. Dit kan gecontroleerd worden door te kijken of het element dat de gebeurtenis veroorzaakte de naam ‘simpleType’ met prefix ‘xs’ bezit en als waarde van het attribuut ‘name’ de referentie naar het type heeft. De referentie naar het type moet niet opgehaald worden, dit kan namelijk afgeleid worden uit de naam van het element. De referentie bestaat uit de samenvoeging van ‘RefOf’ en de naam van het element. Eenmaal deze gebeurtenis zich voorgedaan heeft wordt er een vlag gezet (Typevlag). Zolang deze vlag gezet is wordt er gewacht op een gebeurtenis afkomstig van een element met naam ‘restriction’ en prefix ‘xs’ om het type op te halen. Een gebeurtenis afkomstig van een element met naam ‘Pattern’ en prefix ‘xs’ duidt aan dat er een ‘Pattern’ filter aanwezig is. Een gebeurtenis ontstaan door een element met naam ‘maxLength’ en prefix ‘xs’ duidt aan dat er een ‘MaxLength’ filter toegepast werd. Is de oorzaak van de gebeurtenis een element met naam ‘minInclusive’ of ‘maxInclusive’ met prefix ‘xs’ dan is er een ‘Range’ filter. Is de naam van het element ‘enumeration’ dan is het een ‘Enumeration’ filter.

40

Figuur 15: gebruik van de endElement-gebeurtenis om extra gegevens over de elementen te verzamelen.

De gebeurtenis die ontstaan is door het einde van element, wordt gebruikt om de vlaggen te annuleren, de filternamen en hun waarden te bewaren.

Figuur 16: gebruik van de endDocument-gebeurtenis om extra gegevens over de elementen te verzamelen.

Op het einde van het document wordt er een ‘MyElement’ object aangemaakt.

41

De laatste stap bestaat uit het ophalen van de soort inhoud van de attributen. Om deze stap te voltooien moet het document evenveel geparst worden als er attributen zijn.

Figuur 17: gebruik van de startElement-gebeurtenis om het type inhoud van de attributen te verzamelen.

Ook nu wordt de startElement-gebeurtenis opgevangen. De gebeurtenis wordt genegeerd totdat de plaats waar de inhoud beschreven is, wordt tegengekomen. Dit is zo als er een element met naam ‘attribute’ met prefix ‘xs’, waarvan de waarde van attribuut ‘name’ gelijk is aan de naam van het attribuut die we zoeken en als de waarde van attribuut ‘type’ gelijk is aan de referentie naar de inhoud. Eenmaal er voldaan is aan deze voorwaarden, wordt er een vlag gezet (Typevlag). Zolang deze vlag gezet is worden er bij elke gebeurtenis gelijkaardige controles uitgevoerd zoals bij het ophalen van de soort inhoud van een element om het type en de filters te verzamelen.

42

Figuur 18: gebruik van de endElement-gebeurtenis om het soort inhoud van de attributen te verzamelen.

De endElement-gebeurtenis wordt gebruikt om de gebruikte vlag te annuleren en om de filters en hun waarden op te slaan.

6.1.2 Verwerking van de informatie Eenmaal de gegevens uit het document gehaald zijn worden ze geanalyseerd en bewaard in speciaal daarvoor ontwikkelde objecten. • • • • • •

Het ‘MyElement’ object. Het ‘MyAttribute’ object. Het ‘TypeObjcet’ object. Het ‘Elementmaxmin’ object. Het ‘XsdElement’ object. Het ‘NodeIndex’ object.

43

6.1.2.1 Objecten 1) MyElement Het ‘MyElement’ object is een beschrijving van een element in een XML-document. Het wordt gekenmerkt door de naam van het element, de namen van de kindelementen, de gebruikte inhoud en de attributen. De attributen zijn een verzameling van ‘MyAttribute’ objecten.

Figuur 19: het MyElement object.

2) MyAttribute Het ‘MyAttribute’ object wordt gebruikt om een attribuut te beschrijven. De naam en zijn inhoud worden bijgehouden.

Figuur 20: het Myattribute object.

44 3) TypeObject Het ‘TypeObject’ object is een beschrijving van de inhoud van een element of een attribuut. De inhoud wordt gekenmerkt door de naam, het type, de toegepaste filters en de waarden van de filters.

Figuur 21: het TypeObject object.

Mogelijke waarden voor het type zijn: ‘String’,’Integer’ en ‘Double’. Mogelijke filters die op een type toegepast kunnen worden zijn: Type String

Filter • Enumeration • Pattern • MaxLength

Integer

• •

Enumeration Range

Double

• •

Enumeration Range

Tabel 16: Inhoud van een element.

• • • •

Een ‘Enumeration’ is een opsomming van waarden die als inhoud kunnen dienen. Een ‘Pattern’ legt de inhoud vast door gebruik te maken van reguliere uitdrukkingen. Een ‘MaxLength’ legt het maximum toelaatbare karakters vast. Een ‘Range’ filter is een bereik. Deze wordt beschreven door een minimum- en een maximumwaarde. Het minimum en maximum zijn inbegrepen.

45

4) Elementmaxmin Het ‘Elementmaxmin’ object houdt, het aantal keer een element onder zijn ouderelement in het XML-document voorkomt, bij. Het wordt gekenmerkt door de naam van het element, de naam van het ouderelement, het minimum aantal keer en het maximum aantal keer. Bemerk dat de waarde van het maximum als een ‘String’ bewaard wordt en niet specifiek als een geheel getal. Dit komt omdat men de waarde ‘unbounded’ moet kunnen toekennen, zo kan men een oneindig aantal keer specificeren.

Figuur 22: het Elementmaxmin object.

5) XsdElement Het ‘XsdElement’ is een object dat wordt gebruikt tijdens het parsen, om het soort inhoud van een element op te halen. Het bevat de naam van het element en de referentie naar de plaats waar de inhoud staat beschreven.

Figuur 23: het XsdElement object.

46

6) NodeIndex Het ‘NodeIndex’ object wordt gebruikt om de opbouw van de weergave eenvoudig te houden. Het houdt van een element, de indexen van zijn kindelementen en attributen in de ‘Vector’ die alle DefaultMutableTreeNode objecten bevat, bij. Op deze manier kan snel de juiste node opgehaald worden tijdens de opbouw.

Figuur 24: het NodeIndex object.

47

6.1.2.2 Aanmaak van een standaard type en filter Aan de hand van de verzamelde inhoud van elk element en attribuut, wordt afgeleid hoe de inhoud het best beschreven kan worden. De inhoud wordt, zoals eerder al vermeld, beschreven door een type waarop er filters geplaatst kunnen worden. Aanmaak van een type

Figuur 25: aanmaak van een type.

Om het type te bepalen, wordt de totale inhoud van het element overlopen en gecontroleerd of ze allemaal gehele getallen zijn. Indien een waarde gevonden wordt die geen geheel getal is wordt er gecontroleerd of alle waarden decimale getallen zijn. Als ook hier een waarde wordt gevonden die niet voldoet, worden ze als karakters beschouwd. Aanmaak van de filters

Figuur 26: aanmaak van een filter.

48 Voor elementen die type ‘Integer’ of ‘Double’ bezitten wordt er een ‘Enumeration’ of een ‘Range’ filter aangemaakt. De factor die bepaalt dat het een ‘Range’ of een ‘Enumeration’ filter wordt is de ‘EnumLimit’ waarde. Deze waarde bepaalt het maximum aantal waarden een opsomming kan bezitten en kan door de gebruiker vastgelegd worden. Is het aantal verschillende waarden kleiner dan de vastgelegde ‘EnumLimit’ waarde dan wordt er een ‘Enumeration’ filter gebruikt. Indien het element type ‘String’ bezit zal er een ‘Enumeration’ of een ‘Pattern’ filter gebruikt worden. De ‘Pattern’ filter wordt gebruikt indien het aantal verschillende waarden groter is dan ‘EnumLimit’.

6.1.3 Opbouw van een weergave Nu we alle gegevens uit het XML-document of XML Schema gehaald hebben, moeten ze ook zichtbaar gemaakt worden voor de gebruiker. Om dit te verwezenlijken maken we gebruik van een JTree uit Java. Zo kan er een boomstructuur aangemaakt worden. Een JTree bestaat uit een aantal DefaultMutableTreeNodes die met elkaar verbonden zijn. Elk ‘MyElement’ object wordt overlopen. Van elk kindelement en attribuut wordt er een DefaultMutableTreeNode object gemaakt en opgeslagen. Om later op een eenvoudige manier de nodes terug te vinden, worden de posities bewaard met behulp van een ‘NodeIndex’ object. We beginnen vanaf het rootelement, elke tak wordt tot zijn einde doorlopen vooraleer naar de volgende tak te springen. De volgende stap bestaat erin om de zopas aangemaakte nodes met elkaar te verbinden. Zo wordt de structuur van het document weergegeven. Om zicht te geven op de inhoud worden de overeenkomende ‘TypeObject’ objecten opgehaald. Eenmaal het XML Schema-bestand weergegeven is, moet de gebruiker ook manipulaties kunnen uitvoeren. Een gebruiker kan: • een element of attribuut toevoegen; • een element of attribuut verwijderen; • een type en eventuele filters wijzigen; • een filter toevoegen of verwijderen. In de handleiding wordt beschreven op welke manier de gebruiker dit kan doen (zie bijlage 1).

49

6.1.4 Uitschrijven van het XML Schema-bestand Nadat de gebruiker eventuele wijzigingen heeft aangebracht moet het alleen nog in een XML Schema-bestand uitgeschreven worden.

6.1.4.1 Opbouw van een XML Schema-bestand Het aangemaakte XML Schema-bestand beschrijft de structuur en de inhoud van het XMLbestand. Als u een document bekijkt, zult u eerst de structuur kunnen aflezen en vervolgens de soort inhoud. Aan de hand van een voorbeeld wordt een aangemaakt XML Schema-bestand verduidelijkt.

Figuur 27: voorbeeld van een XML Schema-bestand (deel 1).

Figuur 27 geeft aan, dat het om een XML Schema-document gaat, dat er een UTF-8 codering wordt gebruikt en dat de namespace gelijk is aan: http://www.w3.org/2001/XMLSchema. Namespaces zorgen ervoor dat elementen met dezelfde naam verschillende betekenissen kunnen hebben. Het onderscheid wordt aangeduid met een prefix. Hier is het prefix ‘xs’. De URL die erbij geschreven staat, kan informatie over de gebruikte syntax bevatten. Dit is niet altijd het geval, maar hier is dat wel zo. 1) Structurele eigenschappen


Hier wordt gesteld dat het element met naam DATAPACKET, de elementen met respectievelijk de naam METADATA en ROWDATA als kindelementen bevat. Het element ‘element’ met prefix ‘xs’ is een element dat een element in het XML-document beschrijft. Dit zal altijd gepaard gaan met twee attributen: ‘name’ en ‘type’. Het is duidelijk dat deze attributen de naam en het type van het element bepalen. Attribuut ‘type’ zal altijd een referentie bevatten naar de naam van een element met naam ‘complexType’ en prefix ‘xs’. De referentie bestaat altijd uit ‘RefOf ‘gevolgd door de naam van het desbetreffende element.

50

Het ‘complexType’ element bevat de beschrijving van het desbetreffende element. Element ‘sequence’ wordt gebruikt om de kindelementen vast te leggen. Om aan te duiden welke kindelementen wordt eveneens het element ‘element’ gebruikt maar nu met attributen ‘ref’, ‘maxOccurs ‘en ‘minOccurs’. Attribuut ‘ref’ bevat de naam van het kindelement, ‘maxOccurs’ en ‘minOccurs’ bepalen hoeveel keer het kindelement mag voorkomen. De volgorde waarin de kindelementen staan is de volgorde die ook verwacht wordt in het XMLdocument. De aanwezigheid van het ‘attributeGroup’ element geeft aan, dat het beschreven element één of meerdere attributen bezit. De attributen worden op het einde van het document beschreven. Hieronder volgt de rest van de code die de structuur beschrijft. Het is gelijkaardig te interpreteren.


Element ‘METADATA’ bevat ‘TABLES’ als kindelement dat éénmaal moet voorkomen.


Element ‘TABLES’ bevat ‘TABLE’ als kindelement dat eveneens éénmaal moet voorkomen.

51


Element ‘TABLE’ bevat ‘NAME’ en ‘DATAFIELDS’ als kindelementen en bezit eveneens één of meerdere attributen.


Het ‘DATAFIELDS’ element bevat het ‘FIELD’ element als kindelement dat zesmaal moet voorkomen.


Het ‘FIELD’ element bezit ‘NAME’, ‘TYPE’ en ‘WIDTH’ als kindelement. Eerst wordt het element ‘NAME’ verwacht daarna ‘TYPE’ en ‘WIDTH’.

52


Element ‘ROWDATA’ heeft duizend zeshonderd en tweeëntwintig keer element ‘ROW’ als kindelement.


Het ‘ROW’ element bezit ‘LINESTRING’, ‘FEATUREID’, ’OSODR’, ‘ROADNAME’, ‘FHL’, ‘LHL’, ‘FHR’ en ‘LHR’ als kindelement.


Element ‘LINESTRING’ bevat het ‘COORD’ element als kindelement. Het ‘COORD’ element moet minstens tweemaal voorkomen en mag maximaal vierendertigmaal voorkomen.

53


Element ‘COORD’ bezit het ‘X’ en ‘Y’ element.

Wat tot nu toe beschreven werd, wordt nu grafisch weergegeven in figuur 38.

Figuur 38: voorstelling van de structuur van een XML Schema-bestand.

54 2) Inhoudelijke eigenschappen In figuur 39 staat de beschrijving van de inhoud van element ‘NAME’. Er wordt opnieuw gebruik gemaakt van het element ‘element’ met prefix ‘xs’ maar nu wijst de referentie die bij attribuut ‘type’ staat naar een ‘simpleType’ element. Men zal enkel van een referentie gebruik maken als er een filter werd toegepast op het type inhoud van het desbetreffende element. Indien de inhoud van een element werd beschreven door een basistype zonder filter zal het type rechtstreeks vermeld worden. Het soort filter kan je afleiden uit de soort elementen gebruikt als inhoud van het ‘restriction’ element. In het onderstaande geval is dit het ‘enumeration’ element, wat betekent dat als filter een opsomming gebruikt werd. Het basistype, waarop men de filter toepast, is te vinden bij attribuut ‘base’ van het ‘restriction’ element. Het attribuut ‘value’ bevat de waarden van de filter. Samengevat wil figuur 39 zeggen, dat element ‘NAME’ een inhoud moet hebben, die een waarde is van de opsomming FHL, FHR, LHL, LHR, link, OSODR en ROADNAME.



Element ‘TYPE’ mag enkel de waarde ‘string’ als inhoud hebben.

55


Element ‘WIDTH’ moet een inhoud hebben die bestaat uit een getal van de opsomming ‘13’, ‘50’ of ’60’.


Hier wordt er geen opsomming als filter gebruikt maar een bereik. Het ‘minInclusive’ en ‘maxInclusive’ element bepalen via attribuut ‘value’ het minimum en maximum van het bereik. Element ‘X’ moet een waarde hebben tussen 305000.001985132 en 309999.996673244 of gelijk aan een van deze grenswaarden.


Voor element ‘Y’ is het gelijkaardig als voor het ‘X’ element in figuur 42, maar met een ander bereik.

56


De inhoud van het ‘FEATUREID’ element moet tussen 1 en 1622 liggen ofwel gelijk zijn aan 1 of 1622.


Element ‘OSODR’ moet een inhoud hebben die bestaat uit maximum tien karakters. Hier is de toegepaste filter ‘maxLength’.


Element met naam ‘ROADNAME’ mag bestaan uit eender welke karakters. Het moeten natuurlijk wel karakters zijn die in UTF-8 codering mogen voorkomen.


De inhoud van element ‘FHL’ wordt bepaald door een ‘Pattern’ filter. Een ‘Pattern’ filter maakt gebruik van reguliere uitdrukkingen. De uitdrukking hier gebruikt, betekent dat de eerste twee karakters letters moeten zijn die tussen a en d liggen, gevolgd door een cijfer tussen 0 en 5. Een mogelijke inhoud is dus bc4, inhoud bc4bc4 is niet correct.

57


Element ‘LHL’, ‘FHR’ en ‘LHR’ mogen alle mogelijke karakters als inhoud hebben.

Op een element kunnen ook verschillende filters toegepast worden. De interpretatie blijft hetzelfde. De verschillende filters worden nu onder één restriction-element ondergebracht.


3) Attributen De al dan niet aanwezige attributen in het XML-document worden op het einde van het XML Schema-bestand beschreven. In het gedeelte waar de structuur werd vastgelegd, wordt er zonodig een referentie gegeven naar een naam van een bepaald ‘attributeGroup’ element. Dit element kan een aantal attributen groeperen. De werking is gelijkaardig als deze voor elementen. Het element met naam ‘attribute’ en prefix ‘xs’ maakt gebruik van het ‘use’ attribuut. Dit attribuut zal altijd ‘required‘ als waarde hebben, om aan te geven dat het attribuut gebruikt moet worden. Figuur 50 beschrijft de attributen van element DATAPACKET. De referentie naar een attributeGroup bestaat altijd uit ‘AttributeGroupOf’ gevolgd door de naam van het element. De attributen die gegroepeerd worden in een ‘attributeGroup’, worden beschreven door het element met naam ‘attribute’ en prefix ‘xs’. Het ‘type’ attribuut bevat, net zoals bij elementen, een referentie naar een ‘simpleType’ element, waar de inhoud beschreven zal worden. Maakt men geen gebruik van een filter, dan wordt geen referentie gebruikt, maar het type wordt onmiddellijk vermeld, net zoals het met elementen gedaan werd. Het overeenkomend ‘simpleType’ element zal onmiddellijk na ‘attributeGroup’ vermeld staan.

58


‘DataVersion’ en ‘Source’ zijn attributen van het element ‘DATAPACKET’.


Figuur 51 is de beschrijving van de inhoud van het ‘DataVersion’ attribuut. Het attribuut moet ‘V1.0’ als inhoud hebben.


Het attribuut ‘Source’ mag enkel ‘ESRI File Format’ als inhoud hebben.


In figuur 53 wordt weergegeven welk attribuut het element ‘TABLE’ bezit, nl. ‘ShapeType’. De inhoud ervan wordt beschreven door het ‘simpleType’ element. Het ‘ShapeType’ attribuut mag enkel ‘LINE’ als inhoud hebben. Het einde van een XML Schema-bestand wordt aangeduid figuur 54.


59

6.2

Validatie van het XML-bestand

Naast het aanmaken van een XML Schema-bestand moet het programma ook in staat zijn om een XML-document te valideren tegenover een XML Schema-document. De controle op het XML-bestand gaat na of het een geldig XML-bestand is. Als er een instantie van een parser aangemaakt wordt zal hij standaard niet valideren. Om aan te geven dat de parser moet valideren moet er een vlag gezet worden. Dit gebeurt door de setValidating methode de waarde ‘true’ mee te geven. Dit wordt gedaan met een instantie van een SAXParserFactory. Er moet ook aangegeven worden dat het document tegen een XML Schema-bestand gevalideerd moet worden. Dit wordt gedaan met behulp van een eigenschap aan een instantie van SAXParserFactory te geven. Deze eigenschap is ‘http://apache.org/xml/features/validation/schema’ en wordt toegekend met de setFeature methode. Indien er tijdens de validatie fouten gevonden zijn, zullen er ‘error’, ‘fatal error’ en ‘warning’ gebeurtenissen ontstaan. Door deze op te vangen via de DefaultHandler interface kunnen ze naar buiten gebracht worden. De foutmeldingen worden opgevangen en aan de gebruiker kenbaar gemaakt. De gebruiker kan kiezen om de standaard foutmeldingen of de aangepaste versie te verkrijgen. Bij de aangepaste versie worden de meldingen geanalyseerd om er een zo gebruiksvriendelijk mogelijke melding uit te krijgen. De meldingen worden ook gesorteerd per ‘ROW’ element. Om de reden hiervoor te verduidelijken zal het databestand uitgelegd worden.

Figuur 55: voorbeeld van een XML-databestand (1).

Een databestand bestaat altijd uit een ‘METADATA’ en een ‘ROWDATA’ gedeelte. Het ‘METADATA’ element is een beschrijving van de tabel waarin de data bewaard wordt. Het ‘ROWDATA’ gedeelte bevat de eigenlijke data. Het ‘ROWDATA’ element bestaat uit een aantal ‘ROW’ elementen. Het ‘ROW’ element bevat een aantal kindelementen die de eigenlijke data beschrijven.

Figuur 56: voorbeeld van een XML-databestand (2).

Door de foutmeldingen te groeperen per ‘ROW’ element heeft de gebruiker eenvoudig zicht op de plaats die de oorzaak van de foutmelding is.

60 De foutmelding wordt gesplitst in een boodschapgedeelte en een oorzaakgedeelte. Het boodschapgedeelte geeft aan welk element een fout veroorzaakte en het oorzaakgedeelte formuleert de oorzaak. Indien de gebruiker kiest om de standaard foutmeldingen te verkrijgen, kan het resultaat in een ’.log’ bewaard worden. De aangepaste versie wordt in een XML-bestand bewaard.

6.2.1 Overzicht van foutmeldingen Indien er een attribuut gedefinieerd is in het XML Schema-bestand maar niet in het XMLbestand voorkomt, wordt in de aangepaste versie de foutmelding gegenereerd zoals in figuur 57 weergegeven wordt. Het attribuut werd gedefinieerd in het ‘METADATA’ gedeelte.

Figuur 57: foutmelding als een attribuut niet aanwezig is in het XML-databestand (aangepaste vorm).

Indien de gebruiker voor de standaardfoutmeldingen gekozen heeft, ziet het eruit als in figuur 58.

Figuur 58: foutmelding als een attribuut niet aanwezig is in het XML-databestand (standaardvorm).

61

Indien er een element in het XML Schema gedefinieerd is maar niet in het XML-bestand voorkomt, wordt in de aangepaste versie de foutmelding gegenereerd zoals in figuur 59 weergegeven wordt.

Figuur 59: foutmelding als een element niet aanwezig is in het XML-databestand (aangepaste vorm).

Het element is gedefinieerd als kindelement van element ‘ROW’. Deze foutmelding wordt evenveel keer gegenereerd als er ‘ROW’ elementen zijn. Hier worden enkel de eerste twee ‘ROW’ elementen weergegeven.

Indien er voor de standaardfoutmeldingen gekozen is, ziet de foutmelding eruit zoals in figuur 60.

Figuur 60: foutmelding als een element niet aanwezig is in het XML-databestand (standaardvorm).

62 Indien er een element in het XML-bestand voorkomt die niet aanwezig is in het XML Schema-bestand, komt in de aangepaste versie de foutmelding voor zoals in figuur 61.

Figuur 61: foutmelding als een element niet gedefinieerd is in het XML Schema-bestand (aangepaste vorm).

Indien de gebruiker voor de standaardvorm gekozen heeft, ziet de foutmelding eruit zoals in figuur 62.

Figuur 62: foutmelding als een element niet gedefinieerd is in het XML Schema-bestand (standaardvorm).

63

In het XML Schema worden de kindelementen in een bepaalde volgorde gedefinieerd. Komt er een element in het XML-bestand in de verkeerde volgorde voor, dan wordt er een gelijkaardige foutmelding gegenereerd. Als oorzaak worden de namen gegeven van de elementen die op dat moment verwacht worden.

Indien er een ‘Enumeration’ filter wordt toegepast op een element en in het XML-bestand komt er een waarde voor die er niet aan voldoet, dan wordt in de aangepaste vorm de foutmelding gegeven zoals in figuur 63.

Figuur 63: foutmelding als een element niet voldoet aan de opgelegde ‘Enumeration’ filter (aangepaste vorm).

In de standaardvorm ziet het eruit zoals in figuur 64 weergegeven wordt.

Figuur 64: foutmelding als een element niet voldoet aan de opgelegde ‘Enumeration’ filter (standaardvorm).

64

Indien er een ‘Range’ filter toegepast wordt op een element en in het XML-bestand komt er een waarde voor die er niet aan voldoet, dan wordt in de aangepaste vorm de foutmelding gegeven die figuur 65 weergeeft.

Figuur 65: foutmelding als een element niet voldoet aan de opgelegde ‘Range’ filter (aangepaste vorm).

In standaardvorm ziet het eruit zoals in figuur 66.

Figuur 66: foutmelding als een element niet voldoet aan de opgelegde ‘Range’ filter (standaardvorm).

65

Indien er een ‘MaxLength’ filter toegepast wordt op een element maar in het XML-bestand komt er een waarde voor die langer is dan gedefinieerd, dan komt in aangepaste vorm de foutmelding voor die in figuur 67 beschreven staat.

Figuur 67: foutmelding als een element niet voldoet aan de opgelegde ‘MaxLength’ filter (aangepaste vorm).


Figuur 68: foutmelding als een element niet voldoet aan de opgelegde ‘MaxLength’ filter (standaardvorm).

66

Indien er een ‘Pattern’ filter toegepast wordt en er komt een waarde voor die niet aan de reguliere uitdrukking voldoet, dan ontstaat in aangepaste versie de foutmelding voor die in figuur 69 weergegeven wordt.

Figuur 69: foutmelding als een element niet voldoet aan de opgelegde ‘Pattern’ filter (aangepaste vorm).


Figuur 70: foutmelding als een element niet voldoet aan de opgelegde ‘Pattern’ filter (standaardvorm).

67

Als er een waarde voorkomt die niet voldoet aan het opgelegde type, ziet de foutmelding in aangepaste vorm eruit zoals in figuur 71.

Figuur 71: foutmelding als een element niet voldoet aan het opgelegde ‘integer’ type (aangepaste vorm).


Figuur 72: foutmelding als een element niet voldoet aan het opgelegde ‘integer’ type (standaardvorm).

Een fout veroorzaakt door het niet overeenkomen met het opgelegde type heeft voorrang op de eventuele filters. Er zal geen foutmelding zijn vanwege de filter. De ‘Maxlength’ filter heeft voorrang op een ‘Enumeration’ filter, eveneens op een ‘Pattern’ filter. Een ‘Enumeration’ filter heeft voorrang op een ‘Range’ filter. Een ‘Pattern’ filter heeft voorrang op een ‘Enumeration’ filter.

68

6.3

Validatie van het configuratiebestand

Een laatste functionaliteit die het programma ondersteunt is het valideren van het configuratiebestand aan de hand van een XML Schema-bestand. Vooraleer de werking van de validatie uit te leggen, wordt het configuratiebestand zelf uitgelegd.

6.3.1 Het configuratiebestand Men kan altijd twee delen onderscheiden: het metadata gedeelte, dat slechts een beschrijving is van het document en een reeks instructies. Het metadata gedeelte is voor ons van geen belang.

Figuur 73: voorbeeld van een configuratiebestand (deel 1).

Onder het ‘CSTAT’ element bevinden zich de instructies. Deze worden nu onder de loep genomen. De instructies hebben betrekking op de elementnamen en op de inhoud van de elementen.


In het stukje code die in figuur 74 weergegeven wordt, is het duidelijk dat de commandonaam ‘CREATEPOI’ is. Dit is de inhoud van het ‘CMD’ element. De rest van de code bestaat uit ‘FLD’ instructies en een instructie met een constante. Een ‘FLD’ instructie, bijvoorbeeld FLD{PermanentId}, moet u als volgt interpreteren: • haal de waarde van element ‘PermanentId’ uit het databestand; • plaats die in de inhoud van element ‘PermanentId’. De instructie van een constante betekent bijvoorbeeld dat aan element ‘CPATYPE’ de waarde 1 gegeven moet worden.

69

Een andere instructie kan een ‘CASE’ instructie zijn.


Een ‘CASE’ instructie wordt uitgevoerd op het element waarvan de naam zich tussen het ‘NAME’ element bevindt. Het ‘NAME’ element is een kindelement van het ‘FIELD’ element. In het geval van figuur 75 wordt het op ‘OfficialNameLanguage’ toegepast. Element ‘CASELIST’ behandelt de verschillende ‘CASEEL’ elementen. Elk ‘CASE’ element bevat zijn eigen instructieset, deze wordt beschreven door element ‘CSTAT’. Deze is pas geldig als de inhoud van het ‘VAL’ element overeenkomt met de inhoud gedefinieerd voor het element in het databestand waarop de ‘CASE’ instructie uitgevoerd wordt. Er kan eveneens een ‘ELSE’instructie gevonden worden, deze wordt uitgevoerd als de voorgaande ‘VAL’ elementen niet van toepassing zijn.


70

In figuur 76 wordt gekeken of het element waarop de ‘CASE’ instructie uitgevoerd wordt, de waarde ‘ENG’ bezit. De instructies die uitgevoerd moeten worden zijn: • • • • • •

element ‘OFFICIALID’ en ‘PREFIX’ leeg laten; element ‘NAME’ de waarde van element ‘dg_matchstreetprefixandbody’ uit het databestand geven; element ‘LANGUAGE’ de waarde 1 geven; element ‘OTHERLANGUAGE’ leeg laten; de vorige elementen zijn kindelementen van ‘STREET’; voor element ‘ADDRESSNAME’ is het gelijkaardig.

In figuur 77 wordt er nog een ander type instructie weergegeven. Een conditie bestaat uit een uitdrukking die bestaat uit een operator, die toegepast wordt op de parameters. De operator vind je terug in de inhoud van het ‘OPERATOR’ element. Is de uitdrukking juist dan worden de instructies onder element ‘TRUE’ uitgevoerd, zoniet deze onder element ‘FALSE’.


Tot nu toe werd om inhoud toe te kennen aan een element de instructie ‘FLD{elementnaam}’ gebruikt ofwel werd er met een constante gewerkt. Er kan echter ook een concatenatie van constanten en velden gebruikt worden.

71


In figuur 78 wordt de waarde van ‘STREETNAME’ opgehaald en wordt er straat aan toegevoegd.

6.3.2 Parsen van het configuratiebestand Om de controles uit voeren, worden het XML Schema-bestand en het configuratiebestand geparst om de nodige gegevens te verzamelen. De manier waarop dit gebeurt voor het XML Schema-bestand is dezelfde als bij het openen van een XML Schema-bestand om er wijzigingen in aan te brengen (zie p36) . Het verzamelen van de gegevens uit het configuratiebestand gebeurt in twee stappen. Eerst worden alle ‘FLD’ waarden opgehaald, eveneens degene die in concatenatie voorkomen. De elementnamen die in een ‘CASE’ voorkomen worden eveneens in die stap opgehaald. De tweede stap bestaat in het verzamelen van alle waarden die een element gebruikt in een ‘CASE’. Er wordt opnieuw gebruik gemaakt van de DefaultHandler-klas om de gebeurtenissen op te vangen tijdens het parsen.

Figuur 79: gebruik van de characters-gebeurtenis om de ‘FLD’ waarden te verzamelen.

Als er een characters-gebeurtenis ontstaat, wordt de verkregen inhoud tijdelijk bewaard om eventueel later te gebruiken.

72

Figuur 80: gebruik van de startElement-gebeurtenis om de ‘FLD’ waarden te verzamelen.

Tijdens een startElement-gebeurtenis wordt er telkens gekeken of de inhoud verkregen tijdens een characters-gebeurtenis een ‘CONCAT’ instructie of een ‘FLD’ instructie is. In beide gevallen wordt de waarde van de ‘FLD’ instructie bewaard. Om de elementen te verzamelen die in een ‘CASE’ instructie gebruikt worden, is het wachten tot er een gebeurtenis ontstaat tengevolge van een ‘CASE’ element. Op dat moment wordt er een vlag gezet (Casevlag). Vervolgens is het wachten tot er een gebeurtenis ontstaat tengevolge van een element met naam ‘FIELD’. Als deze gebeurtenis zich voordoet zetten we een vlag om deze te onthouden (Fieldvlag). Indien deze vlag gezet is wordt er gewacht op een gebeurtenis vanwege een element met naam ‘NAME’. Als deze gebeurtenis zich voordoet wordt er opnieuw een vlag gezet (Naamvlag). Deze vlag wordt gebruikt tijdens de gebeurtenis ontstaan door het einde van een element, een endElement-gebeurtenis.

73

Figuur 81: gebruik van de endElement-gebeurtenis om de ‘FLD’ waarden te verzamelen.

Bij een endElement-gebeurtenis wordt er gewacht op een gebeurtenis tengevolge van een element met naam ‘CASE’, om de vlag die gezet werd tijdens een startElement-gebeurtenis te annuleren (Casevlag). Als er een gebeurtenis ontstaat wanneer deze vlag gezet is, wordt er gecontroleerd of de gebeurtenis ontstaan is tengevolge van een element met naam ‘NAME’ of met naam ‘FIELD’. Indien de gebeurtenis is ontstaan tengevolge van een element met naam ‘FIELD’, wordt de vlag gezet bij een startElement-gebeurtenis geannuleerd (Fieldvlag). Indien het ontstaan is tengevolge van een element met naam ‘NAME’ wordt de inhoud verkregen door de characters-gebeurtenis bewaard. Dit is de naam van het element waarop de ‘CASE’ instructie uitgevoerd wordt.

74 In de tweede stap worden alle waarden die een element gebruikt in een ‘CASE’ instructie verzameld. Hiervoor moet het document evenveel keer geparst worden als er ‘CASE’ elementen zijn.

Figuur 82: gebruik van de characters-gebeurtenis om de ‘CASE’ elementen te verzamelen.

De characters-gebeurtenis wordt opgevangen om de inhoud van een element tijdelijk te bewaren.

Figuur 83: gebruik van de startElement-gebeurtenis om de ‘CASE’ elementen te verzamelen.

De gebeurtenissen ontstaan door een startElement-gebeurtenis worden genegeerd totdat deze veroorzaakt worden door een element met naam ‘CASE’. Op dat moment wordt er een vlag gezet (Casevlag). Vanaf dat moment wordt er gecontroleerd of een element met naam ‘CASELIST’ de oorzaak is. Indien dit zo is wordt er een vlag gezet (Caselistvlag). Er wordt eveneens gecontroleerd of een element met naam ‘FIELD’ de oorzaak is. Ook hier wordt er een vlag gezet om de gebeurtenis aan te duiden (Fieldvlag).

75 Indien deze vlag gezet is tijdens een startElement-gebeurtenis, wordt er gecontroleerd of het element dat de gebeurtenis veroorzaakt heeft de naam ‘NAME’ bezit. Op dat moment wordt er een vlag gezet (Naamvlag). Indien deze vlag gezet is tijdens een startElement-gebeurtenis veroorzaakt door een element met inhoud gelijk aan de elementnaam van het element dat we zoeken, wordt er een vlag gezet (Kijkvoornaamvlag). Indien er een gebeurtenis ontstaat door een element met naam ‘VAL’ en deze vlag is gezet dan wordt er opnieuw een vlag gezet om deze gebeurtenis te onthouden (Waardenvlag). Deze vlag is van belang tijdens een endElement-gebeurtenis om een waarde die in een ‘CASELIST’ gebruikt wordt te verzamelen.

Figuur 84: gebruik van de endElement-gebeurtenis om de ‘CASE’ elementen te verzamelen.

De gebeurtenissen die het einde van een element kenmerken worden opgevangen om de gezette vlaggen te annuleren. Als de vlag die tijdens een startElement-gebeurtenis vanwege een ‘VAL’ element gezet is (Waardenvlag), dan wordt de inhoud van het element bewaard. Indien een element met naam ‘ELSE’ de oorzaak is van een endElement- gebeurtenis dan wordt de inhoud van dat element gecontroleerd. Indien het leeg is, wordt dit ‘ELSE’ element genegeerd. Indien een element met naam ‘CASE’ de oorzaak is van de endElementgebeurtenis dan wordt er een ‘CaseElement’ object aangemaakt.

76

6.3.3 Het CaseElement object

Figuur 85: het CaseElement object.

Het ‘CaseElement’ object wordt gebruikt om van een element die in een ‘CASE’ instructie gebruikt wordt de mogelijke waarden bij te houden. Het bevat ook een eigenschap die aanduidt of er een ‘ELSE’ instructie gebruikt werd.

6.3.4 De controles Nadat alle gegevens verzameld zijn, kan de eigenlijke controle uitgevoerd worden. De controle bestaat uit twee luiken. Het eerste luik omvat het controleren van het configuratiebestand tegen het XML Schema-bestand. Het tweede luik bestaat erin om het XML Schema-bestand te toetsen tegen het configuratiebestand. De controle op het configuratiebestand moet de volgende toestanden vermijden: • • • •

dat de inhoud van een element uit het databestand opgevraagd wordt, maar dat het element niet voorkomt in het databestand; dat er een ‘VAL’ waarde van een element die in een ‘CASE’ instructie gebruikt wordt, in tegenspraak is met het soort inhoud gedefinieerd in het XML Schema-bestand voor het desbetreffende element; dat het databestand elementen bevat waarvan de inhoud niet opgevraagd wordt door het configuratiebestand; een laatste mogelijkheid is dat bij een ‘CASE’ instructie niet alle mogelijke ‘VAL’ waarden, volgens het XML Schema-bestand, aan bod komen.

We onderscheiden een controle op de ‘FLD’ instructies en op de ‘CASE’ instructies. De controle van het configuratiebestand tegen het XML Schema-bestand bestaat in een eerste stap uit het controleren van de ‘FLD’ instructies. De waarden van de ‘FLD’ instructies stellen de namen voor van elementen. Er moet gecontroleerd worden of die elementen wel gedefinieerd zijn in het XML Schema-bestand. Dit kan eenvoudig gebeuren omdat alle elementen uit het XML Schema-bestand opgehaald worden. Een tweede stap bestaat uit het controleren van de ‘CaseElementen’. Hier wordt gecontroleerd of de waarden die gebruikt worden in het configuratiebestand voldoen aan de soort inhoud, gedefinieerd in het XML Schema-bestand.

77 Het toetsen van het XML Schema-bestand tegen het configuratiebestand bestaat uit het controleren of alle elementen gedefinieerd in het XML Schema-bestand gebruikt worden in een ‘FLD’ instructie. Er wordt eveneens gecontroleerd of de elementen die in een ‘CASE’ instructie gebruikt worden alle mogelijke waarden volgens het soort inhoud, gedefinieerd in het XML Schema-bestand, bevat. Indien er bijvoorbeeld een ‘Enumeration’ filter gedefinieerd is in het XML Schema-bestand, wil dit zeggen dat alle opsommingwaarden verwacht worden in het configuratiebestand als waarde in de ‘CASELIST’. Indien er een ‘ELSE’ instructie aanwezig is voor het element in het configuratiebestand hoeven niet alle waarden letterlijk voor te komen. Ze worden behandeld in de ‘ELSE instructie’. Het resultaat van dit tweede luik wordt niet als fouten beschouwd maar wel als waarschuwingen. Een mogelijk resultaat van een controle op een configuratiebestand wordt in figuur 86 weergegeven.

Figuur 86: een mogelijk resultaat van een controle op een configuratiebestand.

78

In figuur 86 ziet u een foutmelding vanwege een waarde die in een ‘CASE’ instructie gebruikt werd en die niet voldoet aan de beschreven ‘Enumeration’ filter die in het XML-Schemabestand beschreven staat. De foutmeldingen voor de overige filters of vanwege een type zijn gelijkaardig.

79

BESLUIT External Data Investigator stelt de gebruiker in staat om op een eenvoudige manier een XML Schema-bestand aan te maken. Het bestand wordt geanalyseerd door het programma en stelt een XML Schema-bestand voor om te gebruiken. De gebruiker kan indien hij dat wenst nog wijzigingen aanbrengen. De controles op het databestand en het configuratiebestand leveren correcte en duidelijke resultaten af. Het programma voldoet dus aan de drie vooropgestelde eisen en kan als een succes beschouwd worden.

96

LITERATUURLIJST WWW-sites: http://www.saxproject.org/ http://java.sun.com/ http://www.w3.org/ http://xml.apache.org/ http://www.xml.org/ Cursussen: CALU, J., 2001 XML, 166 p. Boeken: BROWNWELL, D., 2002. SAX2. XML efficiënt verwerken met Java, 211 p. ISBN: 90-395-1997-8 PITTS, N.,2001. XML Grand Cru, 701 p. ISBN: 90-5167-436-8

Gebruik en aanmaak van XML Schema voor validatie van externe data

Recommend Documents