Veel informatie over XML en bijbehorende zaken (zoals DTD, XSL etc.) is te vinden via de Home page van XML 101 (URL: ).

Transcriptie

1 ; 0/ H0Q3'D,W9D,P2R4G/H0OO H0U7L Q3J Inhoudsopgave: 8.0 Inleiding 8.1 XML: extensible Markup Language 8.2 Functie en gebruik van DTD (Document Type Definition) DTD-ELEMENT-definities Externe DTS s DTD-ATTLIST-definities DTD-ENTITY- en DTD-NOTATION-definities 8.3 XML-querytalen en XSL: extensible Stylesheet Language 8.4 Mapping van XML(/DTD) naar relationele tabel(structuur) 8.0 Inleiding De inhoud van documenten is vaak niet expliciet gestructureerd. Zo kun je op WWW weliswaar via trefwoorden zoeken, maar het is daarbij niet mogelijk om aan te geven wat dat trefwoord in dat document voor functie moet hebben. Als voorbeeld geven we de gevonden NAW-gegevens: Saskia van Tilburg woont in Amsterdam op de Hof van Hoorn 27. Zochten we op plaatsnaam Tilburg, Amsterdam of Hoorn? Duidt dat Hoorn nu op een plaats, een adres of een materiaalsoort? Ook om via het Internet aangeleverde gegevens correct te kunnen verwerken, zul je vaak de structuur van die gegevens willen meegeven. XML kan daarbij helpen (XML staat voor extensible Markup Language ). In XML zouden we de eerder gegeven zin als volgt kunnen modelleren: <NAWgegeven> <Naam>Saskia van Tilburg</Naam> <Adres>Hof van Hoorn 27</Adres> <Plaats>Amsterdam</Plaats> </NAWgegeven> Ook zonder verdere kennis van XML is nu van de woorden Tilburg en Hoorn de functie te zien. We citeren [ 1 ] : XML is rapidly establishing itself as the metagrammar for interorganizational communication around the Internet. It is becoming increasingly urgent that business analysts, systems analysts, and software developers be able to: model the information to be represented in XML describe the relationships between the XML and the systems to process it. Having done so, they must also be able to rapidly generate the boilerplate code associated with implementing these processes. Het is mogelijk maar weinig zinvol om XML geïsoleerd te gebruiken. Het krijgt pas zijn kracht als we voorafgaand aan XML-gebruik eerst een structuurdefinitie vastleggen via DTD ( Document Type Definition ) en een check [laten] doen om te controleren of het XML-datadeel wel voldoet aan de via een DTD vastgelegde grammatica. Pas daarna kunnen we aan de slag om via speciale XML-querytaal relevante gegevens op te vragen en/of op een speciale manier te presenteren. Voor die presentatie is het gebruik van XSL ( extensible Stylesheet Language ) mogelijk. We behandelen deze onderwerpen in de volgorde: 1. XML ( extensible Markup Language ) ; 2. DTD ( Document Type Definition ) ; 3. XSL ( extensible Stylesheet Language ). Veel informatie over XML en bijbehorende zaken (zoals DTD, XSL etc.) is te vinden via de Home page van XML 101 (URL: ). 1 G. Booch, M. Christerson, M. Fuchs, J. Koistinen. UML for XML Schema Mapping Specification. 12/08/99. 1

2 8.1 XML: extensible Markup Language XML wordt gebruikt om zowel documenten als gegevens te modelleren/structureren. Daarbij moeten we via een open - en een sluit -tag aangeven wat onze XML-elementen zijn en hoe die genest zijn. We lezen [ 2 ]: An XML document is a tree -like structure. This tree consists of nodes that possess a hierarchical relationship to each other. To promote or demote a node is to raise or lower that node to a different level within that hierarchy. Schematisch zal een XML-model er steeds als volgt uitzien: <root> <child> <subchild> </subchild> </child> </root> Elk kind -element kan weer een of meer sub-kind -elementen bevatten. Zo zou je in XML de gegevens bij een verenigingslid als volgt kunnen modelleren 3 : <LID> <Naam> <Voornaam>Jan</Voornaam> <Achternaam>Janssen</Achternaam> </Naam> <Adres>Annastraat 123</Adres> <Plaats>Nijmegen</Plaats> Duidelijk is hier te zien, dat een LID-element blijkbaar een Naam -, een Adres - en een Plaats - onderdeel kent, waarvan het Naam -deel beschouwd kan worden als een samengesteld kind-element met een voornaam- en een achternaam-subkind, terwijl Adres en Plaats als directe kind -elementen beschouwd kunnen worden. In ORM-terminologie zouden we dit XML-verenigingslid-model (ruwweg; we komen er later op terug waarom we hier geen details geven) op een van de hieronder getoonde manieren kunnen modelleren (hetzij via een primary reference -combinatie van rollen, hetzij via een nesting ): "Naam" Naam met als P Voornaam en P Voornaam Achternaam Achternaam Lid woont op Adres met als Lid woont op Adres woont in Plaats woont in Plaats Behalve met een nesting van (kind)elementen is het bij XML ook mogelijk om met attributen te werken. Door sommige auteurs wordt het gebruik van attributen binnen XML sterk ontmoedigd. We vatten hier op een vrije manier een aantal punten samen zoals verwoordt door Jan Egil Refsnes in zijn XML Basics (via de home page van XML101 bereikbaar). Attributen worden vooral gebruikt voor het geven van aanvullende informatie bij een bepaald element; meestal gaat het dan om gegevens die voor een menselijke gebruiker niet zo interessant zijn, maar die wel nodig zijn voor het door een computer [efficiënt] laten verwerken van de gegevens. Denk hierbij aan zaken als identificerende lidnummers, codes e.d.. 2 Help-functie van de XML-Notepad. 3 Laat je niet ontmoedigen door de overvloed aan tags (tussen < en > ) die blijkbaar nodig zijn voor het aanbrengen van XML-structuur; die zul je maar zelden zelf hoeven in te tikken. Daarvoor gebruik je normaal gesproken een tool, of je laat het XML-document genereren (bijvoorbeeld vanuit een database-systeem), of je laat door wat Javascriptcode door een gebruiker ingevulde gegevens o p een Web-pagina voorzien van XML-tags. 2

3 Eventuele attributen worden als volgt in de element-openings-tag opgenomen: <Elementnaam attribuutnaam = attribuutwaarde > Let op de spatie tussen Elementnaam en attribuutnaam en op de [verplichte!] dubbele aanhalingstekens rond de attribuutwaarde. In ORM-terminologie is de attribuutnaam soms te zien als de reference-code voor Elementnaam, maar kan hij ook vaak vergeleken worden meteen ORM- value-type (bij de bespreking van DTD - ATTLIST gaan we hier verder op in). Hierna is (rechts) een scherm weergegeven van de freeware XML-Notepad-editor, waarmee we het hierna (links) weergegeven XML-document hebben gemaakt (alle tags zijn gegenereerd!). We hebben in dit voorbeeld ervoor gekozen het lidnummer als attribuutwaarde bij LID te nemen. <LEDEN> <LID lidnummer="12345"> <Naam> <Voornaam>Jan</Voornaam> <Achternaam>Janssen</Achternaam> </Naam> <Adres>Annastraat 123</Adres> <Plaats>Nijmegen</Plaats> <LID lidnummer="13579"> <Naam> <Voornaam>Els</Voornaam> <Achternaam>Pietersen</Achternaam> </Naam> <Adres>Molenweg 33</Adres> <Plaats>Nijmegen</Plaats> </LEDEN> Uit dit voorbeeld komt duidelijk het altijd benodigde root -element naar voren (hier: onder de naam LEDEN ). Let in het Structure -deel van de figuur op het gebruik van de verschillende symbolen. Hiernaast tonen we hoe het XML-bestand getoond kan worden via een Web-browser als Internet Explorer 5. Het ziet er niet erg WWW-appetijtelijk uit, maar dat is ook niet de bedoeling van een kaal XML-bestand (later komt dit aspect bij XSL terug). In ieder geval is Internet Explorer 5 blijkbaar in staat de XML-code correct te interpreteren. Voor elk (sub)element staat een + of een - -teken om aan te geven of de waarden en/of dieper geneste inhoud niet dan wel aangegeven is. Met een eenvoudige muisklik kun je + en - in elkaar laten overgaan. Getoond is, dat als een LID-element dichtgeklapt is, van dat LID alleen de attribuutwaarde getoond wordt. Als zo n element méér attribuutwaarden, worden attribuutnamen+waarden achter elkaar in de <LID>openingstag opgenomen; bijvoorbeeld: <LID lidnummer ="12345" sofinummer =" "> N.B. Indien we bij het aanmaken van het XML-document een fout tegen de XML-syntax maken, dan zal bij het inladen van het document door de internet-browser een foutboodschap worden gegenereerd als bijvoorbeeld (met hier een tikfout in de eind -tag): The XML page cannot be displayed Cannot view XML input using XSL style sheet. Please correct the error and then click the Refresh button, or try again later. End tag 'Achternam' does not match the start tag 'Achternaam'. Line 5, Position 31 <Achternaam>Janssen</Achternam> ^ 3

4 N.B. Een free XML-parser is o.a. te downloaden van de MicroSoft-pagina (zie verderop in deze tekst). Met zo n parser kunnen we vooraf controleren of de ingetikte XML -code aan de syntaxregels voldoet. Indien we (handmatig, met een eenvoudige editor zoals NotePad) in het hiervoor gegeven, met XMLtags gestructureerde LEDEN-gegevens toevoegen: <LID kleur = "bruin" > <Wielen> 2 </Wielen> en de inhoud van het bestand daarna inladen in een XML-geschikte Web-browser, dan worden de gegevens van dat vreemde derde lid zonder prote st getoond. We kunnen via XML blijkbaar wel een bestaande structuur van gegevens duidelijk aangeven, maar niet de gegevensstructuur binnen een UoD modelleren, noch te respecteren beperkingsregels afdwingen. 8.2 Functie en gebruik van DTD (Document Type Definition) Een DTD (Document Type Definition) bestaat uit een formele set van regels waaraan een XMLdocument moet voldoen. Het definieert de elementen die gebruikt mogen worden en legt vast waar ze in relatie tot elkaar gebruikt mogen worden. Je kunt een DTD beschouwen als een soort (tekstueel) conceptueel schema van de datastructuur binnen een UoD en de bijbehorende constraints. De modelleringsmogelijkheden via DTD zijn echter veel beperkter dan die van het ons bekende ORM. Een DTD bevat een aantal declaraties, die allen aan de volgende opmaakstructuur: <! > moeten voldoen en waarin [onmiddellijk na het uitroepteken] een van de volgende sleutelwoorden moet staan: ELEMENT (voor de al eerder bij het XML-deel besproken element- tag definities) ATTLIST (idem de attribuut definities) ENTITY (nieuw: entiteit definities; zie verderop) NOTATION (nieuw: datatype notation definities; zie verderop) Deze declaraties worden gegroepeerd en geplaatst binnen een document type declaration die de volgende structuur : <!DOCTYPE doctypenaam [ <!ELEMENT doctypenaam (.. en hier volgt dan een 1 e deel van de DTD -definitie..) > <!.... en verder... > <!.... en verder... > ] > N.B. Een XML-document hoeft voor de specificatie van zijn structuur niet per se een bijbehorende DTD te hebben. Toch wordt het opstellen van zo n DTD vaak aanbevolen om zekerheid af te dwingen over het naleven van de gedefinieerde structuur. Een speciale DTD/XML-parser kan worden gebruikt om eerst de DTD te lezen en daarna te bepalen of het XML-document wel aan dat DTD-sjabloon voldoet. Een geschikte DTD/XML-parser (met een boel Javascript-code) is onder de naam XML Validator via de volgende URL: bij MicroSoft te downloaden (met bestandsnaam: validate_js.htm ) of van daar af te activeren DTD-ELEMENT-definities ELEMENTs : dit zijn de primaire eenheden om XML-documenten mee op te bouwen. De tag definities via ELEMENT kunnen nonterminal of terminal zijn, dat wil zeggen: er kan mee aangegeven worden, dat een bepaald ELEMENT op zijn beurt verder opgebouwd is uit een of meer andere ELEMENTs, maar ook, dat zo n verdere opsplitsing niet gebeurt. Dat laatste geval (dus bij terminal ) wordt meestal gebruikt om het gegevenstype PCDATA (lees: parsable character data, een [getal]string e.d., waarin opmaaktekens als <, >,, & e.d. als (html -) markup zullen worden geïnterpreteerd) van dat ELEMENT aan te geven. 4

5 Voor het door ons eerder besproken XML-voorbeeld met een LEDEN -document geven we als mogelijk/voorlopig DTD (en daarnaast een zo veel mogelijk vergelijkbaar ORM-schema): <!DOCTYPE LEDEN [ <!ELEMENT LEDEN ( LID+ ) > <!ELEMENT LID ( Naam, Adres, Plaats ) > Naam met / van <!ELEMENT Naam ( Voornaam, Achternaam ) > / van <!ELEMENT Voornaam ( #PCDATA ) > met / van <!ELEMENT Achternaam ( #PCDATA ) > Lid Adres <!ELEMENT Adres ( #PCDATA ) > woont op <!ELEMENT Plaats ( #PCDATA ) > ]> Plaats De komma s in het DTD geven tevens aan, dat de daarbij gebruikte volgorde moet worden aangehouden. woont in Voornaam Achternaam Een voorbeeld van een nonterminal ELEMENT-declaratie hierin is <!ELEMENT Lid (Naam, Adres, Plaats)>. Een voorbeeld van een terminal ELEMENT-declaratie is: <!ELEMENT Plaats ( #PCDATA)>. (N.B. Naast #PCDATA komen ook de aanduidingen #CDATA, #EMPTY en #ANY voor.) We hebben de nonterminal elementen in het ORM -schema als ORM-entiteiten aangegeven en de terminal als ORM -value-types. Via het -symbool kunnen we keuzes aangeven ( <!ELEMENT Dessert ( ijs vrucht ) > ). Indien bepaalde onderdelen vaker kunnen voorkomen en/of optioneel zijn, kunnen we als occurrence indicator de volgende symbolen gebruiken: Symbool Beschrijving + Een [verplicht!] element kan een of meer keren voorkomen (>=1) * Een [optioneel!] element kan nul of meer keren voorkomen (>=0)? Een [optioneel!] element kan hoogstens een keer voorkomen (0, 1) Voor een XML-voorbeeld met een [of een hele verzameling] boek[en], geven we de volgende DTD: <!DOCTYPE BOEK [ <!ELEMENT BOEK ( Titel, Auteur+, Hoofdstuk+ )> <!ELEMENT Hoofdstuk ( Titel, Inhoud )> <!ELEMENT Inhoud ( Paragraaf+ )> <!ELEMENT Titel (#PCDATA)> <!ELEMENT Auteur (#PCDATA)> <!ELEMENT Paragraaf (#PCDATA)> ]> Een volgens deze DTD mogelijk geldig XML-document is: <!-- voorbeeld invulling : (dit is een commentaarregel) --> <BOEK> <Titel>Over XML</Titel> <Auteur>Jansen, Jan</Auteur> <Auteur>Pietersen, Els</Auteur> <Hoofdstuk> <Titel>1. Inleiding</Titel> <Inhoud> <Paragraaf>Hier staat de inhoud van de eerste paragraaf</paragraaf> <Paragraaf>En hier staat de inhoud van de tweede paragraaf</paragraaf> </Inhoud> </Hoofdstuk> <Hoofdstuk> <Titel>2. Titel van het tweede hoofdstuk</titel> <Inhoud> <Paragraaf>Inhoud paragraaf 2.1</Paragraaf> <Paragraaf>Inhoud paragraaf 2.2</Paragraaf> <Paragraaf>Inhoud paragraaf 2.3</Paragraaf> </Inhoud> </Hoofdstuk> </BOEK> In dit voorbeeld, het betreffende boek naast een titel ook de namen van 2 auteurs en vervolgens 2 hoofdstukken (elk bestaande uit een (hoofdstuk)titel + een uit 2 en 3 paragrafen opgebouwde inhoud ). 5

6 We geven hiernaast een ruw, mogelijk niet geheel correct voorbeeld van een vergelijkbaar ORMschema dat dezelfde structuur beschrijft. Met * is aangegeven, dat de daar aangegeven uniciteitsregel niet hoeft te kloppen. Zo wordt uit het DTD niet mogelijk of een auteur al dan niet meerdere boeken kan hebben (mee-) geschreven. Misschien zou een bepaald hoofdstuk wel in meerdere boeken kunnen voorkomen e.d.. Ook totaliteitsregels zijn door het DTD niet geheel gedefinieerd; mag bijvoorbeeld een hoofdstuk voorkomen, zonder dat het tot een boek behoort? Ook hier (b)lijkt ORM veel krachtigere modelleringsmogelijkheden te bezitten dan DTD. Boek / schreef * * Hoofdstuk Auteur Titel met Paragraaf Inhoud * Het bovenstaande is geheel in overeenstemming met het eerder genoemde tree-like karakter van XML/DTD: in de richting van de wortel naar de terminal -bladeren toe, kunnen via een DTD een aantal soorten constraints (zoals enkelvoudige uniciteiten en totaliteiten) redelijk worden beschreven. De meeste gebruikte ( normale, tree -based) parsers controleren inderdaad alleen in deze richting van wortel naar bladeren Externe DTS s Omdat DTDs meestal als een standaard voor meerdere XML -documenten worden gemaakt, bestaat ook de mogelijkheid zo n DTD -standaard in een apart bestand op te slaan en er vanuit relevante [XML- ] documenten als volgt naar te verwijzen (let op het gebruik van het woord SYSTEM): <!DOCTYPE LEDEN SYSTEM "D:/IS0/XML/Leden.DTD" > [ <!... met hier eventuele aanvullende definities voor dit ene document.. > <! > ] > N.B. Er moet dan géén <!DOCTYPE LEDEN... -regel meer in dat aparte DTD-bestand staan DTD-ATTLIST-definities ATTLIST : via attribuut definities kunnen we aangeven dat een ELEMENT een of meer attributen kan hebben, die echter in een andere volgorde kunnen voorkomen dan in die ATTLIST staat (N.B. een ELEMENT hoeft niet per se attributen te hebben!). De syntax voor een ATTLIST-declaratie is: <!ATTLIST element-naam attribuut-naam attribuut-type default-value > Bij het eerder gegeven voorbeeld <!ELEMENT BOEK (Titel, Auteur+, Hoofdstuk+ )> zou je als attribuutlijst kunnen hebben: <!ATTLIST BOEK isbnnr CDATA #REQUIRED >. Attributen kunnen vereist (#REQUIRED ), optioneel (#IMPLIED ) of vast ( #FIXED) zijn (de z.g. attribute defaults). Een van deze drie mogelijke default-values moet ingevuld worden. Let er op, dat deze attribute defaults wél voorafgegaan worden door een #, terwijl de eraan voorafgaande type-aanduiding (hier: CDATA) géén #. Let er ook op, dat bij definiëring van een ATTLIST onmiddellijk nà het woord ATTLIST steeds eerst de naam van het XML-element genoemd wordt en pas daarna de naam van het bijbehorende attribuut. Daarnaast bestaan een viertal z.g. tokenized attribute types ( ID, IDREF, ENTITY en NMTOKEN ), waarmee de opsteller van de DTD in staat is de toegestane waarden voor een bepaald attribuut te bewaken. ID moet een unieke identifier voor het bewuste ELEMENT zijn. Attributen van het type IDREF verwijzen naar een ELEMENT met een ID-attribuut; elke IDREF-waarde moet naar een gelijke ID waarde in het XML-document verwijzen. Door gebruik te maken van een ID-attribuut kunnen we dus [als tenminste de XML-data terdege geparsed/gecontroleerd worden op naleving van de eisen van het betreffende DTD], een -in NIAM/FCO-IM/ORM-terminologie- uniciteitsregel afdwingen. Via een IDREF-attribuut is een soort foreign key-verwijzing te simuleren, zij het dat zowel de ID- als de ernaar verwijzende IDREFattribuutwaarde in eenzelfde XML-document moeten voorkomen. 6

7 Uit het boek XML, How to program van Deitel, Deitel, Nieto, Lin & Sadhu halen we het volgende voorbeeld met betrekking tot het gebruik van ID/IDREF: <?xml version = "1.0"?> <!-- Example for ID and IDREF values of attributes --> <!DOCTYPE bookstore [ <!ELEMENT bookstore ( shipping+, book+ )> <!ELEMENT shipping ( duration )> <!ATTLIST shipping shipid ID #REQUIRED> <!ELEMENT book ( #PCDATA ) > <!ATTLIST book shippedby IDREF #IMPLIED> <!ELEMENT duration ( #PCDATA ) > ] > <bookstore> <shipping shipid = "s1"> <duration>2 to 4 days</duration> </shipping> <shipping shipid = "s2"> <duration>1 day</duration> </shipping> <book shippedby = "s2"> Java How to Program 3rd edition. </book> krijgt of kreeg Boek <book shippedby = "s2"> C How to Program 3rd edition. </book> Boekwinkel geleverd bij <book shippedby = "s1"> C++ How to Program 3rd edition. </book> </bookstore> krijgt of kreeg * Levering (ShipID) met Levertijd In het rechts aangegeven ORM-schema, waarbij geprobeerd is een ORM-model te maken van de door het DTD beschreven situatie, zijn weer een aantal zaken onzeker, zoals: Kan een levering ook voor meerdere boekwinkels tegelijk zijn?. Ook is het vreemd dat Boek van een value -type lijkt te zijn. Als we voorgaande DTD/XML-tekst [via Copy/Paste] invoeren in MicroSofts XML Validator en we veranderen bij het laatste book-element de shippedby-attribuutwaarde in s5, dan verschijnt de melding: The attribute ' shippedby' references the ID ' s5' which s not i defined anywhere in the document. Line: 31, Position: 28, ErrorCode: 0xC00CE00E Ook mogelijk bij het gebruik van attributen zijn de z.g. enumerated attribute types, waarbij een lijst van mogelijke waarden aangegeven wordt, die een attribuut mag hebben. Dat kan iets zijn van de vorm: <!ATTLIST person gender ( M F ) F #REQUIRED> waarbij F als default-waarde is aangegeven. Via dergelijke enumerated attribute types zijn de voor ons van ORM bekende waarderegels aan te geven en af te dwingen DTD-ENTITY- en DTD-NOTATION-definities Over betekenis en gebruik van deze twee sleutelwoorden willen we hier weinig vermelden. Een entity is in XML -terminologie eigenlijk een variabele waar een waarde aan toegekend kan worden en waarvan de waarde door referentie via & +entity-naam+ ; opgevraagd kan worden. Ook in HTML hebben we dat al ongemerkt toegepast; omdat in HTML opmaaktekens als > niet rechtstreeks kunnen worden afgedrukt, zijn die tekens impliciet in entities/variabelen opgeslagen. Daarom kunnen we via HTML dat > -teken toch op het beeldscherm krijgen via de referentie >. Als voorbeeld van hetgebruik van een ENTITY-definitie geven we hier: <!DOCTYPE EntityProbeersel [ <!ELEMENT EntityProbeersel ( #PCDATA ) > <!ENTITY variabelenaam "haar hond Tarzan" > ]> 7

8 <EntityProbeersel> Els en &variabelenaam; met nog wat! </EntityProbeersel> Als we dit bestand in Internet Explorer 5 laden, dan zien we dat de substitutie plaatsgevonden: <!DOCTYPE EntityProbeersel (View Source for full doctype...)> <EntityProbeersel>Els en haar hond Tarzan met nog wat!</entityprobeersel> Door gebruik te maken van de SYSTEM -optie is het ook mogelijk de waarde voor een ENTITY uit een ander bestand te laten ophalen. Dat kan via een constructie als: <!ENTITY variabelenaam SYSTEM "D:/is0/xml/Varwaarde.txt" > Op het gebruik van <!NOTATION... > gaan we hier niet in. N.B. een (krachtiger) alternatief voor DTD s zijn de z.g. XML Schema s (o.a. afkomstig van en gepropageerd/ondersteund door Microsoft) waarbij het o.a. ook mogelijk is om het vereiste gegevenstype (int, date, char, string e.d.) aan te geven!! Mede door hun tekstuele aard zijn deze schema s al snel zo complex, dat je ze eigenlijk alleen door een tool kunt laten genereren. 8.3 XML-querytalen en XSL: extensible Stylesheet Language Tot nu toe hebben we ons gericht op het via XML aangeven van de structuur van gegevens en het via DTD definiëren van hoe die structuur kan en moet zijn. Zoals we al eerder aangaven is de bedoeling van dat structuren, dat expliciet aangegeven wordt wat de betekenis van bepaalde gegevens is. Herinner je uit de inleiding dat voorbeeld van: Saskia van Tilburg woont in Amsterdam op de Hof van Hoorn 27. en dat we ons daarbij afvroeg en wat de functie van de verschijnende plaatsnamen dan wel was. Via de aangebrachte XML-tags moet het nu ook mogelijk zijn om in een XML-document gewenste gegevens te selecteren. Vaak worden op het Internet via XML gestructureerde gegevens (b.v. van een bestelling via WWW) aangeleverd en vervolgens door een speciale applicatie geanalyseerd en ingebracht in een grote relationele database. Voor het kunnen bewerken van XML-data zou een standaard XML-querytaal (zoals SQL voor relationele databasesystemen) erg nuttig zijn. Zo n defacto standaard bestaat echter [nog] niet. W3C is bezig met het ontwikkelen van een specificatie voor XQuery (de voorziene officiële XMLquerytaal). 4 Een aantal bestaande XML-querytalen zijn: XML-QL (van AT&T Labs), XQL (van Microsoft), Lorel, UnQL, Quilt en YaTL. Een aantal interessante mogelijkheden voor het selecteren van XML-data zijn reeds aanwezig in XSL [extensible Stylesheet Language]. We tonen hierna een voorbeeld van het gebruik van XSL. We gaan daarbij uit van de eerder besproken, via XML gestructureerde LEDEN -verzameling. Omdat we van plan zijn ze via een Web-browser op een bepaalde manier te laten zien, vermelden we op regel 2 van het volgende bestand, volgens welk.xsl -bestand [XSL: extensible Stylesheet Language] ze getoond moeten worden: <?xml version="1.0"?> <?xml:stylesheet type="text/xsl" href="leden.xsl"?> <LEDEN> <LID> <Naam> <Voornaam>Jan</Voornaam> <Achternaam>Janssen</Achternaam> </Naam> <Adres>Annastraat 123</Adres> <Plaats>Nijmegen</Plaats> <LID> 4 Zie: Quering XML-data door Ikram Abasov, (KUN-student) 30/03/2001 8

9 <Naam> <Voornaam>Els</Voornaam> <Achternaam>Pietersen</Achternaam> </Naam> <Adres>Molenweg 33</Adres> <Plaats>Nijmegen</Plaats> </LEDEN> We geven nu de inhoud van de genoemde Leden.xsl-stylesheet: <?xml version="1.0"?> <html xmlns:xsl=" > <H3>Ledenoverzicht</H3> <body> <xsl:for-each select="leden/lid"> <h4> <xsl:value-of select = "Naam/Voornaam" /> <xsl:value-of select = "Naam/Achternaam" /> </h4> <I> <xsl:value-of select ="Adres" /> <xsl:value-of select ="Plaats" /> </I> </xsl:for-each> </body> </html> N.B. waar de 2 e regel in dit XLS-bestand voor dient, is mij (GP) een raadsel (functioneert ook zonder internet-verbinding!) Via XSL-selectie-opdrachten als <xsl:value-of select =.... /> is het mogelijk om de gewenste attributen te selecteren en de hen toebedachte behandeling te geven. Via de XSL-iterator-functie <xsl:for-each select =.... /> is het mogelijk om door het gehele gegevensbestand heen te gaan en bij elk lid op de gewenste wijze de genoemde attribuut -waarden te tonen. Indien we het Leden.xml-bestand nu in een Web-browser (die XML aankan!) laden, krijgen we voor dit voorbeeld het volgende overzicht: Ledenoverzicht Jan Janssen Annastraat 123 Nijmegen Els Pietersen Molenweg 33 Nijmegen Bij gebruik van een ander.xsl-bestand kan dit overzicht op een totaal andere manier verschijnen. 8.4 Mapping van XML(/DTD) naar relationele tabel(structuur) Voorlopige versie: De voor ons gemakkelijkste wijze om een XML/DTD gegevensstructuur te mappen naar een relationele tabelstructuur, is die via ORM. Maak eerst een zo goed mogelijk (de reden daarvoor hebben we hiervoor gezien) met de XML/DTD-structuur corresponderend ORM-schema en bepaal daaruit de benodigde relationele database-structuur. Er wordt her en der voor deze mapping aan directe transformatie-algoritmen gewerkt, maar die werken nog niet optimaal. Zie als voorbeeld Mapping DTDs to Databases, by Ronald Bourret, May 09, 2001 via URL: 9

10 Met daarin o.a. To start, notice that there is an obvious mapping between the following XML document, object, and row in a table: XML Objects Tables ============= ============ =============== Table A <A> object A { <B>bbb</B> B = "bbb" B C D <C>ccc</C> <=> C = "ccc" <=> <D>ddd</D> D = "ddd" </A> } bbb ccc ddd Similarly, there is an obvious mapping between the following element type definition, class, and table schema: DTD Classes Table Schema ====================== ============ ========================== class A { CREATE TABLE A String B; B VARCHAR(10) NOT NULL, <!ELEMENT A (B, C, D)> <=> String C; <=> C VARCHAR(10) NOT NULL, String D; D VARCHAR(10) NOT NULL } ) Bij het gebruik van complexere DTD s (met ATTLIST e.d.) worden deze transformaties eveneens complexer zoals bijvoorbeeld: DTD Classes Tables ======================== ============== ============== <!ELEMENT A (B, C)> class A { Table A <!ATTLIST A String b; Column a_pk D IDREFS #IMPLIED> ==> String c; ==> Column b <!ELEMENT B (#PCDATA)> String[] d; Column c <!ELEMENT C (#PCDATA)> } Table D Column a_fk Column d Waarbij in de relationele tabellen de uitgang _pk staat voor primary key en de uitgang _fk voor foreign key. Er wordt ook een algoritme besproken voor het omzetten van XML/DTD naar relationele databaseschema s, ofschoon bij de hierna geschetste transformatie als opmerking wordt geplaatst: A generated schema isn' t going to be the same as a human would have written. In addition to naming problems (for example, a person might have called the tables Orders, Items, and Parts), the generation algorithm was unable to determine that the relationship between Items and Parts was many-to-one. The algorithm was also unable to recognize that OrderNum and PartNum could be used as primary keys. Als we onze eigen aanpak (via het eerst opstellen van een zo goed mogelijk overeenkomstig ORM - schema en het vervolgens mappen naar een relationele structuur) loslaten op het voorbeeld van de laatste hiervoor gegeven transformatie, dan komen we eigenlijk tot een andere uitkomst. Het meest voor de hand liggende ORM-schema is hiernaast weergegeven. A verplichte rollen met B en C, maar de rol naar D is optioneel (immers: een implied attribuut). Mapping daarvan naar een relationele structuur levert één D enkele tabel op, met D als optionele kolom (hetgeen dus met afwijkend is van de door henzelf gevonden structuur met 2 tabellen, waarbij de waarde van d alleen via een foreign key gekoppeld mag zijn aan een waarde van a die ook in de andere tabel voorkomt). Ons resultaat lijkt dus heel wat beter en op een elegantere wijze verkregen. A met met B C 10