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

IS0-cursus: XML en Datamodellering

;0 ; 0/ / HHQ Q ' 'D DW WD DP PR RG GH HOO OOH HU UL LQ QJ J Inhoudsopgave: 8.0 Inleiding 8.1 XML: ‘eXtensible Markup Language’ 8.2 Functie en gebruik van DTD (Document Type Definition) 8.2.1 DTD-ELEMENT-definities 8.2.2 Externe DTS’s 8.2.3 DTD-ATTLIST-definities 8.2.4 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: Saskia van Tilburg Hof van Hoorn 27 Amsterdam

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: www.xml101.com ).

1

G. Booch, M. Christerson, M. Fuchs, J. Koistinen. UML for XML Schema Mapping Specification. 12/08/99. 1


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: <subchild>

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: Jan Janssen Annastraat 123 Nijmegen

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" Voornaam Naam

met als

heeft

en

P

Voornaam

P

Achternaam

heeft

Achternaam met als

Lid

Adres

Lid

woont op

Adres woont op

Plaats

Plaats

woont in

woont in

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. 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. 3

2


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. Jan Janssen Annastraat 123 Nijmegen Els Pietersen Molenweg 33 Nijmegen

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 heeft, worden attribuutnamen+waarden achter elkaar in de openingstag opgenomen; bijvoorbeeld:

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 Janssen ------------------------------^

3


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: <Wielen> 2

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 heeft: ] >

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: http://msdn.microsoft.com/downloads/samples/internet/xml/xml_validator bij MicroSoft te downloaden (met bestandsnaam: validate_js.htm ) of van daar af te activeren.

8.2.1

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


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): ]>

Voornaam Naam

met / van

heeft / van

Achternaam met / van

Lid

Adres woont op Plaats woont in

De komma’s in het DTD geven tevens aan, dat de daarbij gebruikte volgorde moet worden aangehouden. Een voorbeeld van een ‘nonterminal’ ELEMENT-declaratie hierin is . Een voorbeeld van een ‘terminal’ ELEMENT-declaratie is: . (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 ( ). 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:

BOEK ( Titel, Auteur+, Hoofdstuk+ )> Hoofdstuk ( Titel, Inhoud )> Inhoud ( Paragraaf+ )> Titel (#PCDATA)> Auteur (#PCDATA)> Paragraaf (#PCDATA)>

Een volgens deze DTD mogelijk geldig XML-document is: <Titel>Over XML Jansen, Jan Pietersen, Els <Titel>1. Inleiding <Paragraaf>Hier staat de inhoud van de eerste paragraaf <Paragraaf>En hier staat de inhoud van de tweede paragraaf <Titel>2. Titel van het tweede hoofdstuk <Paragraaf>Inhoud paragraaf 2.1 <Paragraaf>Inhoud paragraaf 2.2 <Paragraaf>Inhoud paragraaf 2.3

In dit voorbeeld, heeft 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


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.

Paragraaf

Auteur

heeft / schreef Boek

*

Titel heeft

met

*

Inhoud

heeft Hoofdstuk

heeft heeft

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.

8.2.2

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): [ ] >

N.B. Er moet dan géén ‘
8.2.3

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:

Bij het eerder gegeven voorbeeld zou je als attribuutlijst kunnen hebben: . 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 ‘#’ heeft. 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


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: shippedBy IDREF #IMPLIED> ]> <shipping shipID = "s1"> 2 to 4 days <shipping shipID = "s2"> 1 day Java How to Program 3rd edition. C How to Program 3rd edition.

Boek krijgt of kreeg geleverd bij Boekwinkel

*

C++ How to Program 3rd edition.

krijgt of kreeg

Levering (ShipID)

Levertijd met

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 noti 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: 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.

8.2.4

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: ]>

7


<EntityProbeersel> Els en &variabelenaam; met nog wat!

Als we dit bestand in Internet Explorer 5 laden, dan zien we dat de substitutie heeft plaatsgevonden: <EntityProbeersel>Els en haar hond Tarzan met nog wat!

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:

Op het gebruik van 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: Jan Janssen Annastraat 123 Nijmegen 4

Zie: Quering XML-data door Ikram Abasov, (KUN-student) 30/03/2001 8


Els Pietersen Molenweg 33 Nijmegen

We geven nu de inhoud van de genoemde Leden.xsl-stylesheet:
Ledenoverzicht
<xsl:for-each select="LEDEN/LID">
<xsl:value-of select = "Naam/Voornaam" /> <xsl:value-of select = "Naam/Achternaam" />
<xsl:value-of select ="Adres" /> <xsl:value-of select ="Plaats" /> N.B. waar de 2e 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: http://www.xml.com/pub/a/2001/05/09/dtdtodbs.html 9


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 ===============

bbb ccc ddd

object B = C = D = }

Table A ------B C ----... ... bbb ccc ... ...

<=>

A { "bbb" "ccc" "ddd"

<=>

D --... ddd ...

Similarly, there is an obvious mapping between the following element type definition, class, and table schema: DTD ======================

Classes ============

class A { String B; String C; String D; }

<=>

Table Schema ==========================

<=>

CREATE TABLE A B VARCHAR(10) NOT NULL, C VARCHAR(10) NOT NULL, 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 ==============

class A { String b; String c; String[] d; }

Table A Column Column Column Table D Column Column

==>

==>

a_pk b c a_fk 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 heeft verplichte rollen met B en C, maar de rol naar D is optioneel (immers: een ‘implied’ attribuut).

B met A

C met

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.

10

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

Recommend Documents

Ledenoverzicht

<xsl:value-of select = "Naam/Voornaam" /> <xsl:value-of select = "Naam/Achternaam" />