Universiteit Gent
Faculteit Toegepaste Wetenschappen
Vakgroep Toegepaste Wiskunde en Informatica Voorzitter: Prof. Dr. Ir. G. Crombez
Een Repository met behulp van Java en XML door Rami Hansenne
Promotor: Prof. W. Bossaert Thesisbegeleider (intern): Lic. Andy Georges Thesisbegeleider (extern): Ir. Marc Portier
Scriptie ingediend tot het behalen van de academische graad van Licentiaat Informatica Academiejaar 2000-2001
i
Een Repository met behulp van Java en XML door Rami Hansenne
Scriptie ingediend tot het behalen van de academische graad van Licentiaat Informatica Academiejaar 2000-2001 Promotor: Prof. W. Bossaert Thesisbegeleider (intern): Lic. Andy Georges Thesisbegeleider (extern): Ir. Marc Portier Faculteit Toegepaste Wetenschappen Universiteit Gent Vakgroep Toegepaste Wiskunde en Informatica Voorzitter: Prof. Dr. Ir. G. Crombez
Samenvatting Deze scriptie schetst een raamwerk voor een broncode repository, gemplementeerd met behulp van Java en XML. De repository is in staat om Java broncode-bestanden op te slaan in XML formaat. Gezien het universeel karakter van XML, is dit uiteraard de representatievorm bij uitstek voor het opslaan van data over een potentieel lange termijn. De enorme hoeveelheid XML-tools en applicaties die momenteel verkrijgbaar zijn impliceren reeds een quasi onbeperkt gamma aan mogelijkheden wat betreft verdere opslag, manipulatie en representatie van de opgeslagen gegevens. Broncode bestanden in het bijzonder worden gekenmerkt door sterke relationele verbanden, zowel binnen eenzelfde bestand als tussen bestanden onderling. Hiervoor kan er een beroep gedaan worden op een van de meest krachtige concepten die XML ons biedt: de XML Linking Language. Een repository waarin alle verbanden tussen de opgeslagen data worden beheerd, laat toe om ecient en doelgericht doorheen de mogelijks enorme hoeveelheid gegevens te navigeren. De meest voor de hand liggende mogelijkheden zijn evenwel de stimulatie van hergebruik binnen de onderneming, evenals de a eiding van statistische informatie. Het project omvat meer dan enkel een server-side repository. Er werd tevens een client voorzien die instaat voor de conversie van broncode bestanden naar XML-formaat, de generatie van Javadoc bestanden in XML en het invoegen van links in de resulterende bestanden. Voor de overdracht naar de server werd een WebDAV client ontwikkeld. Aan de server zijde werd een databank voorzien die de verbanden tussen de documenten beheert, evenals een search servlet die toelaat doelgericht te zoeken in de repository en een request servlet die het gevraagde document weergeeft op basis van een stylesheet en de nodige linkconversies in real-time uitvoert. Tenslotte werd een servlet voorzien die in ware tijd statistische data genereert omtrent de inhoud van de repository. Trefwoorden: Java, XML, Repository ii
Dankwoord Mijn oprechte dank gaat uit naar mijn promotor, Prof. Bossaert en mijn thesisbegeleiders, Andy Georges en Marc Portier, die mij geholpen hebben bij het verwezenlijken van dit werk en die steeds de tijd vonden om zich te buigen over mijn probleempjes. Zonder hun opbouwende kritiek, suggesties en aanmerkingen zou dit werk nooit geworden zijn wat het is, waarvoor mijn dank. Verder wens ik ook de mensen van the E-corporation te danken, en in het bijzonder Steven Noels, Erwin Speltinckx, Tom Klaasen, Bruno Dumon en Jan Uyttenhove, die opzoekend werk leverden of hints en tips gaven. Een bijzonder woord van dank gaat tevens uit naar mijn ouders die mij in de eerste plaats de kans hebben gegeven om de studie van informatica aan te vatten en die mij gedurende mijn studies steeds hebben gesteund. Ook de collega-studenten die de laatste vier jaar voor vele mooie herinneringen hebben gezorgd zal ik nooit vergeten. Ten slotte wil ik alle overige personen die op de een of andere manier betrokken waren bij de realisatie van dit werk (vaak van op de andere kant van de globe) bedanken voor hun hulp en steun.
Toelating tot bruikleen De auteur geeft toelating deze scriptie voor consultatie beschikbaar te stellen en delen van de scriptie te kopieren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit deze scriptie.
Rami Hansenne
31-05-2001
iii
Inhoud 1 Inleiding
1.1 Het repository concept . . . . . . . . . . . . . . . . . 1.2 Soorten repositories . . . . . . . . . . . . . . . . . . 1.2.1 CVS . . . . . . . . . . . . . . . . . . . . . . . 1.2.2 RCS . . . . . . . . . . . . . . . . . . . . . . . 1.3 Xanadu { Het linking concept . . . . . . . . . . . . . 1.4 Soorten links . . . . . . . . . . . . . . . . . . . . . . 1.4.1 URI: Uniform Resource Identi er . . . . . . . 1.4.2 URL: Uniform Resource Locator . . . . . . . 1.4.3 URN: Uniform Rescource Name . . . . . . . 1.4.4 URC: Uniform Resource Characteristic . . . . 1.4.5 PURL: Persistent Uniform Rescource Locator 1.5 De nood aan een degelijk link-management . . . . .
2 Terminologie
2.1 XML . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 XML: Extensible Markup Language . . . . 2.1.2 DTD : Document Type De nition . . . . . 2.1.3 XSDL (XML Schema De nition Language) 2.1.4 XML-parsers . . . . . . . . . . . . . . . . . 2.1.5 XSL : Extensible Stylesheet Language . . . 2.1.6 Xlink: XML Linking Language . . . . . . . 2.1.7 XPATH . . . . . . . . . . . . . . . . . . . . 2.1.8 XPointer . . . . . . . . . . . . . . . . . . . 2.1.9 Namespaces . . . . . . . . . . . . . . . . . . 2.1.10 XMI . . . . . . . . . . . . . . . . . . . . . . 2.2 Java . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 Java en XML . . . . . . . . . . . . . . . . . 2.2.2 Parser generators . . . . . . . . . . . . . . . 2.2.3 Servlets . . . . . . . . . . . . . . . . . . . . 2.2.4 J2EE . . . . . . . . . . . . . . . . . . . . . 2.2.5 Enterprise JavaBeans . . . . . . . . . . . . 2.2.6 JDBC . . . . . . . . . . . . . . . . . . . . . 2.3 Distributed Authoring and Versioning . . . . . . . 2.3.1 HTTP . . . . . . . . . . . . . . . . . . . . . 2.3.2 WebDAV . . . . . . . . . . . . . . . . . . . iv
. . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1 2 2 4 5 6 6 7 7 8 9 10
12 12 13 20 22 23 27 32 35 37 40 41 42 43 43 45 47 50 51 54 55 56
2.3.3 Publishing systems: Cocoon . . . . . . . . . . . . . . . . . . . . . . . . 2.3.4 Ant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.5 Doclet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3 Implementatie van een repository
3.1 De applicatie . . . . . . . . . . . . . . . . . 3.1.1 Stimulatie van hergebruik . . . . . . 3.1.2 A eiding van statistische informatie 3.1.3 Extra functionaliteit . . . . . . . . . 3.1.4 De implementatie . . . . . . . . . . .
4 Nabeschouwingen 4.1 4.2 4.3 4.4
Thesisverloop . . . . . . . . . Mogelijke uitbreidingen . . . Open source . . . . . . . . . . Gebruik . . . . . . . . . . . . 4.4.1 De client . . . . . . . 4.4.2 De server . . . . . . . 4.5 De directorystructuur . . . . 4.6 CD-inhoud . . . . . . . . . . 4.7 Overzicht gebruikte software .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . .
59 62 63
67 67 67 68 68 69
93
. 93 . 94 . 95 . 96 . 96 . 98 . 100 . 101 . 102
A Analyse en ontwerp
i
B Afkortingenlijst
i
v
Lijst van Figuren 1.1 1.2 1.3 1.4 1.5
Versiebeheer in CVS . . . . Indeling van de URI's . . . Figuur 1.3: Voorbeeld URC Morbiditeit van webpagina's Wijziging van webpagina's .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
3 7 9 10 11
2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 2.11 2.12 2.13 2.14 2.15 2.16 2.17 2.18 2.19 2.20 2.21 2.22 2.23 2.24 2.25 2.26 2.27 2.28 2.29 2.30 2.31
Een voorbeeld XML-document . . . . . . . . . . . . . . . . . . XSL als data-transformatie . . . . . . . . . . . . . . . . . . . . Voorbeeld DTD . . . . . . . . . . . . . . . . . . . . . . . . . . . Voorbeeld XML-document, conform aan de DTD in Figuur 2.3 Voorbeeld XML-document . . . . . . . . . . . . . . . . . . . . . DTD voor het XML-document in Figuur 2.5 . . . . . . . . . . . XML Schema voor het XML-document in Figuur 2.5 . . . . . . Een voorbeeld XML-document . . . . . . . . . . . . . . . . . . DOM-boom voor het XML-document uit Figuur 2.8 . . . . . . Pointerstructuur van DOM-nodes . . . . . . . . . . . . . . . . . Categorisatie van XML-parsers . . . . . . . . . . . . . . . . . . Skelet van een DOM-client . . . . . . . . . . . . . . . . . . . . . Skelet van een SAX-parser . . . . . . . . . . . . . . . . . . . . . Een voorbeeld stylesheet . . . . . . . . . . . . . . . . . . . . . . De XSL transformatie . . . . . . . . . . . . . . . . . . . . . . . Voorbeeld XSL FO-document . . . . . . . . . . . . . . . . . . . Voorbeeld extended link . . . . . . . . . . . . . . . . . . . . . . Doorloopmogelijkheden extended link . . . . . . . . . . . . . . Voorbeeld XML bestand . . . . . . . . . . . . . . . . . . . . . . Extract uit het meta-model zicht op een klasse in UML . . . . Fasen van een compiler . . . . . . . . . . . . . . . . . . . . . . . Werking van een parser generator . . . . . . . . . . . . . . . . . Vergelijking CGI-scripts en Java servlet . . . . . . . . . . . . . Een three-tier client/server architectuur . . . . . . . . . . . . . J2EE architectuur . . . . . . . . . . . . . . . . . . . . . . . . . Een Enterprise Java Bean in zijn context . . . . . . . . . . . . Enterprise Java Beans binnen de applicatieserver . . . . . . . . JDBC-driver type 1 . . . . . . . . . . . . . . . . . . . . . . . . JDBC-driver type 2 . . . . . . . . . . . . . . . . . . . . . . . . JDBC-driver type 3 . . . . . . . . . . . . . . . . . . . . . . . . JDBC-driver type 4 . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15 18 20 22 24 24 24 25 25 26 27 28 29 30 31 32 34 34 36 42 44 46 47 49 49 51 52 53 53 54 54
vi
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
2.32 2.33 2.34 2.35 2.36 2.37 2.38 2.39 2.40 2.41
De JDBC architectuur . . . . . . . . . . . . . . . . . . . . . . . . Voorbeeld van een HTTP-request . . . . . . . . . . . . . . . . . . Voorbeeld HTTP-response . . . . . . . . . . . . . . . . . . . . . . Antwoord van een WebDAV server bij het plaatsen van een lock Het Cocoon pijplijn model . . . . . . . . . . . . . . . . . . . . . . Voorbeeld sitemap . . . . . . . . . . . . . . . . . . . . . . . . . . Voorbeeld Ant taak . . . . . . . . . . . . . . . . . . . . . . . . . . Oproep Ant-taak in een build-bestand . . . . . . . . . . . . . . . Voorbeeld Ant build bestand . . . . . . . . . . . . . . . . . . . . Voorbeeld Java Doclet . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
55 55 56 60 60 62 64 64 65 66
3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 3.12
Een enkele iteratie uit het spiraalmodel . . . . . . . . . . . . . . . . . Het spiraalmodel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Schema van de top level elementen in het gegenereerde XML-bestand . Onderdeel uit de Java 1.1 grammaticabeschrijving . . . . . . . . . . . De door JTB gegenereerde code uit vorige grammaticabeschrijving . . De door JavaCC gegenereerde code . . . . . . . . . . . . . . . . . . . . Extract uit de DepthFirstVisitor . . . . . . . . . . . . . . . . . . . . . Java2XML conversie . . . . . . . . . . . . . . . . . . . . . . . . . . . . Een elementaire Visitor klasse . . . . . . . . . . . . . . . . . . . . . . . Schema van de creatie van een XML source bestand . . . . . . . . . . Schema van de creatie van een XML Javadoc bestand . . . . . . . . . Extract uit een HTTP-upload pagina . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
70 70 71 72 73 74 75 76 77 77 78 88
4.1 De Java XML vorm van int i . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Mogelijke argumenten bij CLWebdav . . . . . . . . . . . . . . . . . . . . . . .
94 98
vii
. . . . . . . . . .
. . . . . . . . . .
Hoofdstuk 1
Inleiding In deze thesis wordt een raamwerk geschetst voor een broncode repository met behulp van Java en XML. In dit hoofdstuk wordt alvast een inleiding gegeven tot het begrip repository en daaraan gerelateerd, het begrip linking. 1.1
Het repository concept
Een repository biedt een centrale locatie voor de opslag en het onderhoud van een aggregatie van data. De term is afkomstig van het Latijnse `repositorium', wat zoveel betekent als `een kamer waarin dingen kunnen geplaatst (of verzameld) worden'. Afhankelijk van de context kan een repository direct (lokaal) toegankelijk zijn voor de gebruiker, of er kan een vorm van abstractie worden toegepast, zodat de data kunnen worden gedistribueerd over een netwerk, waarbij er een vorm van controle kan worden ingevoerd. Gezien de groeiende populariteit van concepten als `Open Source', neemt het belang aan degelijke repositories toe en kan de term `netwerk' in de vorige zin vaak gesubstitueerd worden door het `Internet'. Termen gerelateerd aan `repository' zijn `data warehouse' en `data mining'. Een data warehouse is een centrale repository voor alle signi cante onderdelen van de data die het business system van een onderneming genereert en verzamelt, vaak georganiseerd in een databank, voor gebruik door analytische applicaties en queries van de gebruiker. Deze repository heeft tot doel het publiekelijk beschikbaar maken van data en het bieden van bescherming aan de opgenomen gegevens. Data mining betreft de analyse van data voor het leggen van op zich niet evidente relaties. Met relaties bedoelt men dan associaties (wanneer een gebeurtenis kan gecorreleerd worden met een andere gebeurtenis), sequenties (waarbij de ene gebeurtenis tot een andere leidt), classi caties, patroonherkenning (en de eventueel daaruit volgende reorganisatie van data), clustering (het vinden en visualiseren van groepen van feiten) en voorspelling (op basis van ontdekte patronen). Het spreekt voor zich dat dergelijke relaties tussen de data in een repository slechts kunnen onderzocht worden, indien er ook bepaalde verbanden tussen de gegevens worden opgeslagen. De meest elementaire vorm is wel het bijhouden van verwijzingen of `links' in en tussen de gegevens. Dit principe is uiteraard niet nieuw en te vergelijken met de hyperlinks waardoor een gebruiker doorheen de gigantische informatieruimte die het Internet voorstelt, kan navigeren. 1
Dit navigeren is immers ook niets meer dan het zoeken en volgen van verbanden. Deze de niering van verbanden biedt een grote vrijheid, daar er geen volgorde wordt opgelegd aan het doorlopen van de informatie. In sectie 1.3 wordt iets dieper ingegaan op het ontstaan van het hyperlinking concept. 1.2
Soorten repositories
Er bestaan reeds tientallen types repositories, elk vaak toegelegd op enkele speci eke doeleinden. Hieronder worden kort de twee bekendste types repositories voor opslag en beheer van broncode-bestanden besproken: CVS en RCS.
1.2.1 CVS CVS staat voor `Concurrent Versioning System', een versiebeheer systeem. CVS wordt aangewend om de geschiedenis van broncode-bestanden bij te houden. Dit kan een grote hulp zijn bij het debuggen of het proberen ongedaan maken van een eerder aangebrachte verandering. Het is in principe natuurlijk mogelijk om elke versie van elk bestand ooit gemaakt bij te houden, maar dit zou een enorme hoeveelheid schijfruimte opeisen en de overzichtelijkheid zeker niet ten goede komen. CVS slaat alle versies van een zelfde bestand e ectief op in een enkel bestand. Hierbij wordt enkel de nale versie bewaard, tezamen met de verschillen (delta's) ten opzicht van elk van de vorige versies. Op die manier kan elke versie opnieuw worden gereconstrueerd, indien dit vereist zou zijn. Backtracking is dus steeds mogelijk. CVS kan eveneens van nut zijn wanneer meerdere mensen aan eenzelfde project werken. In zo'n geval is het niet ondenkbaar dat een ontwikkelaar onbewust de aanpassingen aangebracht door een collega overschrijft. Bepaalde editors, zoals GNU Emacs, zijn erop voorzien om dergelijke problemen te voorkomen. Wanneer echter sommige ontwikkelaars een andere editor gebruiken, kunnen er nog steeds problemen ontstaan. CVS lost deze potentiele problemen op door de ontwikkelaars van elkaar te insuleren. Elke ontwikkelaar werkt lokaal in zijn eigen directory en pas wanneer hij of zij gedaan heeft, zal CVS alle versies samenvoegen. CVS ontstond als een verzameling shell scripts, maar later werd er een module ontwikkeld die nu vrij verkrijgbaar is. CVS biedt dus een groot aantal voordelen, maar kan de ontwikkelaar niet op elk domein bijstaan: CVS is geen ontwikkelsysteem. De structuur van de repository en modules wordt niet
beheerd door CVS. CVS geeft nergens aan hoe een systeem moet gebouwd worden, het handelt enkel de opslag van bestanden in een boomstructuur af. Er worden ook geen vereisten opgelegd met betrekking tot het gebruik van make les (bv. relatieve versus absolute directories). Er zijn dus andere tools die de ontwikkelaar hierbij kunnen helpen en uiteraard kunnen deze tools zelf wel onder CVS worden opgeslaan bij de code (scripts, make les,. . . ).
Men kan CVS niet gebruiken als een substituut voor management. De ontwikkelaar
is zelf verantwoordelijk voor de planning. CVS is hierbij slechts een instrument. CVS is ook niet in staat om te bepalen wanneer simultane aanpassingen binnen eenzelfde 2
bestand of over een collectie van bestanden logisch met elkaar zullen con icteren. Met andere woorden, CVS is zich niet bewust van de inhoud van de broncodebestanden of zelfs de taal waarin ze zijn geschreven. Enkel de externe opslagstructuur en de opeenvolgende versies van een zelfde bestand worden gecontroleerd. CVS is tenslotte ook geen con guratiebeheer systeem. Er wordt dus geen hulp geboden
bij activiteiten als source control, dependency tracking, bug tracking, geautomatiseerde testprocedures, installatie of de mogelijkheid om verschillende versies van dezelfde software tegelijkertijd te laten lopen op dezelfde host.
CVS slaat alle bestanden op in een gecentraliseerde repository; een directory bevolkt met een hierarchie van bestanden en directories. Het is normaal gezien niet mogelijk om directe toegang te verkrijgen tot deze bestanden. Via CVS commando's kan je een eigen kopie aanvragen van de gewenste bestanden. De bestanden binnen de repository zijn opgedeeld in modules, elk bestaande uit een of meerdere bestanden, eventueel verdeeld over verschillende directories. Over het algemeen wordt er een module per project toegewezen. Elke versie van een bestand beschikt over een uniek revisienummer, beginnende vanaf `1.1'. CVS is niet beperkt tot lineaire ontwikkeling. De revisieboom kan opsplitsen in verschillende takken, die elk een eigen ontwikkelingslijn vormen. Elk van deze takken krijgt een eigen nummer.
Figuur 1.1: Versiebeheer in CVS Het ophalen van een versie gebeurt met het `checkout' commando en een nieuwe versie uploaden gebeurt via `commit'. Tenslotte kan je de lokale kopie opruimen met `release'. Via het `di ' commando kan je de verschillen opvragen tussen de opgehaalde versie en de huidige versie. Uiteraard kent CVS nog veel meer opties en dan vooral op administrategebied.
Voorbeeld 1.1. Enkele CVS opdrachten worden hier getoond. Om een kopie van de module `example' af te halen:
$ cvs checkout example
3
Om een kopie van de module `example' af te halen, zoals die er een dag geleden uitzag:
$ cvs checkout --D yesterday example Wanneer meerdere personen werken aan dezelfde software, kan een developer zijn wij-
zigingen toekennen aan een aparte tak (branch) om zo con icten te voorkomen: $ cvs tag -b module1 $ cvs update -r module1 $ cvs commit
Om de verschillen tussen 2 versies van een bestand op te vragen:
$ cvs diff -kk -u -r 1.01 -r 1.23 example.c Om een lokale kopie op te ruimen:
$ cvs release -d example
1.2.2 RCS CVS steunt op een verzameling utilities op een lager niveau, genaamd RCS of `Revision Control System'. Het is mogelijk om enkel met RCS te werken, maar de CVS uitbreiding is veel krachtiger en laat toe om operaties uit te voeren op een volledige broncode boom. Het is tevens makkelijker om de werking van CVS aan te passen aan je eigen noden, via scripting talen, zoals Perl. Voordelen van RCS: RCS is heel simpel in gebruik en vereist weinig administratie. RCS kan gebruikt worden in een gecentraliseerd gebied waar alle projectleden werken. RCS is makkelijk bruikbaar voor simpele systemen. Strenge locking van bestanden is voorzien, zodat concurrency (gelijktijdigheid) volledig
wordt uitgesloten.
Nadelen van RCS: Gelijktijdige ontwikkeling door verscheidene ontwikkelaars is niet mogelijk door het feit
dat een lock wordt geplaatst op een bestand of een enkele werkdirectory. 4
Het is niet mogelijk een stamp te plaatsen op een volledige release bestaande uit
meerdere bestanden en directories.
Ter vergelijking volgen hierna de voor- en nadelen van CVS: Voordelen van CVS: CVS is gedecentraliseerd. De gebruiker kan bestanden en directories ophalen uit de
repository en beschikt over een eigen stabiele broncodeboom.
CVS kan een `stamp' plaatsen op releases van een complete broncode boom. CVS laat gelijktijdige aanpassing van bestanden toe. CVS kan makkelijk aangepast worden om bijvoorbeeld sterke locking van bestanden of
simultane aanpassing van bestanden toe te laten via shell scripts of Perl.
Nadelen van CVS: Er is iets meer administratie vereist dan voor RCS. Het is een heel geso sticeerd en complex systeem dat gebruik maakt van `state-of-the-
art' technologie.
CVS voorziet een indrukwekkend groot aantal commando's en opties. De leercurve ligt
dus redelijk hoog voor beginners. Het gebruik van shell scripts kan het een en ander wel wat vereenvoudigen.
1.3
Xanadu { Het linking concept
Hoewel de uitvinding van het World Wide Web, zo'n twaalf jaar geleden, werd toegeschreven aan Tim Berners-Lee, is het concept `hyperlink' reeds een heel stuk ouder. In de jaren '40 voorspelde Vannevar Bush de opkomst van de digitale fotogra e, stemherkenning en personal computers die toegang zouden hebben tot een hypertekst databank. In plaats van de term hypertekst, gebruikte Bush de naam `associatieve sporen', maar het concept was essentieel hetzelfde. Bush's artikel `As we may think' [26] inspireerde Douglas Engelbart er toe om een on-line hypertekst systeem op te zetten met kruisreferenties tussen alle documenten in een workspace, gedeeld door gebruikers op verschillende locaties. Het zogenaamde `Project Xanadu', gestart in 1960 door Ted Nelson, was echter nog een stuk ambitieuzer. Hier mikte men op niets minder dan een `docuverse', een universum van documenten waarbij alle geschriften werden gelinkt en gerefereerd en waar niks kon verwijderd worden. Eens iets werd gepubliceerd, zou het eeuwig blijven bestaan, inclusief alle links en referenties. Bovendien was er toen reeds sprake van concepten als bidirectionele links, versiebeheer en linkbeheer. Men zou dus kunnen spreken van de ultieme repository, al kan deze met de huidige technologie helaas nog niet worden gemplementeerd. Xanadu is bijgevolg een algemeen paradigma, een ideaalbeeld en een model voor alle computergebruik, gebaseerd op zijdelingse connectiviteit van documenten en bestanden. Het 5
paradigma richt zich voornamelijk op elektronische publicatie, maar kan evengoed worden toegepast op elke vorm van opslag en presentatie van informatie. Het is een uni cerend systeem dat orde biedt aan alle erin opgeslagen informatie, zonder een hierarchie te introduceren. Men zou hier kunnen spreken van een universele, elektronische bibliotheek. Bovendien moet de creatie, manipulatie en toegang gebeuren op een manier die goedkoop en betrouwbaar is en tevens veiligheid biedt. Hiermee wordt bedoeld dat de documenten dienen beschermd te worden tegen elke vorm van verlies, beschadiging, aanpassing, censuur, copiering of verwijdering die niet wordt toegestaan door de auteur. 1.4
Soorten links
Het World Wide Web (WWW) verspreidde voor het eerst het hypermedia paradigma over de \wijde" wereld. De combinatie van een eenvoudige point-and-click interface, inline graphics en een globale bereikbaarheid inspireerden zowel computerexperten als leken. De idee achter het Web is een hypertext navigatie paradigma, geplaatst in een gedistribueerde omgeving, waarbij links uit tekstuele documenten verwijzen naar andere documenten, die zich niet noodzakelijk op dezelfde fysische locatie bevinden. Het URL mechanisme (zie 1.4.4) voorziet een syntax voor de universele adresruimte, HTML zorgt voor een platform-onafhankelijk dataformaat en het HTTP-protocol levert een platform-onafhankelijk client/server-systeem. Vanuit het perspectief van de gebruikersinterface is de meest gebruikte vorm van navigatie nog steeds de hypertext link. Zelfs de eenvoudigste webbrowsers voorzien ondersteuning voor het navigeren aan de hand van deze links: de zogenaamde `breadcrumbs', een speciale inkleuring van eerder gevolgde links, een geschiedenislijst van reeds bezochte links, de mogelijkheid tot backtracking en bookmarking, enz. Deze vorm van linking is misschien wel eenvoudig implementeerbaar, maar heeft ook een groot aantal beperkingen. Eigenlijk is de mogelijkheid gewenst om de links te onderhouden (via een linkbase), te linken vanuit read-only documenten en naar binaire documenten, evenals het invoeren van bidirectionele links, de niering van toegangsrechten en toekomstige uitbreidbaarheid. Zoals zal blijken, werden reeds een groot aantal van deze mogelijkheden voorzien in het xlink concept. Een verdere limitatie is het feit dat een URL de fysische locatie van een document aanwijst in plaats van de identiteit ervan; de locatie van een document kan immers wijzigen in de tijd. Het is tenslotte ook nodig om een zekere vorm van standaardisatie in te voeren voor de opslag van meta-data zoals auteur, eigenaar, titel, grootte, data, enz. De URL is evenwel niet de meest algemene linkvorm en er zijn linktypes die reeds een aantal van deze standaardisaties vastleggen. Het meest algemene linktype hierbij is de URI.
1.4.1 URI: Uniform Resource Identi er Een URI is de algemene naam voor een locator die een welbepaald document op een netwerk aanduidt. Meer bepaald beschrijft een URI het mechanisme om een connectie met het doel op te zetten, de speci eke computer waarop het document is gelocaliseerd en de naam van het bestand op die computer. Twee categorieen van URI's zijn de URL's en URN's.
6
Figuur 1.2: Indeling van de URI's
1.4.2 URL: Uniform Resource Locator De meest gebruikte en best bekende vorm van locator is ongetwijfeld de URL. Een URL identi ceert netwerk-toegankelijke documenten op basis van een schema, host en pad. De meest algemene vorm is: <schema>://
:<paswoord>@:<poort>/<pad>
Voorbeeld 1.2. Beschouw de volgende URL: ftp://johndoe:[email protected]:21/users/public/doc.xml
Hiermee wordt het document `doc.xml', in het pad `/users/public' op de server met hostnaam `ftp.voorbeeld.com', opgevraagd via het File Transfer Protocol, met gebruikersnaam `johndoe' en paswoord `mypass'. Loginnaam en paswoord en pad zijn hierbij optioneel. Als schema-naam zijn ook mogelijk: http, nntp, gopher, news, mailto, le, . . .
1.4.3 URN: Uniform Rescource Name Hierbij hecht men een persistente naam aan een document, in plaats van aan het adres van dat document (zoals bij een URL). De URN standaard werd nog niet vastgelegd, maar het doel is het creeren van wereldwijd unieke, locatie-onafhankelijke en persistente referenties naar webdocumenten. De syntax van een URN zal de volgende zijn: urn:< Namespace Identifier>:
Men streeft ernaar onder andere deze eigenschappen te implementeren bij het de nieren van een standaard voor URN: 7
Globaal: Een URN moet een naam zijn die wereldwijd toegankelijk is en geen speci eke
Uniciteit: Een URN mag nooit toegewezen worden aan twee verschillende bronnen.
Persistentie: De levensduur van URN dient minimaal dezelfde te zijn als die van het
Schaalbaarheid: Een URN moet toekenbaar zijn aan elke mogelijke vorm van een
Ondersteuning: Het schema dient reeds bestaande benoemingssystemen te ondersteu-
Uibreidbaarheid: Een URN-schema moet toekomstige uitbreidingen toelaten.
locatie impliceert. Het dient overal dezelfde betekenis te hebben.
document waarnaar verwezen wordt. URN's blijven dus wereldwijd uniek, ook na het verdwijnen van het geassocieerde document. document dat over een netwerk beschikbaar gesteld kan worden (dus ook foto's, videobeelden, geluidsbestanden, etc.) nen, voor zover zij voldoen aan de andere criteria.
De name identi ers worden door een gecentraliseerde dienst onderhouden en toegekend. Op basis van de namespace vastgelegd door de name identi er kunnen organisaties vervolgens zelf verdere onderverdelingen maken door het toekennen van namespace speci c strings. Uiteraard moet de uniciteit ook bij deze onderverdeling blijven gelden. Op basis van een URN kan vervolgens aan de gecentraliseerde dienst de bijbehorende URL of URC opgevraagd worden. Omwille van het feit dat de syntax niet conform is met die van de URL vergt het URN-systeem wel degelijk een aanpassing van de applicaties; dit in tegenstelling tot PURL's (zie 1.4.5).
1.4.4 URC: Uniform Resource Characteristic Een URC is een combinatie van een URL, URN en eventuele andere identi cators voor een webdocument. Er bestaan verschillende versies:
Whois++URC: Samenstelling van tenminste twee attributen, waaronder een unieke
Trivial URC: Omvat enkel een URN en een of meer URL's en dus geen additionele
SGML URC: Bestaat uit een trivial URC in combinatie met een SGML DTD (zie
URN, een of meerdere URL's (bv. mirrors) alsook informatie omtrent de data (type, taal, lengte,. . . ). databeschrijving.
2.1.2). Hierbij wordt de DTD, die informatie biedt over de documentelementen, erg simpel gehouden.
8
johnsdoc113 John Doe Een voorbeeld document <subject scheme="abstract"> Dit document behandelt de verschillende soorten locators. Link management http://www.link.com Linking in XML http://www.xmllink.com
Figuur 1.3: Figuur 1.3: Voorbeeld URC
1.4.5 PURL: Persistent Uniform Rescource Locator PURL's verwijzen niet rechtstreeks naar het doeldocument, maar naar een intermediaire server die op basis van een databank de correcte URL teruggeeft aan de client. Die URL kan dan op de gewone manier door de client worden aangewend. De PURL de nieert dus een extra niveau van indirectie.
Voorbeeld 1.3. Een PURL is bijvoorbeeld: http://purl.oclc.org/OCLC/OLUC/32127398/1
Een PURL is dus eigenlijk niets meer dan een gewone URL. Het \purl.oclc.org" gedeelte geeft de resolver aan, de dienst die voor de resolutie van de client-request zorgt. Uiteraard moet dit een betrouwbare en permanente dienst zijn. Het gedeelte erna laat de resolver toe om de gewenste URL op te zoeken in de databank. Wanneer nu de locatie van een document verandert dient men enkel het voorkomen in de databank aan te passen. Alle reeds bestaande links naar dat document (op basis van een PURL) zullen bijgevolg na een verandering nog steeds het correcte document aanwijzen. In feite gaat het dus om een zogenaamde URL-alias, maar dan wel op basis van een gecentraliseerde en betrouwbare dienst. Het blijft evenwel nog steeds de taak van de eigenaar van een document om de PURL-resolver ervan op de hoogte te brengen wanneer de locatie van zijn document verandert. Indien dit niet gebeurt en iemand vraagt een PURL op geassocieerd met een dode link, dan wordt een pagina teruggestuurd met de geschiedenis van de betre ende PURL (alle URL's die er ooit eens aan geassocieerd waren, tezamen met enige administratieve informatie). 9
Een bijkomend voordeel van PURL's is net het feit dat het om een gewone URL-vorm gaat. Bijgevolg dient er geen aanpassing te gebeuren aan browsers en applicaties, vermits de syntax gelijk blijft aan die van een URL. PURL's kunnen dus vandaag de dag reeds worden aangewend. Dit in tegenstelling tot de URN die een alternatieve syntax introduceert. 1.5
De nood aan een degelijk link-management
Gezien de locatie-georienteerdheid van de URL is er wel degelijk nood aan een vorm van link management. Dit blijkt nog maar eens uit de studie in deze paragraaf. Om het probleem van de dode links aan te pakken dient een centrale databank (linkbase) te worden gede nieerd, die alle erin opgenomen links op regelmatige tijdstippen veri eert en up to date brengt. Er bestaan reeds vele voorstellen voor een dergelijk systeem, maar de meeste zijn websitegeorienteerd en dus niet globaal over het hele Internet. In de volgende gra eken wordt het gedrag (wijzigingen en levensduur) getoond van 360 willekeurig gekozen webdocumenten (wereldwijd), op basis van een onderzoek door de Universiteit van Oaklahoma [18]. Het gaat dus om een vrij kleine steekproef, maar groot genoeg om een idee te krijgen over de levensduur en het aantal veranderingen van de documenten en hun interne links.
Figuur 1.4: Morbiditeit van webpagina's Figuur 1.4 geeft de gemiddelde levensduur van webpagina's weer in een tijdsinterval van drie jaar. De lijnen tonen het aantal webpagina's weer die na drie pogingen niet resolveren. 10
Figuur 1.5: Wijziging van webpagina's De ene geeft het e ectief aantal aan, de tweede het zeswekelijks gemiddelde. Het valt op dat het aantal 'verdwenen' webpagina's aanvankelijk lineair stijgt. Na verloop van tijd (ca. twee jaar) lijkt er wel een grotere stabiliteit in te treden. Sommige webpagina's keren bovendien na verloop van tijd terug. Omdat de aard van de 404-foutboodschappen wijzigde van enkele lijnen naar soms erg lange boodschappen kunnen er ook wel kleine meetfouten opgetreden zijn in de test (foutboodschappen die genterpreteerd werden als webpagina's). Op Figuur 1.5 wordt het gemiddeld aantal wijziging van de webpagina weergegeven in functie van de tijd. De bovenste curve duidt de verandering in aantal bytes aan. Dit is uiteraard slechts een ruwe benadering van het al dan niet wijzigen van de inhoud van een webdocument. De inhoud kan immers veranderen, zonder dat de grootte verandert (vooral dan bij kleine aanpassingen). De volgende twee lijnen geven het aantal nieuwe links of wijzigingen aan bestaande links aan. In ongeveer 20% van de documenten wordt de linkinhoud gewijzigd en zo'n 10% (van het totaal) ondergaan linkwijzigingen op een wekelijkse basis. Men kan besluiten dat er wel degelijk nood is aan een ecienter link management wil men het aantal `404'-boodschappen inperken. Dit zou kunnen gerealiseerd worden door een centraal beheer (controle en update) van de linkspace en/of een dynamische link-generatie.
11
Hoofdstuk 2
Terminologie In dit hoofdstuk wordt nader ingegaan op de termen en concepten die verband houden met de ontwikkeling van de XML repository. Dit omvat vooreerst uiteraard de Extensible Markup Language zelf, evenals de gerelateerde termen, zoals XSL, Xlink, DTD en XSDL (XML Schema De nition Language). Nadien worden de Java-concepten besproken die nodig zijn om de repository te implementeren. Hier komen onder andere Java servlets en Enterprise Javabeans aan bod. Tenslotte komt het WebDAV-protocol voor distributed authoring aan bod, evenals de benodigde client/server architectuur. 2.1
XML
Het creeren van een repository van HTML-bestanden, geoptimaliseerd voor het web zou ongetwijfeld voor problemen zorgen. Vooreerst voorziet HTML geen standaard layout, font of formattering voor reproductie op papier. Bijgevolg zou men slechts een subset van de HTMLmogelijkheden mogen aanwenden of de printmogelijkheden aanpassen wil men een repository ontwerpen in HTML. Zoniet, zal men verplicht worden om elk document twee maal te creeren: een voor het on-line bekijken en een om in afgedrukte vorm op te vragen. Dit is maar een simpel voorbeeld van de problemen die een HTML repository zou teweeg brengen. Auteurs zullen tevens niet over de mogelijkheid beschikken om componenten van een document te identi ceren en zo gespecialiseerde zoekopdrachten toe te laten of een speci eke formattering toe te kennen. Ook het opleggen van business rules aan de structuur en inhoud van een document is eenvoudiger te realiseren bij XML. Hoewel de waarde van XML-gebaseerde content management systemen toeneemt met het aantal auteurs en de complexiteit van de documenten, zal in dit hoofdstuk blijken dat zelfs een kleine auteursgroep een wezenlijk voordeel kan halen uit een XML-oplossing. Enkele belangrijke voordelen van een repository betre en standaardizatie van documenten, pro lering en mogelijkheid tot groei. XML voorziet een natuurlijke structuur om te verzekeren dat alle documenten voldoen aan bepaalde richtlijnen, zoals opgelegd door het bedrijf, door het gebruik van DTD's en schema's. Voor wie nog niet bekend is met al deze termen aangaande XML, volgt eerst een korte introductie.
12
2.1.1 XML: Extensible Markup Language XML [6] ontstond in een poging om SGML1 -documenten op een eenvoudige manier op het world-wide web te publiceren, zonder al te veel van de voordelen van het SGML-formaat te verliezen. XML werd dan ook een subset van SGML. Bovendien laat XML een veel hoger niveau van structurele en stylistische aanpassingen toe dan traditionele HTML. Het laat toe om data zo te structureren, dat ze makkelijker te manipuleren zijn en tussen applicaties uitgewisseld kunnen worden. In het volgende onderdeel wordt dieper ingegaan op de essentiele verschillen tussen HTML en XML.
XML versus HTML Markup talen gebruiken tags om aan te duiden dat bepaalde onderdelen van de tekst een speciale betekenis hebben en dat deze door de applicatie die de documenten verwerkt op een speci eke manier dienen genterpreteerd te worden. De Hypertext Markup Language of HTML de nieert hiertoe een vast aantal tags met een welbepaalde betekenis. Het hoofddoel van HTML was immers het coderen van tekst voor weergave aan de gebruiker.
Voorbeeld 2.1. Enkele voorbeelden van HTML tags: . . .
duidt een structuurelement aan, in dit geval een koptekst. . . . duidt aan dat de tekst ertussen gecentreerd dient te worden. . . . geeft aan dat de tussenliggende tekst in vet moet worden weergegeven. 
laat de browser weten dat er op die plaats een beeld moet ingevoegd
worden.
HTML is dus uitermate geschikt voor de weergave van beperkte hoeveelheden tekst en beelden, maar is omwille van de vaste tags weinig exibel. Hieronder volgen enkele voordelen van HTML: Vooreerst is HTML erg eenvoudig om te leren en te gebruiken. Bovendien bestaan
er tegenwoordig talloze applicaties die toelaten om HTML-documenten te creeren met behulp van een gra sche interface, zonder ooit een HTML-begrip te kennen. Deze applicaties genereren zelf de vereiste HTML-code volgens het WYSIWYG- principe (What You See Is What You Get). Uiteraard heb je dan als gebruiker natuurlijk minder controle over wat er werkelijk wordt geproduceerd (bijvoorbeeld de meta-tag informatie, interne HTML-structuur,. . . ), enkel over hoe het er in een browser zal uitzien.
1
SGML of Standard Generalized Markup Language is een complexe meta-taal die voornamelijk werd
aangewend voor het gestructureerd opslaan van documenten die grote hoeveelheden data bevatten (bv. onderhoudsdocumenten voor vliegtuigen).
13
HTML is een enorm populaire mark-up taal (vooral omwille van het hyperlinking con-
cept) en bijgevolg gemakkelijk overdraagbaar. Omdat er met tags wordt gewerkt die een vaste betekenis hebben is het makkelijk parsers te ontwerpen die HTML-documenten correct weergeven. Elke browser kan elk HTML-document weergeven zoals de ontwerper het heeft bedoeld (althans, dat zou zo moeten zijn); iets dat niet kan gezegd worden van talen die custom tags toelaten, waarmee een algemene parser weinig kan aanvangen.
Hoewel HTML op zich niet zo'n krachtige taal is, laat het toe om krachtigere `actieve e-
lementen' in het document te incorporeren, zoals Java applets en ActiveX-componenten.
Zoals reeds vermeld kent HTML ook enkele nadelen: HTML de nieert enkel standaard tags die door parsers kunnen genterpreteerd worden.
Het is evenwel niet mogelijk om zelf nieuwe tags in te voeren. HTML is met andere woorden niet uitbreidbaar (althans niet door de gebruiker).
Het doel van HTML was en is nog steeds het uitwisselen van data tussen mensen, met
de nadruk op de presentatie ervan. HTML is bijgevolg niet geschikt om data uit te wisselen tussen machines voor geautomatiseerde dataverwerking.
Ook op het gebied van linking heeft HTML zijn tekortkomingen, die voor het overgrote deel door XML worden opgevangen. De oplossingen hiervoor zullen besproken worden in de paragraaf over XLink. Vele van de nadelen van HTML zouden vermeden kunnen worden door SGML aan te wenden, maar deze taal is bijzonder uitgebreid en complex, zodat SGML niet doelgericht te gebruiken is in de meeste applicaties. Vandaar werd de XML, een gesimpli ceerde en strikte subset van SGML, uitgedacht die eveneens toelaat om met gebruiker-gede nieerde tags te werken (vandaar de eXtensible in XML) en bovendien de validatie-, extensibiliteit- en structuureigenschappen van SGML overerft.
Eigenschappen van XML De hoofdeigenschappen van XML betre en extensibiliteit, structuur en validatie:
Extensibiliteit': Dankzij de mogelijkheid om nieuwe tags en attributen te speci eren
Structuur: Documenten zijn in feite containers van elementen, genest volgens wel-
Validatie: XML laat toe om voor elk document of klasse van documenten een strikte
kunnen gebruikers een bijkomende syntax- en semantiek vastleggen voor hun documenten en applicaties. bepaalde structuurregels. Deze regels laten toe om op een eenvoudige manier speci eke elementen te lokaliseren of manipuleren. Ook complete structuurhervormingen worden een stuk eenvoudiger.
beschrijving op te stellen van de structuur waaraan moet voldaan worden. Applicaties kunnen op die manier nagaan of een document wel conform is met zijn structuurbeschrijving of DTD. 14
1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 12. 13. 14. 15.
<-- Quiz by John Doe --> <Wiskunde> Wat is de vierkantswortel uit 169? 13 Tot welk land behoort het eiland Rhodos? Griekenland } }
Figuur 2.1: Een voorbeeld XML-document XML beschrijft documenten als een klasse van data-objecten en legt eveneens gedeeltelijk het gedrag vast van applicaties die het document zullen verwerken. Op deze manier kan doelgericht gezocht worden naar speci eke componenten binnen een document. Vermits evenwel iedereen zijn eigen tags kan de nieren is het nodig om tevens een schema op te stellen dat de applicatie laat weten op welke manier de elementen tussen de tags genterpreteerd dienen te worden.
Onderdelen van een XML-document Hierna volgt een bespreking van de belangrijkste onderdelen van een XML-document, op basis van Figuur 2.1.
Elementen: Dit is de meest voorkomende vorm van make-up (bv. lijn 4). Elementen geven
de aard aan van hetgeen ze omsluiten. Indien elementen een inhoud hebben bestaan ze steeds uit een begin- en eind-tag. Elementen kunnen eveneens leeg zijn. In dat geval kunnen ze uit een enkele tag bestaan, van de vorm <elementnaam/> (bv. lijn 13). Lege elementen zijn bijvoorbeeld handig om een speci ek punt in een document aan te duiden. De inhoud van een element hoeft niet louter tekstueel te zijn. Elementen kunnen andere elementen omsluiten (maar niet overlappen), zoals in lijnen 4 tot 7.
Attributen: Een attribuut is een naam-waarde paar dat voor kan komen in een element-
tag en bijkomende informatie levert in verband met dat element; bijvoorbeeld het attribuut moeilijkheidsgraad in lijn 3. De waarde staat steeds tussen aanhalingstekens.
15
Commentaar: Commentaar in een XML-document begint met '' (bv. lijn 2). Commentaar dient uitsluitend voor de menselijke lezer en wordt over het algemeen niet verwerkt door de XML-parser.
Verwerkinginstructies Data van de vorm '' wordt door de parser gewoon doorgegeven aan de applicatie die er al dan niet iets mee kan aanvangen, afhankelijk van het feit of de tag voor de betre ende applicatie is bedoeld (bv. lijn 14). CDATA-secties Tekst binnen een CDATA-tag wordt letterlijk doorgegeven aan de applicatie zonder te onderzoeken op entiteitreferenties (zie onder) of enige vorm van verwerking. Dit kan handig zijn wanneer het noodzakelijk is om speciale of gereserveerde tekens of lettercombinaties op te nemen in een tekst en in het bijzonder wanneer mark-up wordt toegevoegd die letterlijk genterpreteerd dient te worden.
Voorbeeld 2.2. = 7); *x = \& y; ]]> ]]>
Entiteiten en entiteitreferenties Bepaalde tekens zijn gereserveerd, zoals <, >, &, ' en ". Om deze te gebruiken kan men gebruik maken van entiteitreferenties, zoals: < voor < > voor > ' voor ' " voor " & voor &
De referentienamen staan dus steeds tussen '&' en ';'. Het is ook mogelijk om zelf referenties te de nieren, zoals bijvoorbeeld een stukje tekst dat vele malen doorheen het document zal gebruikt worden. 16
Voorbeeld 2.3.
Dit kan nu gewoon worden opgeroepen d.m.v. `&tekst;'. Het is trouwens ook mogelijk om referenties in te voegen naar andere documenten (externe entiteiten) en bovendien hoeft het niet steeds om zuivere tekst te gaan zoals het volgende voorbeeld illustreert:
Voorbeeld 2.4.
kan opgeroepen worden als
XML en Unicode De Unicode standaard de nieert een universele karakterset en heeft als primair doel het ondubbelzinnig coderen van platte tekst, ongeacht de taal. Momenteel bevat deze standaard (3e versie) karakters voor de meest gebruikte geschreven talen. Bovendien werden tevens karakters opgenomen voor interoperabiliteit met oudere encoderingen en controle-functies. In vele gevallen biedt mark-up gelijkaardige mogelijkheden als de formatteringskarakters in Unicode voor platte tekst. Vandaar dat XML soms de Unicode van de 21ste eeuw wordt genoemd. Wat de Unicode compatibiliteitskarakters betreft kunnen er evenwel con icten optreden met de mark-up regels. De manipulatie van beide vormen is natuurlijk erg verschillend, vermits Unicode lineair wordt geencodeerd, terwijl XML een hierarchische (boom-)structuur de nieert voor de tekst. Daarnaast biedt het gebruik van mark-up nog enkele voordelen, zoals uitbreidbaarheid (in tegenstelling tot het gebruik van vaste controlekarakters) en de mogelijkheid om de tekstweergave aan te passen, zonder de gecodeerde inhoud te veranderen. Tenslotte is er nog het probleem van de ambiguteiten tussen controlekarakters en mark-up. Vaak bestaan er immers equivalenten en wanneer beiden aanwezig zijn in eenzelfde tekst rest nog de vraag welke prioriteit heeft.
Praktisch gebruik Ondanks het wijd verspreid gebruik van XML, hebben bepaalde bedrijven en ontwikkelaars nog steeds de indruk dat XML een trendverschijnsel is dat nog niet klaar is voor de heavy-duty kritische applicaties waarop ze vertrouwen. Ondanks het feit dat de bekendheid van XML sneller groeide dan zelfs Java, is niets minder waar. In combinatie met Java is het perfect mogelijk om portabele applicaties (en data) te ontwikkelen van industriele sterkte.
17
Figuur 2.2: XSL als data-transformatie
XML voor communicatie XML is het middel bij uitstek voor de uitwisseling van data tussen applicaties. Dit is makkelijk te realiseren vermits XML niet is gebonden aan een client. Het gaat hier bovendien om een eenvoudige voorstelling van data, makkelijk uitwisselbaar over een netwerk. Het gaat immers om platte tekst, dus licht-gewicht, makkelijk serializeerbare data (al vormen de meta-tags in bepaalde gevallen uiteraard een aanzienlijke overhead). In deze context is een client meer dan het zicht dat een gebruiker heeft op een applicatie. Het kan immers eveneens gaan om databanken, ingebedde systemen of zelfs call-backs van de applicatie zelf. Een client heeft dus niet noodzakelijk een visuele presentatielaag nodig. Niettemin kan het nog steeds zijn dat er een transformatie van de XML data dient uitgevoerd te worden. XSL-transformaties (2.1.5) worden dus niet enkel aangewend voor het leveren van een zicht op de data aan de client. De XSL stylesheet kan bijvoorbeeld worden gebruikt om bepaalde data uit een XML-document te lteren, of om een document conform te maken aan de DTD die door een andere applicatie wordt verstaan. Het resultaat blijft in zo'n geval dus een XML-bestand. Dit maakt XML nu net zo'n krachtig concept. Twee heterogene applicaties kunnen data uitwisselen met elkaar, ook al werken ze elk met een andere interne representatie. Het gebruik van XML kan dus de interne communicatieproblemen van verschillende applicaties helpen oplossen.
XML voor presentatie Het meest populaire gebruik van XML ligt nog steeds in het scheiden van inhoud (de data die dienen weergegeven te worden) en presentatie (de formattering van die data). Dit houdt in dat de data uniform dienen te zijn doorheen de applicatie, ongeacht het type client waarvoor ze zijn bestemd. De presentatie daarentegen is direct afhankelijk van het type client en zijn mogelijkheden (HTML, WML, Swing,. . . ). XML wordt gebruikt voor de opslag van data, terwijl XSL en XSLT de correcte presentatie verzorgen. Gezien de grote diversiteit aan besturingssystemen en clients die tegenwoordig internetmogelijkheden hebben, is het noodzakelijk om de data-representatie aan te passen aan de mogelijkheden van de client (GSM's en organizers met ondersteuning voor WML of Wire18
less Markup Language bijvoorbeeld). Het is natuurlijk mogelijk om verschillende versies van een programma te creeren voor elk type client, maar dit impliceert natuurlijk een serieuze overhead en potentiele update- en compatibiliteitsproblemen, vooral dan wanneer er in de toekomst nieuwe soorten clients kunnen bijkomen. Hoewel XML zelf geen presentatietechnologie is, kan het wel gebruikt worden om een presentatielaag te genereren. HTML is anderzijds wel een presentatie-technologie, maar biedt onvoldoende exibiliteit om als datarepresentatie laag te worden gebruikt. Gezien de strikte structuur van een XML-document, opgelegd door een DTD of XML schema, kan XML makkelijk worden gemanipuleerd. XSL laat toe om de wijze van presentatie te de nieren, met behulp van formatteringsinstructies die betrekking hebben op de data in een XML-document. Via XSLT kan het originele XML document vervolgens op heel wat verschillende manieren worden weergegeven aan de clients (bv. PDF of complexe HTML). Een krachtig gegeven is de mogelijkheid om meerdere stylesheets te de nieren voor XMLdocumenten die dezelfde DTD volgen. Dit volgt uit het feit dat de XSL-regels worden gede nieerd, extern aan het XML document. Dit biedt een bijkomende exibiliteit, daar application frameworks in real-time kunnen bepalen welk type client de informatie opvraagt en hoe het resultaat dus dynamisch moet worden weergegeven.
XML en de toekomst Gezien de snelle evolutie die XML reeds heeft gekend is het erg moeilijk in te schatten welke impact XML in de volgende jaren of zelfs in de komende maanden zal teweegbrengen. Het is een feit dat bepaalde XML-tools nog lijden onder het feit dat ze zijn afgeleid van HTML-tools. Het staat vast dat de maturiteit van deze applicaties nog ferm zal toenemen, wat alsmaar krachtigere oplossingen en mogelijkheden zal realiseren. Ook de manier waarop JavaScript en XML zullen interageren is nog niet geheel duidelijk. Vermits het gros van de verwerking momenteel aan serverzijde gebeurt, is het niet ondenkbaar dat er meer belang zal worden gehecht aan client-side scripting om de werklast iets evenrediger te verdelen. Tenslotte is het mogelijk dat, alhoewel de B2B-markt een enorme kernmarkt is voor XML, de mobiele markt er in de nabije toekomst nog een grotere wordt, door de mogelijkheid van XML-data om in het juiste formaat te morphen.
XML op het web In tegenstelling tot HTML, kan men met XML relatief eenvoudig volgende concepten realiseren: Webclients die in real-time communiceren met twee of meer heterogene databanken. Applicaties waarbij een groot deel van de verwerking aan de client wordt overgelaten,
zodat de werklast van de server drastisch vermindert.
Applicaties waarbij dezelfde data op verschillende manieren moeten weergegeven worden
aan de verschillende clients.
Applicaties waarbij informatie uit verschillende bronnen naar eenzelfde layout dient
geformatteerd te worden.
19
]>
Figuur 2.3: Voorbeeld DTD Documenten die aangepast worden aan de noden van elke individuele gebruiker.
Hoewel het eveneens mogelijk is om dergelijke concepten in te voeren in HTML-pagina's door het gebruik van scripttalen (bv. Java-script) en plugins (applets, ActiveX-componenten, . . . ), laat XML toe om dit allemaal te doen zonder afhankelijk te zijn van externe software of het type/versie browser waarover de client beschikt. Men kan concluderen dat XML zeker niet beschouwd kan worden als een substituut voor HTML. HTML is immers nog steeds uitermate geschikt voor het verspreiden van kleine hypermedia-bestanden over het web. Bovendien kunnen vele XML-documenten eenvoudig worden geconverteerd naar HTML-formaat. XML kan dan ook perfect naast HTML gebruikt worden, zodat beiden elkaar aanvullen.
2.1.2 DTD : Document Type De nition Een Document Type De nition of DTD is een (overigens niet verplichte) structuurbeschrijving van een XML-document. Een DTD kan zowel in-line (in het document zelf) of in een extern bestand opgenomen worden. In het laatste geval bevat het XML-document een verwijzing naar het betre ende DTD-bestand. Het doel van een DTD is het de nieren van de legale bouwblokken van een XML-document. De DTD laat toe om onder meer de geldige elementen vast te leggen, evenals de nesting, het minimum aantal elementen, de verhouding van elementen tot elkaar, hun inhoud en de toegelaten of verplichte attributen.
Voorbeeld 2.5. De constructie van een eenvoudige DTD wordt toegelicht aan de hand van een simpel voorbeeld. De DTD in Figuur 2.3 bepaalt de structuur van een XML-document dat een boodschap voorstelt.
Het eerste element (boodschap) is het documentelement. Tussen haakjes staat de inhoud van het element aangegeven. Mogelijke waarden zijn onder andere ANY, EMPTY, CDATA (tekst), RCDATA (tekst met geexpandeerde entiteiten) en PCDATA (tekst + elementen). Daarnaast kan een tekst ook een of meerdere elementen bevatten. In het voorbeeld bevat elke boodschap een hoofding, gevolgd door een tekst. De volgorde waarin de elementen voorkomen ligt vast door de positie in de lijst.
20
Men kan ook aangeven dat het ene of het andere element moet voorkomen met een pipeline. Via een apersand duidt men aan dat beide elementen moeten optreden, zij het dan wel in een willekeurige volgorde.
De nitie 2.1. (element1 | element2) : `element1' komt voor of `element2' komt voor. (element1 & element2) : `element1' komt voor en `element2' komt voor.
Indien er ambiguteiten optreden, dienen er extra haakjes te worden ingevoegd.
Voorbeeld 2.6. De expressie (element1 | element2 & element 3) wordt dan ((element1 | element2) & element 3)
of (element1 | (element2 & element 3))
Tenslotte kan er ook vastgelegd worden hoeveel maal een element dient op te treden. In het voorbeeld bestaat een tekst bijvoorbeeld uit een of meer paragrafen.
De nitie 2.2. + minstens een * nul of meer ? nul of een
Voorbeeld 2.7. ((element1 | element2)* & element3)+
Uit het voorbeeld in Figuur 2.3 blijkt tevens dat elementen mogen gebruikt worden in de nities alvorens ze zelf gede nieerd werden. Er wordt immers gebruik gemaakt van een look-ahead parser. Een voorbeeld XML-document dat conform is met de opgegeven DTD wordt gegeven in Figuur 2.4. 21
John Doe Jane Doe Testberichtje <paragraaf>Een voorbeeld tekstje. <paragraaf>Groetjes, <paragraaf>John
Figuur 2.4: Voorbeeld XML-document, conform aan de DTD in Figuur 2.3 Telkens nu een applicatie een document verwerkt, waaraan een DTD verbonden is, zal eerst nagegaan worden of er aan de DTD is voldaan. Dit geldt uiteraard enkel indien de applicatie (bijvoorbeeld een web browser) over de nodige validatie-procedures beschikt. Zoniet, kan er een fout gegenereerd worden. Een voorbeeld van waar het gebruik van een DTD tot zijn recht komt is een applicatie die toelaat om via XML-documenten objecten toe te voegen aan een databank. Hierbij dient uiteraard te worden nagegaan of het XML-object wel conform is met de databank-objecten (zoals correcte datavelden).
2.1.3 XSDL (XML Schema De nition Language) Terwijl XML 1.0 een mechanisme voorziet om beperkingen op te leggen aan het gebruik van mark-up, nl. de Document Type De nition of DTD, is er voor het geautomatiseerd verwerken van XML-documenten een meer rigoureus alternatief vereist. Terwijl XML een meta-taal is die de regels de nieert om tag-talen mee te omschrijven, is een schema een formele speci catie van de grammatica van een dergelijke tag-taal. Een schema kan gebruikt worden om de inhoud van een document te valideren en te bepalen of dit document conform is met een instantie van de grammatica, zoals gede nieerd in het schema. Het W3C is begonnen met de ontwikkeling van deze nieuwe validatiemethode om de tekortkomingen en problemen die rezen bij het gebruik van DTD's op te vangen. Naast de meer accurate voorstelling van de beperkingen op de XML-structuren, wordt een XML-styling gebruikt om de constraints vast te leggen. Een XML schema is dus zelf ook een welgevormd, geldig XML-document. Dit resulteert in de mogelijkheid parsers toe te staan om XMLdocumenten en hun schema's op een analoge manier te behandelen. Dit in schril contrast tot de DTD die een eigen syntax gebruikt. XML Schema is evenwel nog een vrij jonge speci catie en staat als dusdanig nog niet volledig op punt. Vermits XML Schema geen onderdeel uitmaakt van de XML 1.0 speci catie, wordt een document niet `geldig' genoemd, ook al is het conform aan een zeker schema. Hiervoor dient het conform te zijn met de DTD (DOCTYPE declaratie) waarnaar het refereert. Schema validatie door een parser is bijgevolg ook nog niet verplicht volgens de speci catie. Vermits 22
een XML Schema een geldig XML-document is, is het zelf ook conform aan een DTD. Deze onduidelijkheden zullen waarschijnlijk worden weggewerkt in de volgende XML recommendation. Een XML Schema begint met de namespace declaratie. Eerst wordt de default namespace gede nieerd. Over het algemeen wordt het root element steeds `schema' genoemd: <xsd:schema xmlns:xsd="http://www.w3.org/1999/XMLSchema">}
Vervolgens dienen eventuele andere namespaces die in het XML-document kunnen voorkomen, te worden gede nieerd. Een element dat wordt beperkt, heeft de volgende syntax: <element name="[elementnaam]" type="[type element]" [Opties] >
Met type bedoelt men hier bijvoorbeeld String, boolean, oat,. . . . Ook complexere, samengestelde datastructuren kunnen worden voorgesteld met behulp van een schema. Over het algemeen zal men eerst de enkelvoudige elementen declareren en vervolgens de complexere elementen die hieruit zijn opgebouwd. Op analoge manier kan men tevens de elementattributen de nieren:
Naast `name' en `type' kunnen er nog andere attributen worden aangewend om verdere restricties in te voeren. `minOccurs' en `maxOccurs' leggen bijvoorbeeld beperkingen op, op het aantal maal dat een zeker element mag voorkomen. XML Schema kent nog wel enkele verdere opties en mogelijkheden, maar die zouden ons hier te ver leiden. Het bovenstaande wordt toegepast op een voorbeeld XML-document in Figuur 2.5: Een DTD voor dit XML-bestand zou er kunnen uitzien als in Figuur 2.6 en het overeenkomstige schema wordt getoond in Figuur 2.7. Er bestaan verschillende voorstellen voor de standaardisatie van XSDL, zoals XDR (XMLData Reduced) en BizzTalk schema's, maar er is slechts een W3C recommendation.
2.1.4 XML-parsers In deze paragraaf worden twee types XML-parsers nader onder de loep genomen: de DOM(Document Object Model) en SAX- (Simple API for XML) parsers. Beide API's (Application Programming Interfaces) werden ontworpen om te voorkomen dat elke programmeur die 23
<werknemer>John Doe <werknemer >Jane Doe 09/111.11.11
Figuur 2.5: Voorbeeld XML-document
]>
Figuur 2.6: DTD voor het XML-document in Figuur 2.5
<Schema name="schema\_voorbeeld" xmlns="http://www.w3.org/1999/XMLSchema" xmlns:vb=" http://www.voorbeeld.com/afdeling"> <ElementType name="werknemer" type="string" model="closed"/> <ElementType name="telefoon" type="string" model="closed"/> <ElementType name="afdeling" content="eltOnly" model="closed"> <element type="werknemer" minOccurs="1" maxOccurs="*"/> <element type="telefoon" minOccurs="1" maxOccurs="1"/>
Figuur 2.7: XML Schema voor het XML-document in Figuur 2.5
24
XML-documenten wenste te verwerken een XML-parser diende te schrijven in de gebruikte programmeertaal. De SAX- en DOM-API's zijn immers beschikbaar in een groot aantal talen, waaronder C++ en Java. De aanpak van beide systemen is echter volledig verschillend, zoals uit de volgende bespreking zal blijken.
DOM Het Document Object Model, kortweg DOM [4], is een boomstructuur, waarin elke knoop een component voorstelt uit een XML-document, ongeacht of het nu om een tekstueel bestand, een lijst of een tabulair document gaat. De DOM-functies laten toe om doorheen de boomstructuur te navigeren, knopen toe te voegen of te verwijderen en de inhoud van bestaande knopen aan te passen. Beschouw bijvoorbeeld het volgend XML-document in Figuur 2.8. John Doe <email>[email protected] Jane Doe <email>[email protected]
Figuur 2.8: Een voorbeeld XML-document DOM zet dit om in de structuur uit Figuur 2.9(de grijze nodes stellen hierbij karakterdata voor). DOM zal bovendien de volgorde van de knopen in de hierarchie opslaan vermits bepaalde toepassingen vereisen dat bijvoorbeeld het n-de kind kan worden opgevraagd. Daar alle knopen in feite objecten zijn, kan DOM eenvoudig gebruikt worden in object-
Figuur 2.9: DOM-boom voor het XML-document uit Figuur 2.8 25
Figuur 2.10: Pointerstructuur van DOM-nodes georieenteerde programmeertalen, zonder dat er eerst nog eigen structuren gede nieerd dienen te worden. DOM wordt soms ook een random access parsing methode genoemd omdat men op elk moment om het even welk documentobject kan bereiken. In Figuur 2.12 op pagina 28 wordt (het skelet van) een voorbeeld DOM-parser klasse weergegeven.
SAX SAX (Simple API for XML) [4] daarentegen levert een serial access protocol, want het stelt de data voor als een sequentie van gebeurtenissen (events). Dit maakt werken met SAX een stuk sneller, vermits er niet eerst een boomstructuur dient opgesteld te worden door de parser. Aan de andere kant dient er initieel wel wat meer werk te gebeuren: voor gebruik in een objectgeorienteerde programmeertaal moet er eerst een eigen objectmodel opgesteld worden evenals een listner klasse die de SAX events onderschept. SAX werkt immers op basis van een event driven of callback systeem. Telkens de parser een nieuwe XML-tag tegenkomt wordt een callback-functie van de klasse uitgevoerd. Op die manier kan men eenvoudig lterklassen implementeren die op basis van de events de documentdata gaan verwerken. SAX kent events voor het melden van open tags, gesloten tags en de verschillende soorten karakterdata. Vermits SAX de data echter sequentieel verwerkt is het niet mogelijk om een element op te vragen dat verder in de datastroom gelegen is. SAX wordt daarom vaak gebruikt voor geautomatiseerde data-overdracht. In Figuur 2.13 op pagina 29 wordt (het skelet van) een voorbeeld SAX-eventlistner klasse weergegeven, die simpelweg alle tekst uit het XMLbestand uitschrijft. Een meer reeel voorbeeld van een SAX-client kan gevonden worden in de appendices.
Vergelijking DOM { SAX In het geval van DOM doet de parser zowat al het werk: er wordt een volledige object structuur opgesteld en een referentie hiernaar wordt teruggegeven aan de gebruiker. De SAX parser daarentegen leest het document gewoon in en genereert een event telkens hij een herkenbare XML-structuurcomponent ontmoet. De opvang en interpretatie van deze events, evenals het 26
opzetten van een objectmodel ligt volledig in handen van de programmeur. Bij het gebruik van een eenvoudig object model zal SAX heel wat sneller zijn dan DOM. Wanneer een XML-bestand met document-data verwerkt dient te worden (bv. een Worddocument), waarbij geen herstructurering van de elementen is vereist, is DOM waarschijnlijk de beste oplossing. Indien het echter om seriele data gaat (bv. machine-gegenereerd, SQLqueries) geniet SAX-parsing wel degelijk de voorkeur. Tenslotte dient nog opgemerkt te worden dat SAX voordeliger is indien er gewerkt wordt met enorm grote bestanden (in de orde van enkele tientallen megabytes of meer), vermits DOM eerst het gehele document in het werkgeheugen zal opslaan in een boom-structuur, terwijl SAX op elk moment slechts een deel van het document aan het verwerken is.
Figuur 2.11: Categorisatie van XML-parsers Afhankelijk van het feit of de parser rekening kan houden met de achterliggende DTD van een XML-document, kan men spreken van validerende en niet-validerende parsers. Op basis hiervan kan men de XML-parsers verder categorizeren, zoals weergegeven in Figuur 2.11.
2.1.5 XSL : Extensible Stylesheet Language Extensible stylesheet language (XSL) [1] is een taal voor het uitdrukken van stylesheets. Deze stylesheets laten toe om XML documenten te herformatteren en transformeren. Ze zijn zelf ook opgesteld in XML. De transformatietaal kan bijvoorbeeld een XML-document omzetten in een welgevormd XHTML-document (waarbij uiteraard bepaalde informatie omtrent XMLobjecten verloren kan gaan). XSL legt de weergave van een XML-document vast en kan dus als convertor worden gebruikt die een XML-document uitvoert naar een PDF, postscript of TEX-document. XSL is gebaseerd op DSSSL (Document Style Semantics and Speci cation Language), zoals gebruikt in SGML documenten en CSS (Cascading Stylesheets), zoals aangewend bij HTML. Het doel was om XSL heel wat eenvoudiger in gebruik te maken dan DSSSL. In principe is XSL een symbiose van twee verschillende talen: een transformatietaal en een formatteringstaal. De transformatietaal dient om het formaat van XML-documenten aan te passen en wordt vooral toegepast bij applicaties die veel (meta-)data uitwisselen, waarvan 27
// JAXP imports import javax.xml.parsers.FactoryConfigurationError; import javax.xml.parsers.DocumentBuilder; //... // DOM imports import org.w3c.dom.Document; import org.w3c.dom.Node; //... public class DOM_Example { public static void main(String args[]) { try { if (args.length != 1) { System.err.println("Usage: java DOM_Example [filename]"); System.exit(1); } // Document Builder Factory instantiren DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance(); // Instelling validatie en namespaces factory.setValidating(true); factory.setNamespaceAware(false); DocumentBuilder builder = factory.newDocumentBuilder(); Document doc = builder.parse(new File(args[0])); // Document weergeven, vanuit de DOM-boom printNode(doc,""); // ...
}
}
} catch (Exception e) { e.printStackTrace(); }
private static void printNode(Node node, String indent) { // print DOM-boom }
Figuur 2.12: Skelet van een DOM-client 28
// JAXP imports import javax.xml.parsers.FactoryConfigurationError; import javax.xml.parsers.SAXParserFactory; //... // SAX imports import org.xml.sax.HansdlerBase; import org.xml.sax.SAXException; //... public class SAX_Example { public static void main(String args[]) { try { if (args.length != 1) { System.err.println("Usage: java SAX_Example [filename]"); System.exit(1); } SaxParserFactory factory = SaxParserFactory.newInstance(); // Instelling validatie en namespaces factory.setValidating(true); factory.setNamespaceAware(false); // Eigenlijke parsing SAXParser parser = factory.newSAXParser(); parser.parse(new File(args[0],new MyHandler())); // ...
}
}
} catch (Exception e) { e.printStackTrace(); }
class MyHandler extends HandlerBase { // SAX callback implementaties van DocumentHandler, // ErrorHandler, etc. }
Figuur 2.13: Skelet van een SAX-parser
29
<xsl:stylesheet namespace:xsl="http://www.xslnamespace.com"> <xsl:template match="/"> <xsl:apply-templates select="*"/> <xsl:template match="*|@*|text()|cdata()|comment()|pi()"> <xsl:copy> <xsl:apply-templates select="*|@*|text()|cdata()|comment()|pi()"/> <xsl:template match="categorie[.='Arbeider']"> <xsl:copy>Werknemer
Figuur 2.14: Een voorbeeld stylesheet het formaat voor elke client-applicatie verschillend dient te zijn. Er wordt hierbij dus geen rekening gehouden met de voorstelling voor menselijke lezers (bv. voorstelling op een scherm of op papier). Dit laatste wordt onderhouden door het formatterings-subgedeelte van XSL. De stylesheet in Figuur 2.14 verandert de naam van het XML-object `categorie' van `arbeider' naar `werknemer'. Dergelijke transformaties laten bijvoorbeeld toe om gegevens conform te maken met andere applicaties of databanken. Bij een XSL-transformatie zal de XSL-processor zowel het XML-document als de XSLstylesheet inlezen en op basis van de instructies in de stylesheet het XML-document correct weergeven. De transformatie omvat eigenlijk de omzetting van het XML-document tot een XSL-boom. Deze boom heet een virtuele wortel, die een verwijzing bevat naar de stylesheet behorende bij het te verwerken element. Daarnaast worden ook alle attributen, verwerkingsinstructie en commentaar en namespaces opgenomen als knopen in de boom. De formattering betreft vervolgens het verwerken van deze boom om de correcte uitvoer te creeren. De knopen in de XSL-boom worden formatteringsobjecten, die informatie bevatten omtrent paragrafen, spatiering, insprongen, enz.
Formattering (XSL FO { XSL Formatting Objects) Bij de formattering wordt de doelboom genterpreteerd op een wijze die resulteert in de representatie die de ontwikkelaar van het stylesheet voor ogen had. De formatteringsobjecten behoren elk tot een klasse die een deel van pagineringsinformatie vastleggen, zoals woordopsplitsing, paragraa ndeling,... De exacte interpretatie hiervan hangt af van de attribuutwaarden van de objecten. Zo kunnen objecten attributen hebben voor het bepalen van de tekstkleur, spatiebreedte en regelbreedte. Hiertoe wordt de XSL-boom nog enkele malen getransformeerd om tot een area tree te komen. De area tree bepaalt voor elk blad 30
Figuur 2.15: De XSL transformatie van het naal weer te geven document de precieze zone waar elk object (letter, afbeelding, vorm, . . . ) zal geplaatst worden. Naast de geometrische coordinaten kan aan elk van deze zones attributen zoals achtergrondkleur en randen toegekend worden. De formattering begint in de wortel, waarna argumenten worden doorgegeven aan de kinderen die dan op hun beurt aan de formattering kunnen beginnen (de boom wordt volgens de diepte-eerst methode doorlopen),. . . De kindknopen geven de resulterende zones terug aan hun ouders die deze indien nodig verder kunnen bewerken. De boom voorziet de nodige algoritmen (woordopsplitsing, lijnindeling,. . . ) niet, maar roept hiervoor kant en klare functies op uit de formatteringsapplicatie, bijvoorbeeld een browser. Uiteindelijk worden de zones die de root ontvangt in de area tree geplaatst en ligt de volledige bladschikking vast. De exacte werking is nog wel iets uitgebreider, maar dat zou ons hier te ver leiden. Met betrekking tot XML-linking voorziet XSL evenwel de mogelijkheid om bijkomende informatie te speci eren in verband met de weergave van hyperlinks. XSL is in staat om te de nieren op welke wijze een reeds bezochte link wordt aangepast (bijvoorbeeld wijziging van kleur), waar de doelinformatie in het document wordt ingepast, aanpassing van de vorm van een mousecursor die over een link heen beweegt, . . .
Transformatie (XSLT) XSL Transformation of XSLT is de taal die de transformatie van de XML-bronboom naar de XSL-doelboom voor zijn rekening neemt. Deze laatste boom noemt voluit de elementen attribuutboom. De elementen van de doelboom worden toegewezen aan een welbepaalde namespace. De constructie van de doelboom verloopt in twee fases. Eerst wordt een patroon vergeleken met de elementen in de bronboom en vervolgens wordt een overeenkomstige template gebruikt om een gedeelte van de doelboom op te stellen. Voorbeelden van dergelijke templates worden weergegeven in Figuur 2.14 . Voor de de nitie van deze templates wordt gebruik gemaakt van de XML Path language (Xpath), besproken in een volgende sectie. De vorm en samenstelling van de resultaatboom kan bijgevolg compleet verschillen van die van de bronboom. Meerdere templates kunnen toepasselijk zijn. In zo'n geval wordt er slechts een template gekozen op basis van een con ict-resolutiestrategie. Een enkele template kan overigens structuren van willekeurige complexiteit creeren. Vaak omvat de stylesheet dan ook maar een template. Meerdere XSL stylesheets kunnen gelijktijdig toegepast worden op een 31
Hello, world!
Figuur 2.16: Voorbeeld XSL FO-document XML-document, op voorwaarde dat het resultaat hetzelfde is als bij sequentiele toepassing. Bij het toepassen van een stylesheet worden de instructies in sequentie verwerkt, waarbij elke uitgevoerde instructie vervangen wordt door het gedeelte van de resultaatboom die erdoor ontstaat.
2.1.6 Xlink: XML Linking Language XML Linking Language (XLL of XLink) [11] is een methode om expliciete verbanden tussen twee of meerdere bronnen (of delen ervan) te speci eren en beschrijven. Deze bronnen beperken zich niet louter tot XML documenten maar kunnen om het even welk WWWobject omvatten (bijvoorbeeld afbeeldingen, bestanden, programma's,. . . ). Er bestaan 2 soorten XLinks (XLink conforme XML elementen) die de eigenlijke link de nieren en nog eens 4 Xlink attributen die de link beschrijven. Xlinks kunnen zowel gevormd worden als informatie voor een applicatie als voor de gebruiker van het betre ende document. In het laatste geval spreekt men van hyperlinks. De XLink attributen worden gede nieerd over een XLink namespace, in de vorm van een URI (in de voorbeelden zal gewoon `xlink' gehanteerd worden). De attributen die een link de nieren zijn: `type', `href', `role', `arcrole', `title', `show', `actuate', `label', `from', en `to'. Het type-attribuut, met als waarde `simple', `extended', `locator', `arc', `resource', `title', of `none' bepaalt het soort link. De elementnaam op zich kan vrij gekozen worden. Vermits de link volledig gede nieerd wordt door de attributen, kan elk element potentieel een xlink bevatten.
32
Simple links Deze zijn vergelijkbaar met de hyperlinks zoals ze voorkomen in HTML. Het betreft unidirectionele links tussen twee bronnen. HTML-links worden gede nieerd a.h.v. `a'- en `img'-tags en zijn volledig (inline) opgenomen binnen het brondocument. Simpele Xlinks hebben dezelfde functionaliteit en een vergelijkbare syntax als hun HTML tegenhangers.
Voorbeeld 2.8. Klik hier voor meer informatie.
Extended links Het weze duidelijk dat de simple links zeer beperkend zijn: Alle links duiden een relatie aan tussen juist twee documenten. De links zijn unidirectioneel; er is geen `terug-link' vanuit het doeldocument De links zijn opgenomen in het brondocument. Het is bijgevolg niet mogelijk om
{ { { {
links te de nieren in een read-only document links te plaatsen in afbeeldingen en dergelijke een link vanuit meerdere bronnen te de nieren een relatie te de nieren tussen documenten die niet de jouwe zijn.
Het is niet mogelijk om een onderscheid te maken tussen de documentinformatie ener-
zijds en de linking informatie anderzijds.
Via het extended link mechanisme kan men in principe zonder problemen een 200-eindige link de nieren die toelaat om van elk eindpunt een willekeurig ander op te vragen. Bovendien dient deze link slechts eenmaal te worden gede nieerd en hoeft hij in geen enkel van de eindpunten te worden ingepast. Een extended link die meerdere bronnen met elkaar verbindt kan de richting van de verbindingen tussen deze documenten de nieren door middel van arc -type elementen. Zo impliceert Figuur 2.17 dat de links mogen doorkruist worden zoals aangegeven in onderstaand schema. Indien de from- of to-attributen niet werden ingevuld dan wordt dit genterpreteerd als \vanuit om het even welke gede nieerd label. . . ", resp. \. . . naar om het even welk gede nieerd label". Indien er totaal geen arc-element aanwezig is, worden beide bovenstaande interpretaties tezamen gehanteerd. Naast de hierboven gellustreerde attributen kunnen extended links ook gebruik maken van de volgende optionele attributen: 33
Figuur 2.17: Voorbeeld extended link
Figuur 2.18: Doorloopmogelijkheden extended link
title: biedt informatie over het doel van de link aan de lezer van het document. Er
role/arcrole: biedt informatie over de rol en locatie van het doel en wordt gebruikt
show: geeft aan dat het doeldocument het huidige moet vervangen, in het huidige moet
actuate: laat de applicatie weten of activatie van de link moet gebeuren bij het inladen
kan eveneens gebruik worden gemaakt van een title-type element indien er een zekere markup dient te gebeuren binnen de titeltekst. door de applicatie die de XLink verwerkt.
worden ingepast of in een nieuw venster dient te worden geopend. De mogelijke waarden zijn "new", "replace", "embed", "other", en "none". van het brondocument of pas wanneer de gebruiker op de link klikt. Mogelijke waarden zijn "onLoad", "onRequest", "other", and "none".
De "other" waarde geeft aan dat de informatie elders in de link is bevat. De "none" waarde vertelt de applicatie dat er hiervoor geen speci catie vastligt binnen de link.
Linkbases Vermits extended links relaties kunnen beschrijven tussen vele verschillende bronnen (ev. read-only), worden ze over het algemeen opgenomen in een extern XML-document dat enkel 34
en alleen een aantal verwante links speci ceert: een zogenaamde linkbase. XML documenten die gebruik maken van deze links kunnen intern een verwijzing bevatten naar deze linkbase, waarna de verwerkende applicatie automatisch de voor dat document betekenisvolle links opzoekt.
2.1.7 XPATH XML Path Language (XPath) [8] is een taal ontwikkeld met als doel een gezamelijke syntax en semantiek aan te bieden om de inhoud van een XML-document op te vragen en te adresseren. XPath kan gebruikt worden door zowel XSLT (paragraaf 2.1.5), XPointer (paragraaf 2.1.8) en Xlink (paragraaf 2.1.6). Deze taal gebruikt een path-notatie (zoals in een URL) om een deel van een XML-document aan te spreken. Om het gebruik van XPath in XML-uitdrukkingen en URI's mogelijk te maken verschilt de syntax van de gewone XML-syntax.
Voorstelling In XPath wordt een XML-document voorgesteld als een boom van knopen, vergelijkbaar met de DOM-boom. De verschillende soorten knopen omvatten `elementknopen', `tekstknopen' en `attribuutknopen'. De wortel van deze boom is een virtuele knoop die de ouder is van het documentelement. Met elk element in het document komt een elementknoop overeen. Elementknopen hebben een uniek ID indien dit werd gede nieerd in de DTD van het betre ende document. Met de attributen van elk element komen attribuutknopen overeen. In tegenstelling tot de DOM-boom zijn de attribuutknopen hier geen kinderen van hun bijbehorende elementknopen, hoewel de elementen wel ouders zijn van hun attributen. Teksten worden gegroepeerd in tekstknopen (waarbij de CDATA-tag wordt verwijderd). Daarnaast bestaan er nog enkele speciale knopen: verwerkings-, commentaar- en namespaceknopen. Voor elke XML verwerkingsinstructie, wordt er een verwerkingsknoop voorzien in de boom. Deze node omvat de target van de verwerkingsinstructie, evenals de instructie zelf, evenwel zonder de tags `'. Commentaarknopen omvatten de strings binnen de XML commentaar-tags (dus zonder de omsluitende `'). Elk element heeft een verzameling geassocieerde namespace-nodes, een voor elke namespace die het element in zijn scope omvat. Namespace nodes worden nooit gedeeld door elementen. Aan de hand van deze boom kunnen XPath-expressies opgesteld worden die het gewenste onderdeel van een XML-document opleveren. XPath-expressies worden geevalueerd binnen een context. Deze omvat een context-knoop (een startpunt voor de evaluatie) en twee getallen: de contextpositie en contextgrootte. Het resultaat van een XPath expressie levert een van vier soorten objecten op: een nodeset (verzameling knopen), een string, een vlottende kommagetal of een boolean waarde (waar of vals). De belangrijkste categorie van expressies zijn de localisatiepaden. Een dergelijk pad bestaat uit drie gedeelten: een as (bv. de contextknoop zelf, zijn kinderen, voorouders, nakomelingen,. . . ), een nodetest (bv. de naam van een knoop of het type knoop) en nul of meer predikaten (voorwaarden waaraan knopen moeten voldoen): \as::nodetest[predikaat]. . . [predikaat]". Hierbij duiden de vierkante haakjes geen optionele elementen aan, maar het zijn zelf letterlijk op te nemen literals. 35
1. 2. 3. <par onderwerp="Inleiding">Eerste paragraaf van H1 4. <par onderwerp="Java Beans">Tweede paragraaf van H1 5. <par onderwerp="XML">Derde paragraaf van H1 6. 7. 8. 9. <par onderwerp="XPath">Eerste paragraaf van H2 10. <par onderwerp="XPointer">Tweede paragraaf van H2 11. 12. 13. 14. <par onderwerp="Source code">Eerste paragraaf van H3 15. 16.
Figuur 2.19: Voorbeeld XML bestand
Voorbeeld 2.9. Beschouw het eenvoudige XML-document uit Figuur 2.19. Stel dat element \hoofdstuk H2" de contextknoop voor de lokalisatieopdracht is.
child::text() selecteert alle kindknopen van de contextknoop die tevens tekstknopen
zijn. In de guur de string op de regels 9 en 10:
"Eerste paragraaf\ldots Tweede paragraaf van H2" descendant-or-self::* selecteert de nodeset bestaande uit de contextknoop en al zijn
afstammelingen. Hier is dit het hele tweede hoofdstuk (regels 8-11).
child::par[position()=last()] selecteert de nodeset opgebouwd uit de laatste (tweede)
paragraaf van hoofdstuk 2, namelijk die over `XPointer' (regel 10).
ancestor::boek selecteert alle ouders (en voorouder) die boeken zijn. Hier dus de
nodeset met enkel het boek-element.
attribute::nr selecteert het attribuut van de contextnode. Hier dus de string \H2",
het attribuut van de contextnode (hoofdstuk H2).
Ook meer complexe uitdrukkingen zijn mogelijk: /child::hoofdstuk[position()<3]/child::par [position()=2] [attribute::type="onderwerp" and substring(attribute::onderwerp, 6)="Beans"]
36
Deze uitdrukking zet de wortel als contextknoop en selecteert vervolgens van de eerste twee kinderen (alle hoofdstukken op posities kleiner dan drie) telkens het tweede kind (paragraaf op de tweede positie) indien dit een onderwerp-attribuut heeft, waarin de string `Beans' voorkomt, startend vanaf de zesde letter. Het resultaat is hier dus de nodeset bestaande uit de tweede paragraaf van het eerste hoofdstuk, met als onderwerp `Java Beans' (regel 4).
Core functies Elke XPath-implementatie ondersteunt een aantal `core'-functies die vooral worden aangewend om de predikaten voor te stellen. Hiertoe behoren een aantal functies die bewerkingen op strings uitvoeren.
Voorbeeld 2.10. substring("abcdefg", a.d, b.g) levert \bcd" op, namelijk alle letters uit de string
\abcdefg" die zowel behoren tot het interval a-d als b-g.
translate("voorbeeld 1,voorbeeld 2","beeld","BEELD") geeft
voorBEELD1, voorBEELD2
terug.
Andere functies laten dan weer toe om onder andere boolean expressies te evalueren, bewerkingen op getallen uit te voeren (afrondingen e.d.) of om de contextpositie/-grootte terug te geven.
2.1.8 XPointer In HTML is het slechts mogelijk om naar een speci ek deel van een document te verwijzen indien de eigenaar van het HTML-document op die locatie een anchor (anker) heeft geplaatst. XML laat echter toe om een willekeurige locatie in een arbitrair XML-document te adresseren. Hiertoe kan men de XML Pointer language (XPointer) hanteren. De structuren die door XPointer worden teruggegeven kunnen op een willekeurige manier verwerkt worden door de opvragende applicatie. XPointer is een uitbreiding van de eerder besproken XPath taal en laat onder andere toe om adresexpressies op te nemen als fragment identi ers in een URL, zodat de resulterende URL niet naar een volledig XML-document, maar naar een speci ek onderdeel ervan verwijst. Evenals XPath werkt XPointer op basis van een iteratieve selectie die gebeurt aan de hand van opgegeven assen, predikaten en functies.
37
Volledige XPointers De standaard XPointer-uitdrukkingen bestaan uit een of meerdere schema-namen, elk gevolgd door een expressie tussen haakjes. De enige schemanaam die momenteel gebruikt kan worden is xpointer; alle andere namen zijn gereserveerd voor toekomstig gebruik. De uitdrukkingen worden geevalueerd van links naar rechts. Indien de opzoeking op basis van de eerste expressie faalt probeert men opnieuw op basis van de tweede, enz. Indien alle opzoekingen falen, geeft de applicatie een fout terug.
Voorbeeld 2.11. De uitdrukking xpointer(id("Hoofdstuk2"))
geeft het element met id \Hoofdstuk2" terug. Een dergelijke opsporing kan slechts uitgevoerd worden indien er voor dat document een DTD werd opgesteld die het id-attribuut de nieert. Wanneer er geen DTD aanwezig is wordt er dus een fout gegenereerd. Dit kan opgevangen worden door de volledige XPath-vorm als tweede (alternatieve) expressie op te nemen: xpointer(id("Hoofdstuk2")) xpointer(//*[@id="Hoofdstuk2"])
Naast standaard XPath expressies voorziet XPointer eveneens de mogelijkheid om speci eke punten of een bereik te selecteren in de DOM-boom van het desbetre ende document. Het dient hier dus niet noodzakelijk om een nodeset te gaan. Ook een portie van het document dat elementen bevat die niet in relatie tot elkaar staan kan geselecteerd worden, bijvoorbeeld een selectie van ergens in het midden van hoofdstuk 2 tot het midden van hoofdstuk 5. De selectie kan dus ook delen van een element bevatten, zoals een enkele letter. Hiertoe worden de begrippen locatie en locatieset gede nieerd, waarbij een locatie een punt, bereik of element in een XML-document is. Een puntlocatie wordt bepaald door een opgegeven node (de containernode) en een index die de locatie binnen deze node vastlegt (bv. het n-de subelement of het n-de karakter in een string,. . . ). Een bereik wordt vervolgens bepaald door een koppel puntlocaties, waarbij het eindpunt na het beginpunt is gelegen in de volgorde bepaald door het document.
Voorbeeld 2.12. Enkele range-uitdrukkingen: xpointer(id("Paragraaf4")/range-to(id("Paragraaf7"))) xpointer(id('Hoofdstuk1')/item[1]/range-to(followingsibling(item)[2])
38
Bare name XPointers Deze verkorte vorm kan gebruikt worden bij het opzoeken van XML-elementen op basis van de naam. In plaats van de volledige XPointer \xpointer(id("Hoofdstuk2"))" kan bijvoorbeeld gewoon de bare name XPointer \Hoofdstuk2" gebruikt worden. Naast deze verkorte schrijfwijze biedt deze bare name vorm nog twee additionele voordelen: Ze moedigt het gebruik van ID's aan, die over het algemeen het langst overleven bij
documentwijzigingen. Indien men bijvoorbeeld verwijzingen gebruikt naar het derde element van een document, kunnen er al snel problemen ontstaan wanneer de auteur later nieuwe elementen tussenvoegt. Indien men echter verwijst naar de titel van het derde element is de kans groot dat deze na een wijziging gelijk is gebleven.
Indien deze vorm wordt gebruikt in URI's, komt ze overeen met de fragment identi ers
zoals in HTML, wat een eventuele vertaling kan vereenvoudigen.
Kindsequenties In de tweede verkorte vorm, de kindsequentie, gebruikt men gehele getallen om een iteratieve zoekopdracht uit te voeren: elk getal n betekent zoveel als het n-de kind van het huidige element.
Voorbeeld 2.13. 1. De expressie hoofdstuk4/6/8 verwijst naar hoofdstuk 4, paragraaf 6, subparagraaf 8. 2. /1/3/7/1
Ofwel wordt er gestart vanaf een opgegeven, benoemde contextnode (eerste voorbeeld), of er kan gezocht worden vanaf het documentelement (tweede voorbeeld).
Codering Vermits Xpointer-uitdrukkingen zowel in XML-documenten als in URI's kunnen voorkomen, dient er een codering aangewend te worden wanneer er bepaalde speciale karakters in voorkomen. Hiervoor maakt men gebruik van escape karakters.
Voorbeeld 2.14. De expressie xpointer(//*[@id='d\'{e}j\`{a}'])
wordt bijvoorbeeld gecodeerd als 39
http://www.xml.com/vb.xml# xpointer(//* % 5B@id='d% C3% A9j% C3% A1'% 5D)
voor gebruik in een URI en xpointer(hoofdstuk1/paragraaf position() >= 3)
wordt gecodeerd als
voor gebruik in een XML-link.
2.1.9 Namespaces XML laat toe om eigen tags te de nieren bij het opstellen van een XML-document. Nu is dit geen probleem wanneer er slechts een DTD wordt vastgelegd, waaraan het document dient te voldoen. Het is evenwel mogelijk om een document conform te maken aan meerdere DTD's (hierbij dienen prioriteiten te worden vastgelegd om DTD-collisies te vermijden). Vermits deze DTD's opgesteld kunnen zijn door verschillende auteurs, is het niet ondenkbaar dat een zelfde elementnaam in verschillende DTD's kan gede nieerd zijn, telkens met andere betekenissen. Vandaar dat er een methode werd vastgelegd om in dergelijke situaties alsnog de elementen van elkaar te onderscheiden: de namespaces. Het spreekt voor zich dat dit mechanisme slechts werkt indien de namespaces wereldwijd uniek zijn. Nu bestaat er reeds een identi er op het web die een wereldwijd unieke resource bepaalt, namelijk de URI. Over het algemeen wordt dus de eigen domeinnaam gebruikt, of iets dat ervoor dient door te gaan als de auteur niet over een domeinnaam beschikt (bv. \http://www.voornaam-achternaam.com"). De URI moet dus in werkelijkheid niet noodzakelijk bestaan, maar dient enkel om de namespace uniek te maken. Vermits het nogal omslachtig zou zijn om telkens een hele URI te plaatsen voor een elementnaam, wordt er vaak een afkorting gehecht aan de namespace.
Voorbeeld 2.15. Beschouw de uitdrukking: <doc:ns xmlns:doc="http://www.john-doe.com/dtd/messages" >
De volgende elementen kunnen dan met een verkorte namespace-notatie gebruikt worden:
40
<doc:message> <doc:from>John Doe
Bovendien worden namespaces overgeerfd. Indien een element dus geen namespace de nieert, wordt er naar het ouder-element gekeken, dan de grootouders, enz. . . Tenslotte is het ook mogelijk om een default namespace vast te leggen, waaraan alle elementen zonder namespace-de nitie zullen gehecht worden.
2.1.10 XMI XML Metadata Interchange, kortweg XMI, speci eert een open informatie-uitwisselingsmodel, dat de ontwikkelaars van object-technologie de mogelijkheid biedt modellen en data uit te wisselen op een gestandaardiseerde manier. Het voorziet consistentie en compatibiliteit van applicaties, voor modellen gecreeerd in collaboratieve omgevingen. Door een industrie-standaard vast te leggen op gebied van opslag en delen van object programmerings-informatie, kunnen ontwikkelingsteams die verscheidene tools van verschillende ontwikkelaars gebruiken toch collaboreren. De nieuwe XMI standaard laat ontwikkelaars toe het web te gebruiken voor de uitwisseling van data tussen tools, applicaties en repositories en zo robuuste, veilige en gedistribueerde applicaties te ontwerpen in een ontwikkelingsteam. IBM, Unisys en andere grote industrieleiders stelden deze nieuwe open industrie-standaard voor om de voordelen van webgebaseerde XML te combineren voor de niering, validatie en delen van document-formaten op het web, gebaseerd op de voordelen van de object-georienteerde Uni ed Modeling Language (UML) en Meta Objects Facility (MOF), een speci catie van de Object Management Group (OMG). UML voorziet applicatie-ontwerpers van een gemeenschappelijke taal voor het speci eren, visualiseren, construeren en documenteren van gedistribueerde objecten en business modellen. Het voorstel van IBM betreft de uitwisseling van UML modellen en MOF meta-modellen. Het de nieert standaard XML DTD's die deze uitwisselingsmodi vastleggen. XMI laat tevens de automatische generatie van XML DTD's toe voor elk meta-informatiemodel. De uitbreidbaarheid van XMI ondersteunt de generatie van DTD's voor de de nitie van additionele domeinen, zoals data warehousing, componentgebaseerde ontwikkeling en web meta-data. Het gros van de OO modelleringsapplicaties, zoals Rational Rose2 voorzien reeds in de generatie van of conversie naar XMI. Momenteel gaat het nog om een voorstel, maar naar alle verwachting zal de de nitieve standaardisatie niet lang op zich laten wachten. De conversie van het gra sch UML model naar de XMI tekst gebeurt vanuit conceptueel standpunt in twee stappen. Vooreerst wordt het UML model geconverteerd naar een metamodel. Aldus wordt een complexe hierarchie het leven ingeroepen (zie guur).Vervolgens de nieert de XMI-norm volgens welke regels de XMI-stroom wordt gegenereerd uit het metamodel. Enkel de expliciet benoemde meta-model informatie wordt hierbij opgenomen. 2
Modelling tool van Rational Software.
41
Figuur 2.20: Extract uit het meta-model zicht op een klasse in UML De XML-stroom omvat twee onderdelen: de `head data' en de `use data'. De benamingsconventies verzekeren dat de tag-namen verstaanbaar zijn voor iedereen die vertrouwd is met het meta-model. Elke tag vangt aan met de naam van het meta-model package afkomstig van de corresponderende geediteerde meta-klasse. Dit wordt gevolgd door de namen van de metaklasse en het meta-attribuut, zodat het makkelijk verstaanbaar is voor de geoefende lezer, hoe elk onderdeel van de meta-model stroom overeenstemt met een deel van het eigenlijke meta-model. Een mogelijk nadeel aan de voorgestelde XMI-standaard is de gigantische hoeveelheid tekst die gegenereerd wordt in de XMI-stroom. De XMI-voorstelling van elk van de UML-schema's opgesteld voor dit project (zie voorbeeldjes in de appendix), neemt meer dan 1500 regels tekst in beslag. Bijgevolg is er vaak meer bandbreedte vereist om een XMI-voorstelling uit te wisselen, dan een applicatie-eigen representatiemethode. Dit probleem is vooral te wijten aan de lengte van de tag-namen. Vaak zijn deze tags langer dan de omsluitende data. Zou men echter verkiezen om kortere notaties voor de tags te gebruiken, dan zou het document sterk inboeten qua leesbaarheid. Het is een afwegen van performantie t.o.v. overzichtelijkheid. Dit is een probleem dat ook bij de XML-generatie in het project zal opduiken. 2.2
Java
Het is duidelijk dat Java de programmeertaal bij uitstek is voor het ontwerpen van webgebaseerde toepassingen. Vooral de portabiliteit van de Java Virtuele Machine (JVM) is een aanzet geweest tot de immense populariteit van de taal. Al even populair is de term XML en het is geen toeval dat quasi allle XML-gerelateerde toepassingen in Java worden ontwikkeld. 42
Beide standaarden vullen elkaar perfect aan, zoals zal blijken uit de volgende bespreking.
2.2.1 Java en XML Uit de bespreking van XML blijkt duidelijk welke voordelen XML biedt ten opzichte van het klassieke HTML en Unicode, maar men kan zich de vraag stellen waarom er voornamelijk van Java wordt gesproken wanneer het XML-applicaties betreft. Java bracht een revolutie teweeg in de wereld van programmeertalen, door een platform-onafhankelijke ontwikkelingstaal aan te bieden. XML biedt een gelijkaardige mogelijkheid, namelijk een platform-onafhankelijk formaat voor het uitwisselen van gegevens. Daarnaast bieden Java en XML elk vele mogelijkheden die ideaal zijn voor het bouwen van enterprise applicaties, zoals uitbreidbaarheid en herbruikbaarheid. Elk afzonderlijk hebben de beide concepten hun beperkingen. Java vereist dat de ontwikkelaar een formaat opstelt voor netwerkdata en formaten voor presentatie. Bovendien moet er gebruik gemaakt worden van JavaServer pages (JSP) die geen scheiding bieden tussen inhoud en presentatie. XML aan de andere kant is simpelweg een metataal die weinig praktisch nut heeft zonder tools als parsers en XSL-processors. Java en XML tezamen daarentegen bieden de perfecte manier aan om portabele code en portabele data te creeren. Bovendien is je applicatie in staat te communiceren met andere programma's die deze wijd verbreide standaard ondersteunen en bestaan er meer XML-parsers, processors en publishing frameworks in Java dan in eender welke andere programmeertaal. Java wordt meer en meer gebruikt voor het bouwen van gedistribueerde applicaties, hetzij binnen een enkele bedrijfsomgeving, hetzij in een business-to-business context. Deze gedistribueerde applicatie-ontwikkeling versnelde de totstandkoming van de Java 2 Enterprise Edition (J2EE) met zijn Enterprise JavaBeans (EJB) en andere server-technologieen, zoals servlets en transaction processing. Vanaf EJB 1.1 heeft men ervoor geopteerd om XML aan te wenden als de descriptor tussen EJB's. Dit laat toe om EJB's geschreven voor verschillende applicatieservers toch uit te wisselen. Ook de con guratie van recente webservers en publishing frameworks gebeurt tegenwoordig met behulp van XML. Java en XML zijn overigens geen verplicht paar. Het spreekt voor zich dat men onder Java een eigen formaat kan invoeren, maar omgekeerd is XML ook onafhankelijk van de taal waarin de documentuitwisseling gebeurt. Het is dus perfect mogelijk dat een XML-document gegenereerd door een Java programma kan gelezen worden door een applicatie geschreven in C++ of om het even welke andere taal.
2.2.2 Parser generators De compiler Een compiler is een programma dat een bronbestand, geschreven in de ene taal (de brontaal) vertaalt naar een equivalent programma in een andere taal (de doeltaal). Hierbij kan men de compilatie ruwweg opsplitsen in twee delen: het analyse en het synthese gedeelte. Tijdens de analyse wordt het bronprogramma opgedeeld in elementaire stukken en wordt er een intermediaire voorstelling gegenereerd. Gedurende de synthese wordt de doelrepresentatie opgesteld uitgaande van de intermediaire voorstelling. 43
Figuur 2.21: Fasen van een compiler De analyse op zich wordt dan weer gekenmerkt door drie gescheiden fasen. Tijdens de lineaire of lexicale analyse (ook wel scanning genoemd), wordt de ingelezen karakterstroom opgedeeld in tokens (lexeme matching). Dit zijn sequenties van karakters die een collectieve betekenis hebben. De hierarchische of syntax analyse (parsing genoemd) voorziet dan weer in het groeperen van de tokens uit het bronprogramma, tot grammaticaal correcte zinnen, uitgaande van een syntaxbestand. De semantische analyse tenslotte, zal nagaan of het bronbestand semantische fouten bevat en deze rapporteren. Voor het bijhouden van de identi ers en hun attributen tijdens de analyse, wordt een beroep gedaan op de symbooltabel. Deze datastructuur bevat een record voor elke identi er, met velden voor de attributen. De verschillende fasen van een compiler kunnen dus worden voorgesteld, zoals in Figuur 2.21. Tijdens het parsen kan er een boomstructuur opgesteld worden, waarbij elke node een ingelezen lexeme bevat. Deze voorstelling vereenvoudigt de controle van grammaticale producties en syntaxregels, vermits de boom via top-down of bottom-up matching technieken kan worden doorlopen. Syntax trees bevatten enkel de ingelezen identi ers (de terminalen), terwijl in parse trees eveneens de overeenkomstige variabele-namen zijn opgenomen.
Parser generators Uit het bovenstaande blijkt duidelijk dat het haast onbegonnen werk is om zelf een parser of compiler te schrijven voor een complexe brontaal. Gelukkig bestaan er tools om ons bij te staan bij de constructie van parsers: de parser generators. Een van de populairste applicaties voor de constructie van het front-end gedeelte van een compiler (lexicale, syntax en semantische analyse) is `YACC' (Yet Another Compiler Compiler), in combinatie met de lexical analyser `Lex'. Als gevolg van het succes dat YACC kende, zagen een hele nieuwe klasse 44
van parser generators het levenslicht, waaronder enkele geschreven in Java. De bekendsten zijn onder andere JavaCC, AntLR, Jikes en CUP.
Praktisch gebruik JavaCC (Java Compiler Compiler) is een van de meer populaire parser generators voor het gebruik bij Java applicaties. Een parser generator is dus een tool die een grammatica-speci catie inleest en converteert naar een Java programma dat vervolgens in staat is om matches binnen die grammatica te herkennen. Naast de parser generator zelf biedt JavaCC eveneens andere diensten aan, zoals de mogelijkheid om parse trees op te stellen, acties te de nieren, te debuggen, enz. Het is mogelijk de output van JavaCC nog verder te verwerken alvorens er gebruik van te maken. Met syntax tree builder tools, zoals JJTree en JTB (Java Tree Builder) kan men uitgaande van een JavaCC grammatica-bestand het volgende genereren: Een verzameling syntaxboom klassen, gebaseerd op de producties in de grammatica, die
gebruik maken van het Visitor patroon3 .
Een aantal visitor interfaces, die kunnen aangewend worden om de kinderen van de
huidige node in de syntaxboom te bezoeken.
Een JavaCC grammatica met de correcte annotaties, vereist om een syntaxboom op te
stellen gedurende het parsen.
De constructie van een syntaxboom en de bijhorende visitor klassen maakt de output van de parser natuurlijk veel gemakkelijker manipuleerbaar. Door de visitor de gehele boomstructuur te laten a open, kan er bij elk type node (of dus elk type identi er) een event gegenereerd worden die de overeenkomstige actie triggert. De link met de DOM-voorstelling van een XML-bestand is zo natuurlijk snel gelegd.
2.2.3 Servlets Een servlet is een generische uitbreiding van een server; een Java klasse, die dynamisch door de server kan worden ingeladen om de functionaliteit uit te breiden. Evenals gewone Java programma's wordt er gebruik gemaakt van de Java Virtual machine (JVM). In tegenstelling tot Java applets is er geen Java ondersteuning vereist aan de client side, wat de compatibiliteit met oudere browsers alvast ten goede komt. Hierna volgt een opsomming van enkele van de voordelen die Java servlets bieden :
3
Portabiliteit: Vermits servlets in Java worden geschreven genieten ze ook van de over-
draagbaarheid van Java. Een servlet geschreven op een Windows systeem kan nadien even gemakkelijk op een Unix servlet server genstalleerd worden : `write once, serve everywhere'. Uiteraard dient de Java Virtuele Machine (JVM) wel genstalleerd te zijn op het systeem.
Zie appendix voor bijkomende informatie.
45
Figuur 2.22: Werking van een parser generator
Ecientie: Elke servlet wordt slechts als een enkele instantie opgeladen in het geheugen
Veelzijdigheid: Servlets kunnen een beroep doen op de veelzijdigheid van de Java API
Veiligheid: Servlets erven de `type safety' van Java, maken gebruik van Java's garbage
Elegantie: Servlet code is over het algemeen proper, object georienteerd, modulair en
Integratie: Servlets werken nauwer samen met de server, dan bijvoorbeeld CGI-scripts.
Extensibiliteit: Nieuwe servlets kunnen erg eenvoudig worden toegevoegd aan servlet
van de server. Dit betekent dus een hoop minder processorwerk en nodige geheugenruimte voor de server. Ter vergelijking : bij CGI (Common Gateway Interface) dient er voor elke request een apart proces te worden opgestart. en zijn dus in staat om multithreading, data compressie, database aansluitbaarheid, enz te implementeren. collector en hebben bijgevolg geen last van `dode pointers' of memory leaks. Uiteraard dient wel een goede programmeerstijl te worden aangewend, want de servlet kan heel wat meer geheugen opslorpen dan een overeenkomstig CGI-script. Bovendien wordt tevens gebruik gemaakt van Java's strikte en uitvoerige exception handling. Tenslotte kunnen servlets uitgevoerd worden `onder toezicht' van een security manager, die erop toeziet dat de veiligheidsregels worden nageleefd (bv. i.v.m. bestandstoegang). makkelijk leesbaar. Dit is onder andere het gevolg van de Servlet API die de meest gebruikte functies reeds implementeert. Servlets kunnen bijvoorbeeld een beroep doen op de server voor authorisatie checks, vertaling van bestandspaden, gebruikers toevoegen aan een databank,. . .
servers om zo bijkomende functionaliteit te bieden. Bovendien is de mogelijkheid voorzien tot verdere uitbreiding, bijvoorbeeld op het gebied van communicatieprotocollen.
46
Figuur 2.23: Vergelijking CGI-scripts en Java servlet Het gebruik van een servlet verschilt in principe weinig van een CGI-script. Ook servlets worden doorgaans in een speciaal daarvoor bestemde directory geplaatst (afhankelijk van de server), waarna ze onmiddellijk actief zijn. Complexe servlets vergen nog wel enige con guratie aan de serverzijde. Vervolgens kan een servlet opgeroepen worden door de corresponderende klassenaam toe te voegen aan de URL die het servlet pad oproept. Evenals CGI-scripts kunnen servlets argumenten acccepteren. Het gedrag van de servlet wordt hierbij gede nieerd door de implementatie van de GET-methode in de servletklasse.
Voorbeeld 2.16. Beschouw een servlet genaamd \MyExampleRequest.java", opgenomen in de package genaamd \MyRequest", die argumenten van het type \id" kan verwerken. De Tomcat servlet engine veronderstelt dat servlets geplaatst worden onder de directory \WEBINF/classes", die in de URL gemapt wordt op \servlet". Een oproep naar deze servlet zou dus kunnen zijn: http://www.myserver.com/path/servlet/MyRequest.MyExampleRequest?id=5
Voorbeelden van servlet-implementaties kunnen teruggevonden worden in de appendices.
2.2.4 J2EE Meer en meer ontwikkelaars hebben tegenwoordig nood aan een platform voor het schrijven van gedistribueerde transactionele applicaties van industriele kwaliteit, die een beroep kunnen doen op een verhoogde ecientie, veiligheid en betrouwbaarheid van de server-side technologie. Men kan hiervoor gebruik maken van een multi-tiered model, waarbij een thin client 47
applicatie de business logica op de server aanroept. Deze manier van ontwikkelen is normaal gezien niet eenvoudig, gezien het feit dat men (aan de serverzijde) rekening moet houden met concepten als transactie en state management, multithreading, resource pooling en andere complexe details op laag niveau. Het Java 2 Enterprise Edition platform (J2EE) vereenvoudigt evenwel de constructie van dergelijke applicaties, door een abstractie in te voeren die de lage-niveau implementatie-details scheidt van de eigenlijke business logica. J2EE voorziet dus een platform voor het bouwen van grootschalige applicaties en brengt hiervoor de nieuwste technologieen samen, zoals Java Servlets, Java Server Pages (JSP), Enterprise Javabeans (EJB), CORBA, JNDI, JDBC en XML. Aan het hart van J2EE liggen de Enterprise Javabeans, de serverside component technologie. De EJB's vormen de middelste laag in een three-tier client-server systeem. Het J2EE is dus een architectuur voor de ontwikkeling, deployment (ingebruikname) en uitvoering van applicaties in een gedistribueerde omgeving. De betre ende applicaties vereisen databanktoegang, beveiliging, client connectiviteit en transactiemanagement. Het J2EE-platform levert deze diensten, zonder dat de programmeur zich hierover dient te bekommeren. Bovendien stimuleren EJB's het construeren van makkelijk herbruikbare componenten en proberen een einde te maken aan de heterogeniteit die er momenteel heerst onder de multi-tier systemen. J2EE applicatie-ontwerpers schrijven de applicatie-componenten. Een applicatie-component is een alleenstaande module (JAR, WAR of EAR bestanden) die toegevoegd wordt aan en interfacet met andere applicatie-componenten. Deze omvatten zowel thin-clients, applets, servlets, JSP pagina's als server-side EJB's. Zo kan een J2EE applicatie bijvoorbeeld opgebouwd zijn uit een HTML bestand gebruik makende van JSP om informatie op te vragen, een servlet om de informatie op te vangen en een EJB om ze uiteindelijk te verwerken (bijvoorbeeld toe te voegen aan een databank). Om J2EE applicaties te schrijven dient de ontwikkelaar te beschikken over de J2EE API's, een J2EE applicatie server, een web server, databank en deployment tools. Om portabiliteit te verzekeren, kan gebruik gemaakt worden van de Sun referentie implementatie.
Voordelen van middle-tier servers Een middle-tier server speelt een vitale rol in een three-tier applicatie. Het behandelt de requests van de clients en schermt de complexiteit af van het back-end systeem en de databanken. Bovendien kan de middleware laag ondersteuning bieden aan verschillende clients, zoals web browsers, Java applicaties of draagbare apparaten. De clients dienen enkel rekening te houden met de user interface en hebben hierbij geen weet van de achterliggende databanken of complexe business rules. De architectuur van het J2EE platform, maakt dit de ideale keuze voor het ontwikkelen van middle-tier servers.
J2EE architectuur De Java 2 SDK, Enterprise Edition is de referentie-implementatie van Sun Microsystems. De hoofdonderdelen van deze architectuur worden voorgesteld in Figuur 2.25.
48
Figuur 2.24: Een three-tier client/server architectuur
Figuur 2.25: J2EE architectuur
49
2.2.5 Enterprise JavaBeans De idee achter JavaBeans is het ontwikkelen van herbruikbare softwarecomponenten voor het Java-platform. Ze beschrijven het gedrag en de eigenschappen van Java-componenten die voornamelijk uitgevoerd worden aan de client zijde van een client/server systeem. Server beans of Enterprise JavaBeans (EJB) daarentegen, worden aangewend voor het ontwikkelen van gedistribueerde, schaalbare en uitbreidbare applicatieservers. De uitbreidbaarheid wordt bereikt door de mogelijkheid om EJB's in te `pluggen' bij de server en zo de functionaliteit van de server uit te breiden. Zoals gewone JavaBeans van verschillende ontwikkelaars kunnen gecombineerd worden tot een custom client, kunnen EJB's van verschillende ontwikkelaars samengesteld worden tot een custom server. Bovendien kunnen deze platform-onafhankelijke EJB's gebruikt worden in elke EJB-compatibele server zonder hercompilatie. In tegenstelling tot standaard Java Beans beschikken EJB's over het algemeen niet over een gra sche interface, daar ze via de EJB-server kunnen worden gecon gureerd. De con guratie van de EJB gebeurt aan de hand van een bean-descriptor, opgesteld in XML. De enterprise beans worden opgeslagen in een EJB-container, onder het beheer van een EJB server. De EJB-container biedt onder andere persistentie, schaalbaarheid, transactie management en versiebeheer aan de beans die erin vervat zijn. Op die manier dient de programmeur zich niet te bekommeren om de interne implementatiedetails van de betreffende server. Wanneer een bean bijvoorbeeld een commit-opdracht geeft, zal de omvattende container ervoor zorgen dat de transactie correct wordt doorgevoerd. Een client kan gebruik maken van de serverfunctionaliteit door het uitvoeren van methodes van een plaatselijk EJB-object of proxy-object. Dit EJB-object heeft dezelfde interface als een EJB-component op de server (de `remote interface'). Elke actie uitgevoerd op het EJBobject wordt automatisch doorgevoerd naar de server-component die dan het eigenlijke werk zal uitvoeren. Dit gebeurt via RMI of Remote Method Invocation. De client kan met het proxy-object werken als ware het de eigenlijke servercomponent. De twee types Enterprise Javabeans zijn session beans en de entity beans :
Session beans worden geassocieerd met een welbepaalde client en zijn over het al-
gemeen niet persistent. Telkens een gebruiker een connecie opzet met een server (bv. opvragen van een webpagina) kan er een instantie van een session bean gecreeerd worden om met deze gebruiker te communiceren.
Entity beans zijn persistent en kunnen overweg met meerdere gebruikers terzelfder-
tijd. Een enkele entity bean-instantie kan dus door verschillende clients worden gedeeld. Bovendien `overleeft' een entity bean een shutdown van de server, in tegenstelling tot session beans. Entity beans worden vooral gebruikt bij de communicatie met databanken. Ze kunnen bijvoorbeeld het resultaat van een databank-query incapsuleren als een object.
Wanneer nu een client een EJB-object wil creeren wordt door middel van JNDI of Java Naming and Directory Interface (waarmee de server de beschikbare diensten bekend maakt) de home interface van de gewenste klasse geselecteerd. De home interface bevat methodes om een object aan serverzijde te creeren. Deze interface beschrijft tevens hoe een client programma 50
Figuur 2.26: Een Enterprise Java Bean in zijn context of een andere bean deze enterprise bean kan zoeken in of verwijderen uit zijn container. Via RMI kan aan de container gevraagd worden om de servercomponent op te stellen en een proxy-object terug te geven aan de client (een soort `spiegel' van het eigenlijke object op de server). Alle acties op het proxy-object worden doorgevoerd op de corresponderende bean aan de serverzijde. De remote interface beschijft de methodes van de bean, of dus wat de bean kan doen. De client (of een andere enterprise bean) roept de methodes, gede nieerd in de remote interface, op om de business logica gemplementeerd in de bean te activeren. Acties op het proxy-object worden dan automatisch doorgegeven aan de server. De bean aan de serverzijde kan naast JNDI ook gebruik maken van Callback methodes en de EJBContext om te communiceren met zijn container:
Callback Methodes: deze worden door de container aangewend om de bean te ver-
EJBContext: dit is een referentieobject naar de container, bevat in de bean. Het laat
wittigen van een actie (bv. opslaan/verwijderen van de bean), zodat de bean eerst nog de nodige acties kan tre en. de bean toe om informatie op te vragen in verband met de client, remote interface of transacties.
Een voorbeeld van een eenvoudige Enterprise JavaBean kan gevonden worden in de appendices.
2.2.6 JDBC De Java Database Connectivity (JDBC) technologie is een API die toelaat quasi elke relationele databron te raadplegen vanuit de Java programmeertaal. Het ondersteunt connectiviteit met een groot aantal SQL databanken. De nieuwe JDBC standaard levert zelfs de mogelijkheid om andere tabulaire bronnen te raadplegen, zoals rekenbladen en zgn. at les. 51
Figuur 2.27: Enterprise Java Beans binnen de applicatieserver Dankzij de JDBC API kunnen ontwikkelaars steunen op het "Write Once, Run Anywhere" concept van het Java platform voor platform-onafhankelijke applicaties van industriele sterkte die de toegang vereisen tot enterprise gegevens. Een dergelijke uniforme toegangwijze is een noodzaak gezien het groot aantal databanken dat elk via een eigen taal wordt aangestuurd. Via een JDBC-driver kan een ontwikkelaar eenvoudig en op een uniforme wijze toegang krijgen tot data uit heterogene omgevingen. Deze driver verzorgt de communicatie tussen het betre ende database management system (DBMS) en de JDBC technologie, zodat de programmeur hiervan wordt ontlast. Bij het ontwikkelen van de JDBC API hield men drie doelen voor ogen: JDBC zou een API op SQL-niveau worden JDBC zou gebruik maken van de ervaring van bestaande database APIs JDBC moest een simpele API worden
Met een SQL-niveau API bedoelt men dat het mogelijk zou worden om SQL-statements in te bedden in Java API oproepen. Hoewel alle statements dus in SQL worden opgesteld, zal JDBC ze indien nodig vertalen naar statements die de betre ende databank verstaat. Omgekeerd worden ook de resultaten gegenereerd door de databank vertaald naar Java variabelen en eventuele Java excepties. De JDBC API is niet de eerste die steunde op het idee databanktoegang uniform te maken. Bij de ontwikkeling steunde men immers op de ideeen van een gelijkaardige API, namelijk de Open Database Connectivity (ODBC). ODBC werd ontwikkeld om een standaard vast te leggen voor datatoegang onder een Windows omgeving. ODBC was op bepaalde gebieden echter nodeloos complex, onder andere door het feit dat complexe taken werden vermengd 52
Figuur 2.28: JDBC-driver type 1
Figuur 2.29: JDBC-driver type 2 met de simpelere en meer algemene functionaliteit van de API. Om dus een eenvoudige taak te kunnen implementeren werd je verplicht kennis te hebben van de totale API. JDBC steunt op de ideeen van abstractie die opgenomen zijn in de ODBC API en er werd een mapper gecreeerd die JDBC-connectiviteit leverde aan ODBC-compatibele databanken. Men opteerde ervoor om een exibeler en simpelere API te maken die eenvoudige en complexe taken scheidt op interface-niveau. Het enige alternatief voor JDBC is het programmeren van een eigen abstractielaag, wil men databank-onafhankelijke code produceren. Pas nadat deze abstractielaag is afgewerkt kan er aan de eigenlijke applicatie begonnen worden. Hoewel men onder C en C++ de ODBC standaard als abstractielaag zou kunnen aanwenden, is deze niet platform-onafhankelijk. Bovendien laat JDBC toe dat de server applicatie in run-time besluit met welke databank een connectie wordt opgezet. De JDBC-drivers worden opgedeeld in 4 types:
Type 1: hierbij wordt een mapping gebruikt om toegang te krijgen tot de databank
Type 2: Native API drivers die direct communiceren met de databank.
Type 3: Generic network drivers. De JDBC driver van de client gebruikt sockets om
(bv. een JDBC-ODBC brug).
een verbinding op te zetten met de middleware applicatie op de server. Deze vertaalt dan op zijn beurt de requests naar de speci eke API. Dit soort drivers is bijzonder
exibel vermits er totaal geen code dient te worden genstalleerd op de client en een enkele driver toegang kan krijgen tot meerdere (heterogene) databanken. 53
Figuur 2.30: JDBC-driver type 3
Figuur 2.31: JDBC-driver type 4
Type 4: Over een netwerk protocol communiceert de driver direct met de databank op de server.
De volledige JDBC-architectuur wordt weergegeven in Figuur 2.32. 2.3
Distributed Authoring and Versioning
Bij de ontwikkelen van een repository waartoe meerdere auteurs tegelijkertijd kunnen bijdragen, is er nood aan een distributed authoring system. Men moet immers voorkomen dat de ene auteur ongewild de veranderingen van een andere auteur overschrijft. Het standaard HTTP-protocol heeft geen locking-voorzieningen en is bijgevolg niet afdoende voor het uploaden of opvragen van documenten van en naar de repository. Het WebDAV-protocol is een uitbreiding op het HTTP-protocol dat extra methodes speci eert die net deze mogelijkheden voorzien, evenals uitgebreidere management methodes die toelaten documenten van op afstand te verplaatsen en manipuleren. Hierna volgt een korte bespreking en vergelijking van beide protocols.
54
Figuur 2.32: De JDBC architectuur GET /mypages/page.html HTTP/1.0 User-agent: NCSA Mosaic for the X Windows System/2.5 Accept: text/plain Accept: text/html Accept: application/postscript Accept: image/gif
Figuur 2.33: Voorbeeld van een HTTP-request
2.3.1 HTTP Het Hypertext Transfer Protocol (HTTP) is een client/server gebaseerd protocol binnen de applicatielaag, voor de verspreiding van hypertekst, graphics, animaties, geluid en andere multimediabestanden. Uit de naam blijkt reeds dat HTTP het hyperlinking concept ondersteunt. Referenties binnen bestanden kunnen dus nieuwe transfers impliceren. Elke webserver omvat, naast de documenten die het beschikbaar maakt, een HTTP daemon; een programma ontworpen om te wachten op HTTP-requests en deze af te handelen van zodra ze arriveren. Dergelijke requests worden verstuurd door een HTTP-client, bijvoorbeeld een web browser, door hyperlinks te activeren of een URL op te geven. Deze request wordt gestuurd naar het Internetadres, zoals geimpliceerd door de URL. Daarnaast bestaat de request tevens uit de protocolversie, de request-methode, client-informatie en een eventuele berichtinhoud. Een voorbeeld HTTP-request wordt afgebeeld in Figuur ??. Hierbij is `GET' een HTTP-methode, gebruikt om een bestand of andere informatie op te vragen van de server. Andere HTTP-methodes zijn:
POST: gebruikt bij het doorgeven van data aan de server, na het invullen van een form.
HEAD: vaak gebruikt (door de browser) om na te gaan of de inhoud van het bestand
Deze data worden toegevoegd aan de body van de HTTP-request.
55
HTTP/1.1 200 OK Date: Wed, 04 Jul 1999 21:12:42 GMT Server: Apache/1.3.1 (Unix) Last-Modified: Fri, 03 May 2000 20:01:12 GMT Content-Length: 7482 Connection: close Content-Type: text/html ... [data] ...
Figuur 2.34: Voorbeeld HTTP-response is gewijzigd na een bepaalde datum, alvorens het volledige document af te halen van de server. Vermits het web oorspronkelijk een read/write omgeving moest worden, werden er nog additionele methodes voorzien, die echter in weinig clients en servers e ectief werden gemplementeerd, omwille van veiligheidsredenen. In intranet omgevingen, worden ze dan wel weer vaak aangewend:
PUT: gebruikt om een object up te loaden naar de server.
DELETE: verwijdert een document van de server.
LINK: creeert een hyperlink tussen de gespeci eerde pagina's.
UNLINK: verwijdert de link tussen pagina's.
De server antwoordt op dergelijke requests met resultaatcode, evenals de protocolversie, server- en meta-informatie en eventuele objectinhoud. Een voorbeeld wordt weergegeven in Figuur 2.34.
2.3.2 WebDAV WebDAV werd ontwikkeld als een verzameling extensies op het hypertext transfer protcol (HTTP). HTTP/1.1 werd immers ontworpen om nieuwe methodes toe te laten. De DAV staat voor \Distributed Authoring en Versioning", de mogelijkheid om met meerdere gebruikers asynchroon en op verschillende fysische locaties te werken aan een zelfde webdocument, zonder elkaars werk te compromitteren. WebDAV gaat evenwel nog iets verder, vermits er totaal geen beperking wordt opgelegd op het type webdocument. Vermits WebDAV werkt over HTTP biedt het een groot aantal voordelen die FTP niet kan leveren. Het gaat hier bijvoorbeeld om sterke autorisatie, encryptie, proxy-ondersteuning en caching. Het is waar dat men bepaalde van deze voordelen kan bekomen onder SSH, maar de HTTP infrastructuur is veel wijder verspreid en kan steunen op een reusachtig aantal tools, ontwikkelingsbibliotheken en applicaties. 56
Voordelen van WebDAV Werkgroepen kunnen simultaan documenten editeren en publiceren op het web. Het
locking mechanisme voorkomt overschrijf-con icten. De fysische locatie van de auteurs heeft geen belang.
WebDAV kent geen restricties wat betreft het type web-document. Er is ondersteu-
ning voorzien voor HTML en XML authoring, maar er kan even goed gebruik worden gemaakt van bestaande wordprocessor, spreadsheet, tekst en gra sche formaten.
WebDAV en HTTP voorzien een standaardinterface voor een groot scala aan reposi-
tory systemen, zoals documentbeheer, con guratiemanagement, bestandssystemen en databanken. De hele repository kan gebruikt worden als een netwerk-bereikbaar bestandssysteem.
Er wordt gewerkt aan ondersteuning voor ingebedde systemen. Dit zou resulteren in een
volledig nieuwe klasse van `web-enabled' apparaten. Bedenk bijvoorbeeld een digitale camera met WebDAV ondersteuning die automatisch getrokken foto's uploadt naar een web-server (via een ingebouwde cellulaire modem).
WebDAV voorziet HTTP-extensies die de volgende mogelijkheden toevoegen aan het standaard HTTP-protocol:
Overschrijf-preventie: belet dat meer dan een persoon tegelijkertijd aan een zelfde
Properties: WebDAV biedt de mogelijkheid om informatie omtrent de opgehaalde
Namespace-beheer: de consistentie van de benamingen gebruikt door de collecties
document werkt. Dit voorkomt het zogenaamde \lost update probleem", waarbij aanpassingen door de ene auteur onbewust door de andere worden overschreven.
resources te creeren, verwijderen en opvragen (bv. auteur, datum van laatste aanpassing,..). Het is eveneens mogelijk om in de properties hyperlinks in te voegen tussen verschillende resources, ongeacht het type. van documenten wordt beheerd en gecontroleerd bij het aanmaken en verwijderen van documenten. Het is bovendien mogelijk om een lijst op te vragen van alle documenten in een zekere collectie.
De volgende mogelijkheden zullen in toekomstige versies van het WebDAV protocol worden gemplementeerd:
Versiebeheer: de mogelijkheid om belangrijke revisies van een document op te slaan
voor latere raadpleging. Versiebeheer laat eveneens gelijktijdige ontwikkeling toe: twee of meer auteurs kunnen werken aan het zelfde document in parallelle tracks. Het automatisch versiebeheersysteem houdt de opeenvolgende modi caties bij, aangemaakt door clients die zich onbewust zijn van het versiebeheer. Hoewel de V in WebDAV voor Versioning staat, laat deze functionaliteit dus nog wat op zich wachten.
57
Geavanceerde collecties: evenals een symbolische link in een bestandssysteem zal
Toegangscontrole: de mogelijkheid om de toegangsrechten tot een zeker document
het mogelijk zijn om een referentie toe te voegen aan een collectie, die verwijst naar om het even welk document op het web. Het zal eveneens mogelijk zijn om een zekere ordening op te leggen aan de documenten binnen een collectie. te limiteren op basis van authenticatie van de gebruiker. Momenteel gebeurt de authorisatie nog op collectie niveau en niet op documentniveau.
Soorten clients Eens de DAV-server werd gecon gureerd en on-line is kunnen DAV-clients hierop inloggen om bestanden te delen:
Stand-alone clients: Voor zowat elke programmeertaal bestaat er wel een WebDAV
Web browser: Microsoft Internet Explorer ondersteunt de DAV extensies in de browser
Web interface: Een van de doelen die WebDAV stelt is de mogelijkheid om bestanden
API of module die programmeurs toelaat om een eigen interface te schrijven voor de DAV server. Bijgevolg zijn er onder elk operating system reeds gra sche en commandolijn WebDAV clients beschikbaar. Vele authoringtools beschikken tegenwoordig reeds over een ingebouwde WebDAV-client voor onmiddellijke publishing vanuit de authoringomgeving. zelf. Het is dus eenvoudig om via de webbrowser toegang te krijgen tot een WebDAV server. IE is momenteel de enige browser die dit ondersteunt, maar andere browsers zullen weldra volgen. Onder Windows biedt Microsoft de mogelijkheid om een DAVserver te koppelen aan het lokaal bestandssysteem (Microsoft Webfolders). Op die manier kunnen de bestanden gemanipuleerd worden via de standaard drag & drop functionaliteit. te delen via een bestaande WWW-infrastructuur (bv. via forms). Dit heeft als voordeel dat de client niet over DAV-enabled software dient te beschikken. Uiteraard is deze aanpak nogal omslachtig voor intensief gebruik.
De WebDAV extensies op het HTTP-protocol omvatten de volgende methodes:
COPY en MOVE: verplaatsen en kopieren van een resource.
MKCOL: creatie van een nieuwe collectie op de server.
PROPFIND: weergeven van de properties van een resource.
PROPPATCH: instellen van de properties van een document.
LOCK en UNLOCK: gedeelde of exclusieve lock plaatsen op een document.
58
Het is enkel mogelijk om een resource in zijn geheel te locken en dus niet een welbepaald onderdeel ervan. Ook op niet bestaande resources kan een lock geplaatst worden. Het gaat in dit geval dus eigenlijk om de reservatie van de betre ende naam. Elke lock heeft een zekere diepte. Diepte 0 betekent dat de lock enkel van toepassing is op de resource zelf. Diepte oneindig geeft aan dat de lock recursief wordt geerfd door alle leden van de hierarchie. Belangrijk hierbij is wel dat bij het maken van een kopie de lock op het brondocument niet wordt mee gekopieerd (in tegenstelling tot een move-operatie). Om te voorkomen dat gebruikers vergeten een document weer vrij te geven is elke lock voorzien van een time-out. Een lock moet dus op geregelde tijdstippen worden vernieuwd om in stand gehouden te worden. Het regelen van de locks en properties van een document gebeurt in XML-formaat. Figuur 2.35 geeft een voorbeeld weer van het antwoord dat de server terugzendt na het succesvol plaatsen van een exclusieve lock op een document. Vermits alle parameter bodies (maar niet de content bodies) in XML-formaat worden opgeslaan kan de client-applicatie via het PROPPATCH commando eveneens metadata opslaan in het property-schema. Hierbij kan men bijvoorbeeld denken aan een auteursnaam, referenties of aan timestamps. Deze `dead' properties worden dan opgeslaan in een databank. `Live' properties daarentegen (zoals de datum van de laatste aanpassing) worden in real-time bepaald bij het ontvangen van een request door een client.
2.3.3 Publishing systems: Cocoon Een web server op zich volstaat om simpele HTML-documenten en beelden terug te geven aan de client. Wanneer men echter meer complexe data gaat aanbieden, is er nood aan een manier om deze gegevens te gaan structureren en formatteren. Cocoon is een publishing framework, gemplementeerd als een Java Servlet. Cocoon werd ontwikkeld door Apache en laat toe om XML-documenten op de server om te zetten naar een ander formaat (bijvoorbeeld HTML of PDF) dat bruikbaar is voor de client. Hiervoor wordt gebruik gemaakt van o.a. DOM, XML en XSL technologieen. Veel belang werd gehecht aan het gescheiden houden van inhoud, weergave en logica. Elk van deze lagen kan afzonderlijk worden ontworpen en onderhouden, om zodoende de ontwikkelingstijd te minimaliseren en hergebruik te stimuleren:
XML creatie De content owners zijn verantwoordelijk voor de inhoud van het betre ende XML-bestand. Zij dienen enkel weet te hebben van de gebruikte DTD en moeten dus totaal geen rekening houden met de manier waarop het XML-document later zal worden verwerkt.
XSL verwerking De logica voor de transformatie van het XML-document is gescheiden van
de inhoud en bevindt zich in de logicsheets. Deze worden door de XML-processor ingelezen en toegepast op het brondocument.
XML rendering Het dynamisch gecreeerde document wordt tenslotte gerenderd door de toepassing van een XSL-stylesheet die de formattering bepaalt (bv. Conversie naar HTML, PDF, XHTML, enz.). 59
HTTP/1.1 207 Multi-Status Server: Microsoft-IIS/5.0 Date: Wed, 04 Aug 2000 21:52:58 GMT Content-Type: text/xml Content-Length: 310 Infinity http://www.domain.com/resources/doc.xml Second-604800 opaquelocktoken: d63b4gad-7dsc-43d6-fea5-00a0c91e6be4
Figuur 2.35: Antwoord van een WebDAV server bij het plaatsen van een lock
Figuur 2.36: Het Cocoon pijplijn model
60
Om dit alles te verwezenlijken werkt Cocoon volgens het pijplijnmodel (Figuur 2.36 op pagina 60). 1. De producer genereert een XML-document. De open structuur van Cocoon laat toe nieuwe producers, processors of formatters te schrijven en deze als het ware in te pluggen in het systeem. 2. De processor neemt de verwerking van dit document voor zijn rekening. Dit betreft over het algemeen een XSLT-transformatie voor het genereren van een nieuw statisch of dynamisch XML-bestand. 3. De formatter tenslotte levert het in het juiste formaat (opmaak) aan de client. Dit gebeurt allemaal op basis van verwerkingsinstructies opgenomen in het XML-document, speci ek voor Cocoon, van de vorm:
4. De resulterende output kan dan naar de client gestuurd worden. Vermits vrijwel alle werk dus serverside gebeurt, kan een client het resultaat met een simpele browser bekijken, zonder dat deze over ingebouwde XSLT-transformatiemogelijkheden dient te beschikken.
Cocoon 2.0 De volgende generatie van Cocoon, Cocoon 2.0, belooft een gigantische stap te betekenen in de wereld van publishing frameworks. Cocoon 1.x is nog voor een groot deel gebaseerd op de transformatie van XML via XSL en kent nog enkele serieuze beperkingen. Zo heeft het bijvoorbeeld geen grote impact op de beheerkost van grote sites. Terwijl een enkel XML document kan vertaald worden in een groot aantal verschillende client views, blijft er toch nog een aanzienlijk aantal documenten bestaan. Het is tenslotte nog erg moeilijk om inhoud, presentatie en logica ook e ectief te scheiden. Cocoon 2 is erop gericht om contracten tussen de verschillende lagen op te leggen en aldus de beheerkost te verlagen, in combinatie met precompilatie en geavanceerd geheugenbeheer. Bovendien zal het onderscheid tussen XSP, dynamische XML en statische HTML verborgen worden voor de gebruiker. Waar Cocoon vooral gericht was op het beheer van het XML onderdeel van een website, is Cocoon 2 in staat de gehele site te beheren. Een zogenaamde sitemap zal administratie toelaten vanuit een centrale locatie. Een sitemap is in principe een collectie pipelines die binnenkomende URL's matchen met voorgede nieerde regels en als dusdanig de Cocoon engine toelaten om de correcte acties uit te voeren op de betre ende pagina's. De sitemap stelt dus de centrale repository voor de webadministratie voor, die de URI-namespace beheert. Elke pipeline de nieert een generator, een of meerdere transformators en een serializer. De generator produceert XML-code (meer bepaald SAX2-events), de transformators verwerken deze code op de gepaste manier en de serializers produceren de gevraagde output. Een eenvoudig voorbeeld van een dergelijke sitemap werd afgebeeld in Figuur 2.37. 61
<sitemap> <process match="/press/en/*.html"> <parameter name="stylesheet" value="/styles/simple-press-html.xsl"/> <serializer type="html"/> <process match="/press/en/*.pdf"> <parameter name="stylesheet" value="/styles/simple-press-pdf.xsl"/> <serializer type="pdf"/>
Figuur 2.37: Voorbeeld sitemap
2.3.4 Ant Ant is een Java-gebaseerde build tool die steunt op XML voor de de nitie van de build bestanden. Uiteraard bestaat er reeds een groot gamma aan soortgelijke applicaties, zoals `make', `gnumake', `nmake',. . . Deze tools zijn echter over het algemeen shell-gebaseerd. Dit impliceert dat ze makkelijk uitbreidbaar zijn, maar tegelijk ook gebonden aan een enkel besturingssysteem. Bovendien treden er vaak problemen op bij verkeerdelijk gebruik van whitespace (bv. tab i.p.v. spatie). Gezien whitespace van geen belang is in XML-bestanden, overkomt Ant dit probleem al van bij de initiele parsing. Uiteraard voorziet ook Ant uitbreidbaarheid, maar dan op basis van Java klassen i.p.v. shell commando's. Gezien het feit dat Ant volledig in Java is geschreven, levert dit uiteraard een platform-onafhankelijke build-tool. Dit voorkomt dus tevens de nood om aparte shell scripts en batch bestanden te schrijven voor een applicatie die op meerdere besturingssytemen kan draaien. Elk build bestand (doorgaans `build.xml' genaamd) bevat een enkel project, bestaande uit een of meerdere targets. Een target omvat dan weer een verzameling tasks. Deze targets kunnen afhankelijk zijn van elkaar. Zo kan het aanmaken van een jar bestand slechts plaatsvinden na de compilatie. De afhankelijkheden kunnen gede nieerd worden aan de hand van XML-attributen.
Voorbeeld 2.17.
62
De volgorde van uitvoeren wordt dus niet bepaald door de locatie van een target binnen het build bestand. Ant zal wel trachten de targets uit te voeren in de volgorde waarin ze voorkomen binnen het depends-attribuut, zolang dit niet in con ict is met andere dependsstatements. De volgorde van uitvoeren voor bovenstaand voorbeeld is dus: t1-t2-t3-t4. Het gedrag van een taak kan verder worden bepaald door de de nitie van een verzameling properties en task lters. Hiermee kan de gebruiker bijvoorbeeld vastleggen op welk type bestanden de task wordt toegepast. Alle propertie-verwijzingen worden genoteerd tussen \$ f\ en \g".
Voorbeeld 2.18.
Ant voorziet reeds een groot aantal ingebouwde taken. Deze omvatten de belangrijkste bestandbeheer-operaties, zoals `deltree', `mkdir', `copy le',. . . en Java-gerelateerde operaties: `javac', `javadoc', `jar', `zip', . . . Ook meer complexe taken zoals `Telnet', `Clearcase' operaties en geluidsweergave zijn standaard beschikbaar. Uiteraard volstaat dit nog steeds niet voor bepaalde toepassingen en vandaar werd de mogelijkheid voorzien om zelf tasks te de nieren. Hiervoor dient de gebruiker een eigen klasse te schrijven die \org.apache.tools.ant.Task" uitbreidt, met setter-methodes voor elk attribuut. In Figuur 2.38 vindt men een voorbeeld van een dergelijke taak. Deze eigengede nieerde task kan worden opgeroepen in een build-bestand zoals te zien is in Figuur 2.39. Een volledig Ant build-bestand wordt tenslotte weergegeven in Figuur 2.40.
2.3.5 Doclet Javadoc is een tool, geleverd bij de Java Developers Toolkit (JDK), die toelaat declaraties en documentatie (commentaar) in een verzameling bronbestanden te parsen en er een set HTML bestanden uit te destilleren die de klassen, infterfaces, constructors, methodes en velden beschrijven. Via Javadoc doclets is het mogelijk om de uitvoer van Javadoc aan te passen. Een doclet is een programma, geschreven volgens de doclet API, dat de inhoud en het formaat speci eert van de te genereren output. Het is dus mogelijk om in plaats van HTML tevens platte tekst, SGML, XML, RTF, PDF en andere formaten te produceren. Daarenboven kunnen speci eke taken worden gede nieerd die normaal niet worden uitgevoerd bij de productie van APIdocumentatie. Zo kan er bijvoorbeeld een stylistische controle worden uitgevoerd (werden alle methodedeclaraties voorzien van commentaar,. . . ?). Sun voorziet reeds een standaard doclet voor HTML. Daarnaast bestaat er ook een experimentele versie van de MIF (Maker Interchange Format) Doclet. Dit uitvoerformaat kan worden ingelezen door Adobe FrameMaker en zo eventueel worden geconverteerd naar PDF, 63
package com.johndoestasks; import org.apache.tools.ant.BuildException; import org.apache.tools.ant.Task; public class Fout extends Task { private String fout; // Setter methode voor het `fout' attribuut public void setError(String fout) { this.fout = fout; } // Methode die de task uitvoert public void execute() throws BuildException { System.out.println(fout); } }
Figuur 2.38: Voorbeeld Ant taak
... ... <printfout fout="Bestand niet gevonden!" /> ...
Figuur 2.39: Oproep Ant-taak in een build-bestand
64
<project name="MijnJarProject" default="jar" basedir="."> <property name="bron" value="."/> <property name="doel" value="doe"/> <property name="jar" value="jar"/> <mkdir dir="${doel}"/> <javac srcdir="${bron}" destdir="${doel}"/> <mkdir dir="${jar}/lib"/> <jar basedir="${doel}" jarfile="${jar}/mijnjar.jar" /> <delete dir="${doel}"/>
Figuur 2.40: Voorbeeld Ant build bestand
65
import com.sun.javadoc.*; public class ListClass { public static boolean start(RootDoc root) { ClassDoc[] classes = root.classes(); for (int i = 0; i < classes.length; ++i) { System.out.println(classes[i]); } return true; } }
Figuur 2.41: Voorbeeld Java Doclet PS, RTF, MS Word en WordPerfect formaten via batch processing. Bovendien laat dit formaat toe om verschillende versies van eenzelfde document met elkaar te vergelijken. Tenslotte zijn er ook talloze doclets ontworpen door andere ondernemingen die nieuwe uitvoerformaten toelaten. Hierbij kan men bijvoorbeeld denken aan de Apache XML-doclet. Er zijn drie stappen vereist voor het ontwikkelen van een eigen doclet. Vooreerst dient er een Java klasse te worden geschreven die de package \com.sun.javadoc" importeert en de doclet API volgt. Vervolgens wordt deze klasse gecompileerd zoals eender welke andere Java klasse. De doclet kan tenslotte worden uitgevoerd door de \-doclet" optie aan te wenden bij het gebruik van Javadoc. Hieronder staat een elementair voorbeeld van een doclet die simpelweg de namen van alle geparste klassen uitschrijft.
Voorbeeld 2.19. De doclet in Figuur 2.41 kan worden uitgevoerd met het volgende commando:
javadoc -doclet ListClass -classpath $CLASSPATH$\lib$tools.jar MyClass.java
Voor de creatie van een meer complexe output kan het handig zijn om uit te gaan van de code voor de standaard doclet.
66
Hoofdstuk 3
Implementatie van een repository 3.1
De applicatie
Het einddoel is de ontwikkeling van een repository voor de opslag van broncode bestanden in XML-formaat. Gezien het universeel karakter van XML, is dit uiteraard de representatievorm bij uitstek voor het opslaan van data over een potentieel lange termijn. De enorme hoeveelheid XML-tools en applicaties die momenteel verkrijgbaar zijn impliceren reeds een quasi onbeperkt gamma aan mogelijkheden wat betreft verdere opslag, manipulatie en representatie van de opgeslagen gegevens. Broncode bestanden in het bijzonder worden gekenmerkt door sterke relationele verbanden, zowel binnen eenzelfde bestand als tussen bestanden onderling. Hiervoor kan er een beroep gedaan worden op een van de meest krachtige concepten die XML ons biedt: de XML Linking Language. Een repository waarin alle verbanden tussen de opgeslagen data worden beheerd, laat toe om ecient en doelgericht doorheen de mogelijks enorme hoeveelheid gegevens te navigeren. De meest voor de hand liggende mogelijkheden zijn evenwel de stimulatie van hergebruik binnen de onderneming, evenals de a eiding van statistische informatie.
3.1.1 Stimulatie van hergebruik Bij de constructie werd ervoor geopteerd om de broncodetaal te beperken tot Java. Zoals later zal blijken is het echter mogelijk om een zelfde concept te realiseren voor om het even welke andere brontaal. Telkens wanneer een programmeur een nieuwe klasse heeft geschreven kan hij of zij de betre ende bestanden in XML formaat uploaden naar een centrale server. Aan deze server is een zoekmechanisme gekoppeld. Dit laat toe dat ontwikkelaars die weinig contact hebben met elkaar, toch een volledig overzicht krijgen van alle beschikbare klassen. Aldus wordt het een stuk eenvoudiger om na te gaan of er reeds een klasse bestaat die een bepaald probleem aanpakt. Indien er een dergelijke klasse werd gevonden kan die op een van vier manieren worden hergebruikt: De hele klasse kan gewoon afgehaald worden. De klasse kan worden uitgebreid via overervingsmechanismen.
67
Men kan simpelweg een deel van de klasse kopieren (cut and paste) en inlassen in de
eigen code.
Er kan verkozen worden om zich te inspireren op basis van een oplossing voor een
gelijkaardig probleem en simpelweg de aangewende ideeen over te nemen.
Bovendien moet het mogelijk zijn om voor elke functie van de klasse extra informatie op te vragen. Hiertoe dient ook een manier te worden ontwikkeld om javadoc commentaar op te slaan in XML formaat en de nodige xlinks te leggen tussen source code en commentaar. Omgekeerd moet het ook mogelijk zijn om de commentaar bij een klasse op te vragen en van daaruit de source code voor een bepaalde methode op te vragen. Tenslotte moet men tevens aanverwante informatie kunnen opvragen. Wanneer een klasse bepaalde andere packages importeert of klassen/interfaces uitbreidt of implementeert moeten er ook links worden gelegd tussen beide entiteiten.
3.1.2 A eiding van statistische informatie Gedurende de conversie van Java source code naar XML moet het mogelijk zijn om extra informatie op te slaan in het resulterende XML bestand. Dit zou onder andere de auteursnaam, check-in of compilatie-datum en het aantal regels code kunnen bevatten. Zo zou het later mogelijk zijn om alle klassen van een bepaalde auteur op te vragen, na te gaan hoeveel code een bepaalde programmeur reeds heeft geschreven, hoeveel keer een bepaalde klasse reeds werd hergebruikt, etc. Indien de bronbestanden in groter detail worden geanalyseerd, kunnen er mogelijks zelfs heel bijzondere statistieken worden afgeleid. Stel bijvoorbeeld, dat er per klasse wordt bijgehouden hoeveel identi ers, variabelen, methodes, overervingen, kruisverwijzingen, enzovoort erin voorkomen. Dan is het in principe mogelijk om een complexiteitsmaat toe te kennen aan de klasse. Wanneer een klasse te complex blijkt te zijn, kan dit een aanduiding zijn dat deze mogelijks moet worden opgesplitst, wil men de complexiteit van het geheel beheersen. Tenslotte kan tevens informatie worden afgeleid uit de linkstructuur die er heerst tussen de bestanden in de repository. Dit laat bijvoorbeeld toe om de `populariteit' van een klasse te meten. Het betreft hier dan het aantal keer dat een zekere klasse in een andere context werd gemporteerd of uitgebreid. Men kan vervolgens overwegen om de veel gevraagde klassen verder uit te werken en al dan niet voor het grote publiek beschikbaar te maken (commercieel of aan de open source gemeenschap). Uiteraard kan men nog vele andere mogelijke toepassingen bedenken bij het analyseren van deze data, zoals het bijhouden van een tijdslijn, of de evolutie van een zekere klasse.
3.1.3 Extra functionaliteit Uiteraard kunnen er hierna nog tal van andere voorzieningen worden gemplementeerd. De XML voorstelling van de data biedt ons immers heel wat speelruimte: hieronder volgt een greep uit de mogelijkheden: Het gebruik van stylesheets laat toe om de bestanden op een aangename manier weer te
geven (o.a. via syntax highlighting en regelnummering). Eventueel kan er zelfs steeds 68
een canonische codevorm worden gegenereerd, ongeacht de vorm van het inputbestand. Bovendien is het mogelijk de weergave te wijzigen door enkel en alleen de stylesheet aan te passen. Aan de XML bestanden hoeft verder niks gewijzigd te worden. Via een XSLtransformatie is het bijvoorbeeld mogelijk om alle weergegeven broncodebestanden voor te stellen met een gelijkvormige spatiering en haakjesplaatsing, zonder daadwerkelijk iets te veranderen aan de inhoud van de XML-bestanden zelf. Zo wordt het eenvoudiger voor de gebruiker om klassen geschreven door verschillende auteurs toch op uniforme wijze door te nemen. Vermits alle verwante klassen worden gelinkt zou het mogelijk zijn om de afhankelijkhe-
den tussen de klassen onderling te bepalen. Op basis hiervan zou een build bestand kunnen worden gegenereerd. Dit geeft aan welke andere klassen vereist zijn om een bepaalde applicatie te compileren en in welke volgorde de compilatie dient te gebeuren. In dit geval is het makkelijker om enkel de vereiste klassen af te halen. Deze selectie en eventueel zelfs de packaging in een jar le en/of compilatie zou zelfs aan de serverzijde kunnen gebeuren.
Kenmerkend aan XML bestanden is de mogelijkheid om een DTD of XML Schema te
voorzien. Dit laat toe om bepaalde regels op te leggen. Zo kan men dus bepaalde programming rules opleggen en verzekeren dat deze worden nageleefd door alle werknemers.
Analoog wordt het mogelijk om ervoor te zorgen dat bepaalde conventies worden gevolgd.
Indien bijvoorbeeld van de ene dag op de andere een nieuwe regel zou stellen dat alle namen van constanten moeten worden voorafgegaan door een underscore, kan een eenvoudige XML parser worden opgesteld die alle klassen in de repository afgaat, de constanten eruit ltert en de notatie ervan wijzigt indien nodig. Het spreekt voor zich dat dit een heel delicate operatie is en men de nodige voorzichtigheid aan de dag zou moeten leggen bij het werkelijk implementeren van een dergelijke mogelijkheid. Wanneer bijvoorbeeld de benaming van publieke methodes of klassen zou worden aangepast, zouden de resulterende problemen en naamcon icten niet meer te overzien zijn.
3.1.4 De implementatie De eigenlijke implementatie gebeurt volgens een iteratief concept, meer bepaald het spiraalmodel waarbij voor elke complete iteratie een waterval model wordt aangewend. De bedoeling is om te starten met een prototype dat reeds de volledige cyclus van initiele source code conversie tot uiteindelijke weergave in een browser doorloopt. Uiteraard beperkt elk onderdeel zich in deze fase tot het absolute minimum. Vervolgens zal dezelfde cyclus nog een aantal maal doorlopen worden, waarbij er telkens extra functionaliteit wordt voorzien. Elke cyclus wordt voorafgegaan door een planning en het opstellen van use cases, RUP- en UML-schema's,. . . (zie ook appendices). Deze werkwijze voorkomt dat men pas laat in de ontwikkelingsfase merkt dat bepaalde onderdelen veel meer tijd in beslag zullen nemen dan oorspronkelijk werd gepland. Potentiele problemen kunnen zo immers reeds in een vroeg stadium worden gedenti ceerd. Het project kan opgebroken worden in een aantal discrete stappen. Om de eerste iteratie van het spiraalmodel te doorlopen, werd er voor elk onderdeel reeds een elementaire versie gemplementeerd: 69
Figuur 3.1: Een enkele iteratie uit het spiraalmodel
Figuur 3.2: Het spiraalmodel
70
Figuur 3.3: Schema van de top level elementen in het gegenereerde XML-bestand De conversie van Java code en Javadoc commentaar naar XML De insertie van xlinks in de resulterende XML-bestanden Het uploaden van de XML-bestanden naar de server Het accepteren en klasseren (opslaan) van de bestanden door de server en de gelijktijdige
extractie/beheer van link informatie.
Het toelaten bestanden op te vragen in een browser. Een eenvoudige search engine Een manier om statistische informatie op te vragen.
Java naar XML conversie Men kan zich de vraag stellen waarom er werd geopteerd voor Java als brontaal. Zoals uit de eerdere hoofdstukken reeds bleek, vormen Java en XML het perfecte duo voor het ontwikkelen van een dergelijke applicatie. Het was dan ook een logische keuze om Java als brontaal te selecteren, zeker gezien de nog steeds groeiende populariteit van de taal. Ook de relatief complexe grammatica en hierarchische verbanden tussen Java broncode bestanden zijn redenen voor deze keuze. Als het immers mogelijk is om een dergelijk project op te zetten voor een uitgebreide taal als Java, dan zou het weinig problemen mogen leveren om iets dergelijks te ontwikkelen voor gelijkaardig en minder complexe talen. Vooreerst diende er op louter logisch niveau te worden bepaald hoe het resulterende XMLbestand er zou uitzien. Er werd aanvankelijk besloten dat het gegenereerde XML bestand een element zou bezitten dat de Javadoc commentaar omvat, een element dat de code bevat en tenslotte nog een element waarin statistische informatie wordt opgenomen. Elk onderdeel zou uiteraard nog verder worden voorzien van XML style markup. Op deze manier konden de drie logisch verschillende types informatie reeds van elkaar scheiden worden om later belangenvermenging te voorkomen. Vervolgens diende vastgelegd te worden op welke wijze we de XML-inhoud van elk element e ectief gingen produceren. Wat het Javadoc gedeelte betreft werd gebruik gemaakt van een XML-doclet, ontwikkeld door Apache1 . Deze laat toe om, in combinatie met de Javadoc util, commentaar te extraheren uit een Java source bestand en deze van de nodige XML mark-up te voorzien. Vermits 1
http://www.apache.org
71
void MethodDeclaration() : {} { ( "public" | "protected" | "private" | "static" | "abstract" | "final" | "native" | "synchronized" )* ResultType() MethodDeclarator() [ "throws" NameList() ] ( Block() | ";" ) }
Figuur 3.4: Onderdeel uit de Java 1.1 grammaticabeschrijving deze versie naar een standaard aan het evolueren is, was het aangewezen hiervan gebruik te maken. De huidige versie is nog een beta, maar het zal later eenvoudig zijn over te stappen op een nieuwe versie van de XML doclet. Er werd in een later stadium toch voor geopteerd om de Javadoc XML in een apart bestand op te nemen, vermits de XML-doclet op deze wijze los van de Java source XML-generator zou kunnen evolueren. Een eventuele update naar de nale versie van de XML-doclet zou zo vrij pijnloos kunnen verlopen (enkel een stylesheet aanpassing is in zo'n geval vereist, zoals later zal aangetoond worden). Voor de conversie van de source code zelf bestaat er geen kant-en-klare klasse. De Java Developers Kit (JDK) voorziet evenwel een Java parser generator, genaamd JavaCC. Op basis van een grammaticabestand, dat de huidige Java syntax op formele wijze beschrijft genereert JavaCC een source code parser. Met behulp van deze parser kan Java Tree Builder (JTB), een Open Source applicatie, vervolgens een boomstructuur opstellen die het gehele broncode bestand opdeelt in nodes. Er diende nu nog een visitor klasse te worden geschreven (op dit moment Java2XML visitor gedoopt) die de nodes van de source code boom afgaat en alles van de juiste tags voorziet. Tegelijkertijd werd er eveneens statistische informatie bijgehouden en opgeslaan. Deze beperkt zich nog tot het aantal statements, klassen, methodes,. . . Het geheel werd vervolgens gebundeld in een Java2XML main klasse, zodat een enkele oproep het XML bestand creeert. De DOM-boom volgt dus als het ware de broncode boom. In Figuur 3.4 volgt een extract uit de grammatica beschrijving van Java (versie 1.1). Het betreft hier de beschrijving van een methodedeclaratie. Uiteraard worden de onderdelen ResultType(), MethodDeclarator(), NameList() en Block() zelf eveneens verder gede nieerd. Wanneer dit bestand `gevoed' wordt aan JTB, zal deze tool een grammatica-bestand produceren met ingebedde code. Op p73 volgt een (sterk ingekorte) versie van hetgeen wordt geproduceerd voor de bovenstaande methode-declaratie. Dit uitvoerbestand kan vervolgens ingelezen worden door JavaCC, die de gewenste broncode boom uitvoert, evenals generische visitor methodes voor het doorlopen van de nodes (elk grammaticaal token komt overeen met een node) van de boom. Voor elke productie van de grammatica zal een aparte klasse worden geproduceerd. Het spreekt voor zich dat dit de overzichtelijkheid ten goede komt, vermits grammatica's voor relatief complexe talen al snel meer dan 100 producties vereisen. JavaCC genereert de volgende klasse, zoals weergegeven op p74, voor de eerder geziene methodedeclaratie. De commentaar wordt door JTB louter voorzien om de ontwikkelaar bij te staan bij 72
MethodDeclaratin MethodDeclaration() : { NodeListOptional n0 = new NodeListOptional(); NodeChoice n1; NodeToken n2; ... ResultType n18; MethodDeclarator n19; NodeOptional n20 = new NodeOptional(); ... NodeToken n27; Token n28; {} } { ( ( n3="public" { n2 = JTBToolkit.makeNodeToken(n3); } { n1 = new NodeChoice(n2, 0); } | ... n17="synchronized" { n16 = JTBToolkit.makeNodeToken(n17); } { n1 = new NodeChoice(n16, 7); } ) { n0.addNode(n1); } )* { n0.nodes.trimToSize(); } n18=ResultType() n19=MethodDeclarator() ( ... )? ( ( n26=Block() { n25 = new NodeChoice(n26, 0); } | n28=";" { n27 = JTBToolkit.makeNodeToken(n28); } { n25 = new NodeChoice(n27, 1); } ) ) { return new MethodDeclaration(n0,n18,n19,n20,n25); \} }
Figuur 3.5: De door JTB gegenereerde code uit vorige grammaticabeschrijving 73
package syntaxtree; /** * Grammar production: * f0 -> ( "public" | "protected" | "private" | "static" | "abstract" | "final" | "native" | "synchronized" )* * f1 -> ResultType() * f2 -> MethodDeclarator()}} * f3 -> [ "throws" NameList() ] * f4 -> ( Block() $\vert $ ";" ) */ public class MethodDeclaration implements Node { public public public public public
NodeListOptional f0; ResultType f1; MethodDeclarator f2; NodeOptional f3; NodeChoice f4;
public MethodDeclaration(NodeListOptional n0, ResultType n1, MethodDeclarator n2, NodeOptional n3, NodeChoice n4) { f0 = n0; f1 = n1; f2 = n2; f3 = n3; f4 = n4; } public void accept(visitor.Visitor v) { v.visit(this); }
}
public Object accept(visitor.ObjectVisitor v, Object argu) { return v.visit(this,argu); }
Figuur 3.6: De door JavaCC gegenereerde code
74
public void visit(MethodDeclaration n) { n.f0.accept(this); n.f1.accept(this); n.f2.accept(this); n.f3.accept(this); n.f4.accept(this); } /** * f0 -> * f1 -> FormalParameters() * f2 -> ( "[" "]" )* */ public void visit(MethodDeclarator n) { n.f0.accept(this); n.f1.accept(this); n.f2.accept(this); }
Figuur 3.7: Extract uit de DepthFirstVisitor het manipuleren van deze klassen. Het geeft de namen van de velden in deze klasse weer (de kinderen van de methode-declaratie node), evenals de delen van de originele productie die ze representeren. Elk onderdeel van een dergelijke productie wordt voorgesteld als een onderdeel van de boom, inclusief de tokens. Alle gegenereerde bestanden worden ook nog eens onderverdeeld in packages om het bestandsbeheer te simpli eren. Voor de meeste toepassingen is het evenwel niet vereist deze klassen verder te manipuleren en kan men zich beperken tot het gebruik van de visitor klassen en de oproepende main klasse. JTB genereert automatisch twee interfaces: Visitor en ObjectVisitor, evenals hun standaardimplementaties: DepthFirstVisitor and ObjectDepthFirst. De Visitor interface omvat een methode-declaratie voor elke productie uit de grammatica, plus een methode-declaratie voor elk van de zes automatisch gegenereerde klassen. DepthFirstVisitor doet niets anders dan simpelweg elke node van de boom te overlopen volgens het diepte-eerst stramien en voor elk kind van de huidige node de accept() methode op te roepen. De ObjectVisitor interface is een uitgebreide versie van de standaard visitor die toelaat elke node als een object te incapsuleren. Het is natuurlijk de bedoeling dat de ontwikkelaar deze methodes gaat uitbreiden om de gewenste manipulaties uit te voeren. De standaard DepthFirstVisitor voorziet bijvoorbeeld de methode voor het bezoeken van een methode-declaratie uit Figuur 3.7. In het kader van de Java naar XML-conversie werd een eigen visitor klasse ontwikkeld die voor elk van de producties, de identi ers omsluit in de corresponderende XML-tags. De tag-namen komen overeen met dezelfde formele namen, zoals ze voorkomen in het grammaticabestand. Dit heeft wel tot gevolg dat de hoeveelheid meta-informatie vaak groter is dan de 75
<method_declaration> <modifier> static <primitive_type> boolean <method_declarator> <method_name> exampleMethod ( <modifier/> String opt ) ;
Figuur 3.8: Java2XML conversie omsluitende code. In bepaalde gevallen is een toename van de bestandsgrootte met een factor 10 mogelijk. Het is dus een afwegen van overzichtelijkheid en ecientie. Minder tags of kortere tag-namen zou resulteren in een minder uitdrukkelijke bestands-explosie, maar het zou een grote impact hebben op respectievelijk de functionaliteit of de leesbaarheid. Deze problematiek wordt later uitvoeriger besproken. Als voorbeeld van de werking van het Java2XML onderdeel van het project kan men een methode-declaratie van de volgende vorm beschouwen: Static boolean exampleMethod (String opt);
Dit wordt omgezet naar de XML-vorm uit Figuur 3.8. Tenslotte dient er nog een klasse te worden geschreven die het doorlopen van de broncode boom dirigeert. Een heel elementair programma kan er uitzien als in Figuur 3.9. Deze klasse roept de broncode parser aan en past ze toe op hetgeen vanuit standaard input wordt ingelezen. Deze invoer wordt gecompileerd, de broncode boom wordt geproduceerd en er wordt een diepte-eerst visitor genstantieerd om de boom te doorlopen. Uiteraard is deze klasse vrij nutteloos, vermits ze verder niets aanvangt met de broncode boom, maar het illustreert de algemene werking. De totale werking van de Java2XML component kan dus worden voorgesteld zoals in Figuur 3.10. 76
import syntaxtree.*; import visitor.*; public class Main { public static void main(String args[]) { JavaParser parser = new JavaParser(System.in); try { Node root = parser.CompilationUnit(); System.err.println("Java program parsed successfully."); root.accept(new DepthFirstVisitor());
}
}
} catch (ParseException e) { System.err.println("Encountered errors during parse."); }
Figuur 3.9: Een elementaire Visitor klasse
Figuur 3.10: Schema van de creatie van een XML source bestand
77
Figuur 3.11: Schema van de creatie van een XML Javadoc bestand Zoals reeds aangehaald wordt de Javadoc commentaar behandeld door de XML-doclet. Wanneer er zich nu op een gegeven moment een aanpassing van de Java syntax zou voordoen, dient er simpelweg op basis van het nieuwe grammatica-bestand een nieuwe parser en tree builder te worden gegenereerd. Vervolgens dient de visitor lichtjes te worden aangepast om de wijzigingen op te vangen. Dit laat toe het hele systeem nog te gebruiken bij het verschijnen van een nieuwe Java versie of zelfs een volledig verschillende programmeertaal. In de latere cycli van het Java-conversie onderdeel werden eveneens een DTD en een eenvoudig XML Schema opgesteld om de output van de Java2XML klasse te formalizeren. Beiden zijn terug te vinden in de appendices. Ook voor de output van de XML-doclet is een DTD voorzien, opgesteld door de Apache-werkgroep.
Insertie van Xlinks Na de conversie van Java broncode naar XML-bestanden beschikt men over een verzameling losstaande klassen. Om de verbanden tussen deze klassen bij te houden werd ervoor geopteerd gebruik te maken van Xlink, een van de krachtigste onderdelen van XML. Uiteraard diende er vooreerst te worden vastgelegd welke verbanden er beschouwd gingen worden en voor welke doeleinden ze zouden worden aangewend. Voorbeelden van dergelijke verbanden zijn algemene relaties, zoals de gemporteerde packages en gemplementeerde interfaces, maar eveneens verbanden binnen de eigenlijke code, zoals methode-oproepen toegepast op instanties van een externe klasse. De mogelijkheid om bidirectionele links en links met meerdere targets te de nieren zou in ieder geval van pas komen. Zo is het bijvoorbeeld niet enkel mogelijk vast te leggen welke klassen of packages door een zekere klasse worden gemporteerd, maar omgekeerd wel mogelijk om alle klassen die een zeker klasse importeren te bepalen. Zoals later zal blijken is het invoegen van deze xlinks in bepaalde gevallen een vrij complexe aangelegenheid. Vandaar dat het niet simpelweg mogelijk is om via een stylesheet (XSLtransformatie) het oorspronkelijke XML-bestand om te zetten naar een gelinkt bestand. Er zal dus wel degelijk een parsing moeten plaatsvinden. Hierbij was er keuze uit DOM- of SAX-parsing. Vermits elke node van de XML-boom slechts eenmaal zou moeten overlopen worden en de performantie van essentieel belang is (zeker gezien de grootte van bepaalde XML-broncode bestanden), werd er gekozen voor SAX-parsing. Dit is zonder twijfel de meest eciente parse-oplossing gezien de omstandigheden. Hieronder volgt een analyse van de links waarover een ideale XML repository zou kunnen beschikken. De verschillende linktypes worden telkens gellustreerd aan de hand van 78
voorbeelden. 1. Package informatie Een link van een import statement naar de bijbehorende package.
De regel import be.ac.rug.javaxml
wordt in een Java XML bestand opgeslaan als import be.ac.rug.javaxml .* ;
en wordt vervangen door: import <javalink xlink:type="simple" xlink:href="URL"> be.ac.rug.javaxml ;
waarin URL verwijst naar een XML bestand dat een index bevat met xlinks naar alle elementen in de betre ende package. Vermits elk element potentieel een xlink kan bevatten is het eveneens mogelijk om de link op te nemen in het `name' element: import be.ac.rug.javaxml ;
79
Er werd echter verkozen de naam voor alle xlink-elementen constant te houden, zodat ze er later makkelijk weer uit te lteren zijn (bv. voor de conversie naar HTML-links). Wat URL namespace management betreft: de URL steunt op de packagenaam plus klassenaam (en eventuele fragment identi er naar een methode). Er mag dus aangenomen worden dat deze steeds uniek is (vermits packagenames op hun beurt steunen op URI's). Een tweede mogelijkheid zou zijn om onmiddellijk al een extended link te voorzien naar elk element in de package, maar dit kan voor problemen zorgen indien er later bestanden bijkomen of verwijderd worden. Bij gebruik van simpele xlinks dient enkel het indexbestand aangepast te worden (iets dat bijvoorbeeld in batchverwerking zou kunnen gebeuren). Een link vanuit een javabestand naar alle javabestanden die dat bestand of de package waarin het is vervat importeren. Dit is een bijzonder moeilijke opgave en zou vereisen dat telkens er een nieuw bestand wordt toegevoegd aan de repository (of er een wordt verwijderd) dat alle bestanden in de gemporteerde packages worden aangepast. Elk java XML bestand zou over een extended link beschikken van de vorm: Java-bestanden die deze klasse importeren: <javalink xlink:type="extended"> <doc xlink:type="locator" xlink:role="URL-a" xlink:href="..."/> <doc xlink:type="locator" xlink:role="URL-a" xlink:href="..."/> ...
Voorgaande linktypes kunnen overigens gecombineerd worden d.m.v. bidirectionele extended links, opgeslagen in een extern bestand, indien er een xlink processor beschikbaar is die deze kan verwerken. Een dergelijke xlink heeft de volgende vorm: <javalink xlink:type="extended"> <doc xlink:type="locator" xlink:role="URL-a" xlink:href="..."/> <doc xlink:type="locator" xlink:role="URL-b" xlink:href="..."/> ...
80
xlink:to="URL-c"/>
...
2. Link naar alle klassen in bijbehorende package De regel package be.ac.rug.javaxml
wordt in een Java XML bestand opgeslaan als <package_declaration> <package>package <package_name> be.ac.rug.javaxml ;
en wordt vervangen door: <package_declaration> <package>package <package_name> <javalink xlink:type="simple" xlink:href="URL"> be.ac.rug.javaxml ;
waarin URL verwijst naar hetzelfde indexbestand zoals besproken in 1. Uiteraard zou het eveneens mogelijk zijn om onmiddellijk een extended link te voorzien in de klasse zelf, maar dit zou leiden tot de problemen zoals vermeld in de bespreking van linktype 1. 3. Links naar parent class/interfaces De regel public class Voorbeeld extends be.ac.rug.VB1 { ...
81
wordt in een Java XML bestand opgeslaan als <modifier>public class Voorbeeld <extends> extends be.ac.rug.VB1 ...
en wordt vervangen door: <modifier>public class Voorbeeld <extends> extends <javalink xlink:type="simple" xlink:href="URL"> be.ac.rug.VB1 ...
De werkwijze voor `implements' statements is vrijwel identiek, met dat verschil dat er dan ook extended links zijn toegelaten naar meerdere interfaces. Deze links lijken op de extended links uit de bespreking van linktype 1. zoals daar het geval was, kunnen ook hier inverse links worden voorzien van een klasse/interface naar alle bestanden die deze klasse of interface uitbreiden of implementeren. 4. Links vanuit @ tags Vanuit @see tags in javadoc commentaar een link naar de betre ende klasse
82
Vanuit @auteur tags een link naar het email adres van de auteur Vanuit additionele tags, zoals @revision. Deze zijn evenwel nog niet gestandaar-
diseerd, maar er zijn reeds concrete voorstellen in de maak.
Opmerking 3.1. Dit is perfect mogelijk vanuit het javadoc XML gedeelte. @-tags
worden echter niet apart gemerkt in het Java source XML-bestand. Bijgevolg zou er dus een extra parser moeten voorzien worden die de @-tags extraheert uit de commentaar secties. 5. Type declaraties Bij de instantiatie van een object kan een xlink worden voorzien naar de betre ende klassedeclaratie. Beschouw: JavaCCParser parser;
Dit wordt in een Java XML bestand opgeslaan als <modifier/> JavaCCParser parser
en wordt vervangen door: <modifier> <javalink xlink:type="simple" xlink:href="URL"> JavaCCParser
83
parser
Voorts kan eveneens de variabelenaam bij elk voorkomen gelinkt worden naar de betreffende klasse waarvan de variabele een instantie is. Linking van member variabelen en methode-attributen kan op een gelijkaardige manier. Het grootste probleem is hier het bepalen van de fully quali ed name van de klasse. De Java2XML parser houdt immers enkel rekening met de syntax en zal niet nagaan of de gebruikte klassen e ectief bestaan. De parser werkt immers enkel in op het huidige bestand. Wanneer er verschillende packages worden gemporteerd dienen al deze packages te worden doorzocht om de juiste klasse te bepalen (plus de bestanden in de huidige package). 6. Methodes Link van de methode-oproep naar de implementatie (of documentatie - zie later) van deze methode. Beschouw: parser.javacc\_input();
Dit wordt in een Java XML bestand opgeslaan als: <statement> <statement_expression> parser.javacc_input <arguments> () ;
en wordt vervangen door: 84
<statement> <statement_expression> parser. <javalink xlink:type="simple" xlink:href="URL"> javacc_input <arguments> () ;
waarbij URL verwijst naar de implementatie van de javacc input functie van de JavaCCParser klasse. Ook hier duikt het probleem op dat de syntax parser niet nagaat of gebruikte methodes/variabelen wel bestaan of werden genitialiseerd. Bovendien wordt de methode zelf niet apart gemarkeerd. Daarnaast treden nog enkele bijkomende problemen op, onder andere: Er dient gedetecteerd te worden of het wel om een methode-oproep van een in-
stantie gaat. Het kan immers ook om een static method van een klasse gaan. De syntax parser gaat dit niet na. Indien het om een static method gaat zouden alle klassen van de huidige en de gemporteerde packages moeten gecontroleerd worden. Er kan reeds sprake zijn van een fully quali ed name bij de oproep (zoals "java.io. Printwriter.XXX") of het kan daarnaast ook om een native method gaan (zoals "System.exit(1)"), die deel uitmaakt van een impliciet gemporteerde package. Er moet gecontroleerd worden of het wel om een methode gaat. Dit is niet gemarkeerd in het XML bestand (vb: "File.seperator") Wanneer de klasse een andere klasse uitbreidt kan het zijn dat de methode in een van de voorouders werd gemplementeerd. Dit dient dus recursief te worden onderzocht. Dit geldt eveneens voor alle klassen in de huidige en de gemporteerde packages. Er kan sprake zijn van overloading in welk geval er naar de juiste implementatie moet worden verwezen op basis van de meegeleverde argumenten. In geval van overriding moet naar de 'dichtste' implementatie worden verwezen. De methode kan worden uitgevoerd op een object dat de uitvoer is van een andere functie, zoals (x.toString()).substring(0,10); Mogelijks treedt er een vorm van casting op, zoals "((String)Vector.elementAt(3)). toUpper()".
Dit alles maakt dat het linken van methodes een bijzonder complexe zaak wordt. 85
7. code en implementatie Er kunnen links worden voorzien van de klassenaam/methodenaam naar de bijbehorende documentatie en omgekeerd. In de Javadoc XML bestanden volstaan simpele links, in de Java source bestanden kunnen simpele links worden voorzien bij de klasse en methode de nities en kunnen de links bij methode-oproepen (zie paragraaf 6.) worden uitgebreid tot extended links (zoals in paragraaf 1). 8. extra Daarnaast zijn er in nog enkele andere links mogelijk, bv. links naar member variabelen en attributen. De syntax is hierbij equivalent met de links in sectie 5 (type declaraties). Bovendien zijn links denkbaar naar alle mogelijke versies van een bepaalde klasse, links vanaf een methode-implementatie naar alle plaatsen waar deze methode wordt gebruikt en dergelijke.
Gebruik van Xpath/Xpointer Wanneer er niet simpelweg naar een klasse wordt gelinkt, maar wel degelijk naar een welbepaald element van een XML bestand (bv. een methode), dan zal men gebruik maken van fragment identi ers in de URL. Hiertoe wordt gebruik gemaakt van een Xpointer uitdrukking die dan weer steunt op een Xpath expressie. Voor deze toepassing volstaat het om te verwijzen naar een welbepaalde ID. Bijgevolg zullen alle klassen en methodes moeten voorzien worden van een ID, zowel in de source code als in de javadoc XML bestanden. Voor deze ID's volstaat de methodenaam (eventueel voorzien van de parameters in het geval van overloading). Voor de eigenlijke URL wordt best gebruik gemaakt van een relatieve URL, op basis van het classpath. Bij de conversie naar HTML kunnen dan de eigenlijke servernaam en repository basis directory eraan worden toegevoegd. Een URL die verwijst naar de functie 'calculate()' van een klasse 'Voorbeeld' in een package 'be.ac.rug.xlink' kan er dus als volgt uitzien: /be/ac/rug/xlink/Voorbeeld.java.xml#xpointer(id("calculate"))
Overigens rest er nog het probleem dat de syntax parser zich beperkt tot het te parsen bestand. Bij de link insertie zouden alle gemporteerde, extended en implemented klassen of interfaces eveneens recursief moeten geparst worden (en dat voor elke instantiatie, methodeoproep,...). Wanneer nu bepaalde packages slechts toegankelijk zijn via het CLASSPATH of opgenomen zijn in een .JAR dient de functionaliteit voor het opvragen van deze bestanden eveneens te worden gemplementeerd.
De implementatie Wat link-type 1.b betreft werd er uiteindelijk besloten om dit niet in het XML-bestand op te slaan, maar dynamisch te bepalen op basis van een databank, vermits die informatie gedurig onderhevig is aan verandering. Hetzelfde geldt voor links van het type 2. Dit kan vergeleken worden met de mogelijkheid om xlinks in een apart bestand op te slaan (los van de bron- of doelbestanden). Omwille van de ecientie werd er evenwel geopteerd om dit soort verbanden in een relationele databank te stockeren. De grootste aandacht werd echter besteed aan de links betre ende methodes en typeverwijzingen. Zoals uit de voorgaande analyse bleek kan de bepaling van de fully quali ed name 86
in sommige gevallen bijzonder moeilijk zijn. Daar staat echter tegenover dat net deze links van vitaal belang zijn, wil men een makkelijk navigeerbare repository ontwerpen. Het moet immers mogelijk zijn om door op een methode-oproep (bv. \anObject.aFunction(anArg)") te klikken, de implementatie van de overeenstemmende functie van de correcte klasse op te roepen. Hiervoor moet de parser dus de volledige naam van de corresponderende klasse bepalen. Mogelijks is \anObject" immers een klassenaam en \aFunction" een static methode. Zoniet, kan de klassenaam teruggevonden worden in een declaratie hogerop (bv. \MyClass anObject;"). Vermits er gebruik wordt gemaakt van SAX parsing is het echter niet mogelijk om terug te keren in de XML-stream, wanneer de parser een methode-oproep tegenkomt. Elke instantiatie van een klasse wordt dus door de LinkInsertor klasse opgeslaan in een hashmap (dictionary). Wanneer de parser nu op een methode-oproep stuit, wordt eerst deze lijst overlopen om de corresponderende klassenaam terug te vinden. Tenslotte weet de parser nog steeds niet de fully quali ed klassenaam. De \MyClass' klasse kan immers opgenomen zijn in een gemporteerde package. Vermits niet al deze packages aanwezig moeten zijn bij de linkinsertie, kan de packagenaam op dat moment niet worden bepaald. Ook de beperking opleggen dat alle gemporteerde packages aanwezig moeten zijn zou niet veel helpen, vermits het in real-time parsen van extra bestanden bij elke objectinstantiatie een enorme overhead met zich mee zou brengen. Gelukkig heeft de parser wel een idee van de mogelijke plaatsen waar een klasse die in het huidig bestand wordt gebruikt zich kan bevinden. Ofwel is deze klasse terug te vinden in dezelfde package als de huidige klasse, ofwel bevindt ze zich in een van de gemporteerde packages. Dit omvat dus ook de packages die standaard worden gemporteerd (cfr. \java.io"). De voorgaande analyse liet ons toe een package te realiseren die deze linkinsertie realiseert. Verdere uitbreidingen lieten zelfs toe om een hele directorystructuur (bv. een hele package) af te scannen naar Java bron-XML bestanden en Javadoc-XML bestanden en deze van links te voorzien. Hetzelfde geldt overigens voor de XML-conversie. Nu diende er nog beslist te worden of de conversie en/of link-insertie aan de client-zijde, dan wel aan de server-zijde zou plaatsvinden. Vermits het parsen en verwerken van grote packages een vrij intensieve aangelegenheid kan zijn, werd er geopteerd om dit gedeelte aan de client-zijde uit te voeren om te voorkomen dat de server overbelast geraakt bij grote hoeveelheden requests. Het zou echter slechts een kleine aanpassing vergen om de conversie aan de server-zijde te laten plaatsvinden, mocht dit ooit nodig zijn.
Client/Server communicatie Eens de bronbestanden werden geconverteerd, moeten ze op de een of andere wijze worden overgebracht naar de server. Tijdens een initiele cyclus van het spiraalmodel werd er gekozen voor een HTTP-upload (Figuur 3.12). Hiervoor werd gebruik gemaakt van een eenvoudige client en servlet die een HTML post-operatie kunnen behandelen. De client is in feite gewoon een web pagina, voorzien van forms en een post tag. Aan de serverzijde diende vervolgens een servlet te worden geschreven en genstalleerd die de attachments kan ontvangen, decoderen2 en opslaan (zie appendices voor de code). 2
De attachments worden immers voor verzending gecodeerd in Base-64 formaat, waarbij speciale tekens
worden omgezet in hun corresponderende ASCII-code, zodat een ASCII-stream wordt verkregen voor verzending volgens de MIME (Multi-purpose Internet Mail Extension) standaard.
87
Figuur 3.12: Extract uit een HTTP-upload pagina Voor de opslag en weergave van de XML bestanden werd een Apache webserver opgezet. Hierop draait vervolgens een Tomcat servlet engine (eveneens een open source `Jakarta' project van Apache). Deze servlet engine laat toe om Java servlets te schrijven voor het ontvangen en weergeven van XML bestanden. De post servlet ontvangt een ge-upload XML bestand en slaat dit op in een bestandssysteem. De bestanden worden opgeslagen in een relatief pad dat overeenkomt met de package-naam. Een bestand dat tot de package be.ac.rug.java2xml
behoort, zal bijvoorbeeld worden opgeslagen in het pad /be/ac/rug/java2xml/
Om de package-naam te bepalen dient de servlet evenwel eerst het binnenkomend XML document te parsen. Hiervoor werd beroep gedaan op een niet validerende SAX parser (in plaats van DOM). Vermits dit immers in realtime door de server moet gebeuren is dit de snelste manier van werken (zie ook bespreking SAX en DOM). De HTTP-post manier van werken, verloopt uitstekend indien slechts een auteur tegelijk aan een zekere klasse werkt. Indien evenwel meerdere ontwikkelaars schrijftoegang tot een bepaald bestand moeten hebben, kunnen er concurrency (gelijktijdigheid) problemen optreden. In een volgende cyclus werd dit opgevangen door het implementeren van een Webdav client/server systeem. Zoals bleek in de bespreking van WebDAV, ondersteunt dit protocol locking mechanismes om de eerder genoemde concurrency problemen op te vangen. Bovendien wordt het nu mogelijk om vanaf een externe computer bestanden in de repository te verplaatsen of verwijderen en subdirectories te creeren. Wat de serverzijde betreft is er niet direct een probleem, vermits er verschillende Webdav-server implementaties bestaan. De `mod dav' module voor Apache is er een van. Daarnaast zijn er nog andere implementaties in aanmaak, waaronder `Slide'. De nieuwe Tomcat versie, zal trouwens over een eigen Dav-implementatie beschikken, zodat het zelfs niet meer vereist zal zijn om Apache te gebruiken (Tomcat kan immers ook als webserver worden gebruikt). Anderzijds beschikt Apache tevens over een servlet-oplossing, namelijk `JServ'. Ook andere servlet-enabled webservers met WebDAVondersteuning kunnen gebruik worden. De gebruiker heeft dus keuze genoeg wat betreft het serverplatform. Nu was er een WebDAV client nodig. Er zijn verscheidene clients vrij verkrijgbaar op het web, maar de meeste kunnen enkel aangedreven worden via een gra sche interface. Vermits het uploaden in een later stadium geautomatiseerd moet kunnen worden (bijvoorbeeld door 88
de upload aan te drijven vanuit een Ant build-bestand), is er nood aan een command-line WebDav client. De enige bestaande versies zijn evenwel platform-afhankelijk. Vandaar dat er werd geopteerd om een eigen command-line client te schrijven, volledig in Java en dus makkelijk overdraagbaar. Gezien het grote aanbod aan WebDAV clients was het gelukkig niet nodig het wiel opnieuw uit te vinden. Er werd gebruik gemaakt van een bestaande Open Source Webdav-project, opgezet door de universiteit van Columbia. Verdere informatie hierover kan in de betre ende broncode worden teruggevonden. De gra sche user-interface werd gestript en ontleed, waarna de front-end volledig werd herschreven, zodat de client in zijn geheel vanaf de commandolijn kan worden bediend. In tegenstelling tot het HTTP-upload proces laten de bestaande WebDAV-implementaties niet toe dat er nog een vorm van post-processing gebeurt op de upgeloade data. Bijgevolg was het niet mogelijk om de packagenaam van een klasse aan de serverzijde te bepalen en zo de klasse in de correcte directory binnen de repository te plaatsen. Het was dus nodig om een shell klasse te schrijven rond de WebDAV-client om reeds aan de clientzijde de destinatiedirectory te bepalen en via het WebDAV MKCol-commando (`make collection') reeds de correcte directorystrucuur op te zetten op de server. Vervolgens kan het betre ende bestand upgeload worden naar die locatie. Tenslotte werden alle onderdelen van de Java2XML client (Convertor, Linkinsertor en WebDAV-client) in jars gegroepeerd voor distributie. Een Ant build-bestand werd voorzien voor eenvoudig gebruik.
Databeheer Tot dusver werd voornamelijk de clientzijde van de applicatie beschouwd. Eens de XMLbestanden werden ontvangen door de WebDAV server, dienen ze in de correcte directories te worden geplaatst. Gezien het type en de hoeveelheid data in de repository continu wijzigt, is het nodig om een centraal beheer van de verbanden tussen alle klassen op te zetten. Er moet immers voorkomen worden dat XML-bestanden, bij de weergave aan de gebruiker, links bevatten naar bronnen die niet (of niet meer) in de repository zijn vervat. Hiervoor werd gebruik gemaakt van een databank die alle wijzigingen aan de repository registreert. Een database request is immers een stuk ecienter dan het afscannen van een directorystructuur en parsen van de betre ende bestanden. Bovendien kan in een databank meer informatie worden opgeslaan dan zomaar uit het bestandssysteem kan worden afgeleid. Uiteraard zullen de nieuw toegekomen bestanden ook geparst dienen te worden om de nodige informatie af te leiden, maar dit kan nu in een batch proces op de server gebeuren i.p.v. in real-time bij een client-request. Het interval waarmee dit achtergrond proces wordt getart is instelbaar door de server administrator. Ook hier werd voor reden van ecientie beroep gedaan op SAX parsing om de klasse-informatie uit een XML-bestand te extraheren. Vermits de hele repository in Java werd gemplementeerd, werd er voor een JDBCdatabank gekozen. Bij de huidige implementatie wordt er gebruik gemaakt van de Open Source Java databank Hypersonic SQL. Dit voornamelijk omwille van de compacte grootte en eenvoudige con guratie, alsook de ecientie. Daarnaast ondersteunt Hypersonic de volledige SQL syntax en beschikt de databank over voldoende voorzieningen met betrekking tot veiligheid en integriteit. Gezien het om een JDBC databank gaat, kan er makkelijk overgeschakeld worden naar een andere JDBC-compatibele databank (bv. de databank die al voor een andere 89
applicatie op de server draait: MySQL, Oracle,. . . ) door enkel de JDBC-driver te wijzigen. Momenteel bevat de databank tabellen voor het opslaan van: klassenaam, packagenaam, bestandsnaam, auteur, incheck-datum, gemporteerde packages/klassen, gemplementeerde interfaces, uitgebreide klassen, methodes en methode-parameters. Hierbij is de combinatie packagenaam/klassenaam om evidente redenen telkens de primaire sleutel. Uiteraard kan er in de toekomst nog extra informatie worden toegevoegd, al zal dit de parsing natuurlijk wel iets vertragen. Voorbeelden van interessante gegevens zijn: modi ers, variabelen, constructors, aantal codelijnen/woorden/karakters per klasse of methode,. . . Deze databank bevat dus alle noodzakelijke informatie voor de manipulatie van de links in en tussen de XML-bestanden. Vooraleer een Xlink dus wordt omgezet naar een HTMLreferentie, zal eerst de databank worden geraadpleegd om na te gaan of het doel wel beschikbaar is. Zoniet, dan wordt de link simpelweg niet ingevoegd. Ook het eerder besproken probleem van de fully quali ed methodenamen is hiermee opgelost. De server kan in de databank immers nagaan welke van de mogelijke doelen in de extended link de correcte is. Tenslotte werden er enkele voorbeeld Enterprise Javabeans (EJB) ontwikkeld (zie appendix), die het gebruik van de databank verder zouden kunnen abstraheren. Gezien de relatief eenvoudige structuur van de huidige databank, levert dit niet direct een drastisch voordeel op, maar indien in de toekomst de databank functionaliteit zou worden uitgebreid, kan het nuttig zijn EJB's te hanteren voor de interactie met de databank.
Request handler Er moet uiteraard een mechanisme worden voorzien om XML-bestanden uit de repository op te vragen. Vermits alle bestanden in een pad staan dat overeenkomt met de packagenaam, vereenvoudigt dit de URL-conversie. In elke URL komt immers de packagenaam voor, die gewoonweg dient gemapt te worden op de directory relatief aan de repostory root. Niettemin worden alle requests over een servlet geleid. Dit laat nog enige vorm van processing toe, alvorens de documenten worden weergegeven. De request servlet zal het gewenste bestand immers in real-time parsen en uit alle potentiele (X-)links opgenomen in het XML-bestand de onbestaande links weg lteren. Er gebeurt eveneens nog een beperkte processing om de hieropvolgende XSLT-conversie te vereenvoudigen. De potentiele links bevatten immers nog geen URL's maar wel packagenames, vermits de bestandsstructuur van de server op het moment van de linkinsertie nog niet gekend was. In elke resulterende link dient overigens ook de request servlet te worden verwerkt, zodat er nooit direct naar het bestandssysteem wordt gelinkt en er dus vanuit server-oogpunt steeds een zekere vorm van controle (bv. custom logging) kan gebeuren op de acties van de client. Ook voor de package-navigatie werd een servlet ontworpen. Deze zal op basis van het argument, dynamisch een index-pagina creeren met links naar de bestanden (klassen en subpackages) die op het moment van de request aanwezig zijn in de betre ende directory (= package). Dit uiteraard ook met de bedoeling om het aantal dode links tot een absoluut minimum te beperken. Op basis hiervan is het mogelijk om in de front-end een volledige clickable package-structuur op te zetten, waarmee de gebruiker makkelijk kan navigeren naar de gewenste klasse. Voor de weergave van de XML bestanden werden enkele voorbeeld stylesheets geschreven 90
(zie ook appendices). Deze stylesheet geeft de code weer op een standaard manier, met highlighting van kernwoorden, variabelen, literals, enz. Dit kan uiteraard op eenvoudige wijze aangepast worden indien een andere weergave van de code gewenst is. Er werd verkozen om de conversie van XML naar een geldig HTML bestand volledig aan de server zijde door te voeren. Oudere browsers ondersteunen immers geen XML en stylesheets en aldus kan iedereen de bestanden bekijken. Zelfs de XSL-capabiliteiten van de huidige browsers staan nog niet volledig op punt. Indien de transformatie aan serverzijde gebeurt, ontvangt de client enkel de HTML-code en de browser dient dus totaal geen weet te hebben van de achterliggende XML. Om die conversie te realiseren werd er gebruik gemaakt van het Cocoon publishing system, een open source project van Apache dat als plugin kan gebuikt worden bij de Tomcat Servlet engine. Processing tags zullen dus in het XML bestand ingevoegd worden om de conversie correct uit te voeren. Bovendien werd in de Java2XML client een optionele normalize functie voorzien, die een standaard layout geeft aan de Java source output. Extra spaties en returns worden verwijderd en de diepte van insprongen, de positie van de accolades, enz. worden genormaliseerd. In combinatie met een custom stylesheet, krijgen broncode bestanden geschreven door verschillende auteurs toch eenzelfde uitzicht, wat het geheel eenvoudiger zal maken bij het opvragen van source code bestanden in een browser.
Search engine Uiteraard is een gebruiker die de package names niet kent niet veel met bovenstaand systeem. Het is dus nodig om een full text search engine op te zetten, zodat men kan zoeken op speci eke woorden die in de source code (meer bepaald in de commentaar) voorkomen. Zo wordt het eenvoudig om klassen op te zoeken die een welbepaald probleem aanpakken of om alle klassen van een zekere auteur op te vragen. Er werd uitgegaan van een bestaande Open Source Java search engine, genaamd BDDBot, maar deze werd compleet herwerkt. De originele engine werkte enkel op HTML bestanden, dus dit was een eerste probleem dat aangepakt diende te worden. Bovendien was het niet praktisch om meerdere woorden op te geven, vermits dit meerdere hits opleverde. Wanneer dus in een bestand drie van de opgegeven woorden voorkwamen, zouden er drie links naar het betre ende bestand teruggegeven worden. De engine struikelde bovendien over het gebruik van bepaalde tekens, zoals underscores en punten, waardoor ze aanvankelijk onbruikbaar was voor source code bestanden. Al deze probleempjes werden aangepast en bovendien werd een optionele extra mogelijkheid voorzien, namelijk het conjunctief zoeken. Dit laat toe om veel gerichter te gaan searchen omdat enkel bestanden die aan alle search keys voldoen weergegeven worden. Het geheel werd overigens gekoppeld aan de vorige klasse zodat ook hier op gezette intervallen de search databank wordt aangepast op basis van nieuwe, verwijderde of aangepaste bestanden. Ook hier gaat het om een thread die op de achtergrond loopt, zodat de gebruikers rustig kunnen blijven beroep doen op de engine. De grootste aanpassing ligt hem evenwel in het feit dat de search bot ontworpen was voor een eigen web server. De klasse die de request onderschept werd dus volledig opnieuw ontworpen om als servlet te kunnen dienen voor servlet based web servers (zoals hier Apache Tomcat wordt gebruikt). Het is tevens mogelijk om eventuele restricties op te leggen, zodat bijvoorbeeld bepaalde packages niet worden gendexeerd en er bijgevolg geen links naar XML-bronbestanden in deze 91
packages worden gegenereerd.
Statistische informatie Vermits er nu toch een databank beschikbaar was, met daarin de verbanden tussen alle bronbestanden in de repository, kon er handig gebruik van gemaakt worden om tevens een beperkte vorm van statistische gegevens te genereren. Vandaar de ontwikkeling van een servlet die een dynamisch XML-bestand genereert met daarin de algemene informatie omtrent de data in de repostory, alsook de mogelijkheid om verbanden op te vragen. De algemene data omvat onder andere het aantal packages, bestanden, klassen, methodes, gemporteerde en extended klassen, gemplementeerde interfaces,. . . Daarnaast is het mogelijk om ook de betre ende lijsten van klassen/packages/bestanden op te vragen, evenals een listing van alle klassen die een opgegeven klasse, interface of package importeren, implementeren of uitbreiden. Uiteraard betreft het hier slechts een eenvoudig voorbeeld. Hoe meer informatie er in de databank wordt opgenomen, hoe uitgebreider de af te leiden gegevens zullen zijn. Enkele mogelijke uitbreidingen zijn: Alle klassen ontwikkeld door een gegeven programmeur, op of na een gegeven datum Klassen die een zekere methode gebruiken Het totaal aantal codelijnen geschreven door een programmeur Het aantal maal dat een zekere klasse werd opgevraagd (ev. in functie van de tijd) Een tijdslijn/geschiedenis van een zekere klasse of package De complexiteit van een klasse De populariteit van een klasse Een netwerkstructuur die de verweving van de klassen/packages gra sch weergeeft
92
Hoofdstuk 4
Nabeschouwingen 4.1
Thesisverloop
Deze thesis werd mogelijk gemaakt dankzij de hulp van de mensen bij de E-corporation. De maand juli werd grotendeels gewijd aan het leren werken met de taal Java en het aanleren van begrippen als XML, XSL/XSLT, DTD's, en de talloze daarmee samenhangende concepten. Deze fase kenmerkte zich voornamelijk door het lezen van vele boeken en Internetbronnen met betrekking tot deze onderwerpen. Dit werd gevolgd door een vorm van stage gedurende een zestal weken in de E-corporation. Naast lezen, werd het nu ook tijd om te beginnen experimenteren met tools als webservers en publishing systems. In deze fase werd eveneens het concept van een XML broncode repository uitgewerkt, in overleg met mijn promotor Prof. Bossaert en Dhr. Portier, mijn begeleider bij de E-corporation. Use cases en UML schema's werden opgemaakt en de eerste cyclus in het iteratief ontwerp werd afgerond. Dit betrof een heel eenvoudig systeem, bestaande uit een Java naar XML conversie, http upload en weergave via een stylesheet. Van Xlinks, WebDAV, search engine, databank of statistieken was op dat moment nog geen sprake. In de daarop volgende maanden werden de bestaande componenten verder uitgebouwd en telkens nieuwe elementen toegevoegd aan het systeem. De meeste tijd werd uiteindelijk besteed aan de Java naar XML conversie en het linkbeheer. Wat de XML-conversie betrof, kroop er veel tijd in het uitdenken van een eciente manier om dit te implementeren. Na veel experimenteren met parser generators en lexical analyzers, waren het vooral tools als de Java Tree Builder die wat schot in de zaak brachten dankzij hun abstractie van het low level parsen. Uit de bepreking van de Xlink kwestie bleek reeds dat ook het beheren van de links tussen de klassen een complexe kwestie werd. Vooral het bepalen van de fully-quali ed methodenamen zorgde voor enkele hoofdbrekens, maar na wat brainstormen met de mensen van de E-corporation lukte het toch deze problemen onder handen te nemen. Nadat de belangrijkste zaken gemplementeerd werden, werd er meer aandacht besteed aan enkele meer formele vereisten, zoals een DTD en een schema voor de gegenereerde XML bestanden. Vermits het hele project ontwikkeld werd op een Windows NT platform, diende er ook het een en ander aangepast te worden om het geheel werkende te krijgen onder Linux en Unix. Vooral de case-gevoeligheid van deze platformen lag aan de oorzaak van enkele problemen. In de recentste versie zijn deze moeilijkheden echter volledig gladgestreken. 93
<modifier/> <primitive_type> int i ;
Figuur 4.1: De Java XML vorm van int i Niettemin zijn er nog enkele zaken waarvoor moet worden opgelet bij het gebruik onder Unix of onder webservers/publishing systems verschillend van degene besproken in deze thesis. Er dienen een aantal aanpassingen te gebeuren in de con guratiebestanden `java2xml.cfg' en `cocoon.properties', zoals besproken in een volgende sectie. In bepaalde gevallen kunnen er problemen optreden indien de relatieve paden in het java2xml con guratiebestand niet vervangen worden door de corresponderende absolute paden. Wanneer tenslotte een combinatie van Apache en Tomcat wordt aangewend als webserver, dienen alle URL's m.b.t. tot de repository te verwijzen naar de Tomcat poort (standaard 8080) en niet naar die van Apache (standaard poort 80). Wat het uploaden betreft dient er uiteraard de poort van de WebDAV server gebruikt te worden (bv. poort 80 meer de Apache mod dav module). 4.2
Mogelijke uitbreidingen
De Java2XML client en server hebben nog wel te kampen met enkele performantieproblemen. Als prototype werkt alles naar behoren, maar in een reele werkomgeving is de responstijd vaak aan de hoge kant. Dit is vooral het gevolg van de bestandsexplosie bij de Java naar XML conversie. Een broncode bestand van 30kb bijvoorbeeld, kan al aanleiding geven tot een XML bestand van enkele honderden kilobytes. Dit wordt veroorzaakt door het feit dat de meta-data vaak meer plaats innemen dan de eigenlijke omsloten gegevens.
Voorbeeld 4.1. Beschouw een regel broncode van de vorm int i;
Dit kan aanleiding geven tot de XML-vorm afgebeeld in Figuur 4.1.
94
Uiteraard is dit nu wel een extreem voorbeeld, maar het verduidelijkt het kernprobleem. Immers, grotere XML-bestanden geven aanleiding tot langere up- en downloadtijden. Daar komt nog bij dat Cocoon slechts de HTML doorgeeft aan de client nadat de volledige XSLTtransformatie werd uitgevoerd. Indien telkens het reeds verwerkte gedeelte naar de gebruiker zou worden gestreamd (zoals bij standaard HTML requests) en de pagina dus stapsgewijs zou worden opgebouwd, dan zou dit een en ander reeds wat verhelpen. Er zijn twee evidente manieren om dit euvel te verhelpen, maar beiden hebben enkele nadelen en ze vereisen tevens het totaal herwerken van de Java2XML client en server. Een eerste oplossing is het reduceren van het aantal tags. Dit kan de bestandsgrootte drastisch verkleinen, maar vermits er in zo'n geval minder meta-data worden opgeslaan zullen de mogelijkheden van de resulterende XML-bestanden ook drastisch reduceren. Zelfs eenvoudige toepassingen, zoals syntax highlighting hebben immers nood aan een erg jne granulariteit qua syntax markering. Een ander mogelijkheid is het verkorten van de tag-namen. In plaats van "local variable declaration" kan men bijvoorbeeld "lvd" gebruiken. Ook dit heeft uiteraard een belangrijke invloed op de bestandsgrootte. Bovendien gaan er geen meta-data verloren. Helaas wordt het XML-bestand in zo'n geval wel quasi onleesbaar voor iemand die niet vertrouwd is met de gebruikte afkortingen. Ook aanpassingen in de parser-code kunnen zo ferm bemoeilijkt worden. Om dit performantieprobleem voor een deel tegemoet te komen werd er een eenvoudige vorm van caching ontworpen. Indien caching wordt aangezet in het Java2XML con guratiebestand, zal er bij elke request naar een JavaXML bestand steeds nagegaan worden of er niet reeds een gecachte versie bestaat, opgeslaan tijdens een vorige request. Zoja, dan wordt dit bestand gebruikt, zonder de volledige parsing procedure opnieuw te doorlopen. Dit heeft wel tot gevolg dat de links in het resulterende bestand niet voor honderd percent up to date zullen zijn, vermits de databank niet wordt geraadpleegd, maar kan het behandelen van een request met een factor drie versnellen. Deze caching methode is dus vooral interessant wanneer men op voorhand weet dat de kans klein is dat er in de komende tijd nog documenten worden toegevoegd aan de repository. De caching kan overigens aan en uit worden gezet, zonder dat de server dient te worden herstart. Tenslotte zijn er nog tal van zaken die kunnen verbeterd of toegevoegd worden aan de repository. Een heel belangrijke aanvulling is bijvoorbeeld logging. Momenteel worden eventuele fouten gewoon weergegeven op de server-console als Java-excepties. Het toevoegen van log-functies in kritieke secties van de code (request-handling, databanktoegang,. . . ) kan het debuggen in bepaalde gevallen sterk vereenvoudigen. Qua functionaliteit kunnen er nog heel wat mogelijkheden worden uitgedacht, vooral nu de broncode in het universele XML-formaat in de repository is opgenomen. Enkele voorbeelden (vooral dan met betrekking tot statistische informatie) van dergelijke potentiele uitbreidingen zijn terug te vinden in de use-cases (zie appendices). 4.3
Open source
Vermits er voor de creatie van deze applicatie uitvoerig gebruik gemaakt werd van Open Source tools, bibliotheken en applicaties (Tomcat, Cocoon, JTB,. . . ), is het maar normaal dat het resultaat terug vrijgeven wordt aan de Open Source gemeenschap. Twee alleen95
staande onderdelen van de Java2XML client werden alvast vrijgegeven (sinds december 2000). Het gaat om de Java broncode naar XML convertor en de Java command line WebDAV client, CLWebdav gedoopt. De homepages zijn respectievelijk http://java2xml.cjb.net en http://clwebdav.cjb.net. Onze hartelijke dank alvast aan de mensen achter de Open Source tools die dit project mede mogelijk maakten. 4.4
Gebruik
Hier volgt een korte gebruikersbeschrijving van de Java2XML client en server.
4.4.1 De client De Java2XML client is vervat in 5 jar bestanden. Daarvan zijn er slechts 4 nodig voor direct gebruik. Vooreerst dienen de jar bestanden tezamen in de directory (bv. de lib subdirectory van het JDK installatiepad) te worden geplaatst. Van daaruit kunnen ze reeds onmiddellijk worden aangesproken via een commando van de vorm "java -jar jarname argument". Om de jars ook vanuit een ander pad toegankelijk te maken is het echter eenvoudiger om in diezelfde directory een aantal batch bestanden of shell scripts te voorzien die commando's van de vorm "java -jar jarpath/jarname argument" bevatten. Indien deze directory vervolgens in het `path' wordt opgenomen, zijn de clientbestanden van overal toegankelijk. Voorbeeld batch bestanden en shell scripts zijn terug te vinden in de client package. Uiteraard moet het jarpath nog wel worden aangevuld, vermits dit afhankelijk is van de keuze van de gebruiker. Uiteraard kan een dergelijk batch bestand een concatenatie van commando's bevatten, zodat tengevolge van een enkele oproep een heel directory-argument wordt geconverteerd, gelinkt en eventueel zelfs ge-upload. Het eerste jar bestand is Java2XML.jar . Hiermee kan een Java bronbestand of een hele directory bronbestanden (bv. een package) worden geconverteerd naar XML bestanden. Indien een directory-argument wordt opgegeven, dan zullen ook alle subdirectories recursief worden verwerkt. Door het argument weg te laten en dus enkel "java -jar Java2XML.jar" uit te voeren, wordt een korte beschrijving van de mogelijkheden weergegeven. Dit is analoog voor de andere jars. Met Doc2XML.jar kunnen vervolgens op gelijkaardige wijze de Javadoc XML bestanden worden gegenereerd voor een enkel bronbestand of een directory. JavaLink voert de linkinsertie uit op de XML bestanden. Het spreekt dus vanzelf dat JavaLink pas kan worden uitgevoerd nadat beide vorige procedures worden toegepast. JavaLink uitvoeren op XMLbestanden die reeds gelinkt zijn (of een directory met reeds enkele gelinkte bestanden) levert geen problemen, vermits dit telkens gecheckt wordt alvorens aan het link-proces te beginnen. Een voorbeeld Ant bestand (build.xml) werd voorzien dat de conversie en linking in de juiste versie toepast op een opgegeven argument. Voorlopig gebeurt de output van deze operaties in dezelfde directory als de bronbestanden. De reden hiervoor is dat de bronbestanden toch mee moeten worden ge-upload naar de repository (zodat er een download link naar kan worden genserteerd in het corresponderende XML-bestand). 96
Tenslotte dienen de XML-bestanden (en overeenkomstige bronbestanden) te worden geupload naar de server. Hiervoor kan om het even welke WebDAV-client worden aangewend. Indien de gebruiker liefst met een gra sche versie werkt, dan kunnen bijvoorbeeld DavExplorer of Webfolders worden gebruikt. Het is belangrijk dat de bestanden op de server worden geplaatst in een directorystructuur die overeenkomt met de packagenaam. De package \com.mydomain.mypack" dient dus e ectief te worden ge-upload naar \/com/mydomain/mypack" in de server root. Indien dit niet gebeurt, zullen er op de server geen links kunnen worden ingevoerd in de betre ende documenten en zal er ook niet naar gelinkt kunnen worden. Er is evenwel ook een commandolijn WebDAV-client voorzien bij de Java2XML client. Deze biedt een aantal voordelen t.o.v. andere clients. CLWebdav.jar biedt dezelfde functionaliteit als een gewone WebDAV-client, maar WDUpload.jar, de shell rond CLWebDAV zal een ltering uitvoeren. Enkel de Java, Java XML en JavaDoc XML bestanden zullen ge-upload worden. Indien er zich nog andere type bestanden in de brondirectory bevinden, dan worden deze eruit ge ltert. Bovendien controleert deze client alvorens te uploaden of de relatieve directorystructuur overeenkomt met de packagenaam. Dit verzekert dat de XML-bestanden op de correcte plaats zullen terecht komen in de repository. Vermits er bij het WebDAV protocol immers geen post-processing mogelijk is, dient dit reeds aan clientzijde te gebeuren. De gebruiker dient zich dus bij het gebruik van deze client geen zorgen meer te maken over de creatie van directories op de server, vermits de client deze automatisch zal voorzien. Het is echter wel nodig dat het upload commando wordt gegeven vanuit de root van de bronpackage. Een voorbeeld: indien de gebruiker een package \com.mydomain.mypack" wenst up te loaden dat lokaal te vinden is onder \usr/my les/mypackages/com/mydomain/mypack", dan dient het upload commando te worden gegeven vanuit \usr/my les/mypackages". Dit laat toe dat WDUpload nagaat of de relatieve padnaam overeenkomt met de packagenames, zoals gede nieerd in de XML-bestanden (hiervoor wordt opnieuw SAX-parsing gebruik). Is dit niet het geval, dan wordt een foutboodschap gegenereerd. CLWebdav heeft deze beperking niet en kan vanuit elk pad worden opgeroepen, maar het is dan de verantwoordelijkheid van de gebruiker om de correcte destinatie te de nieren. Het is dan ook sterk aan te raden om WDUpload te gebruiken. WDUpload en CLWebdav gebruiken een hele reeks argumenten, waarvan er reeds een aantal vast kunnen worden gede nieerd in een batch bestand of shell script. Een typische oproep naar WDUpload gebeurt als volgt: java -jar <jarpath>/WDUpload.jar <port> [<username>] [<password>] <source >
Gebruikersnaam en paswoord zijn dus niet verplicht. Dit kan worden ingesteld op de WebDAV server. Host en port hebben eveneens betrekking op de WebDAV server. Deze kan eventueel verschillen van de webserver die de XML-bestanden zal weergeven. Over het algemeen zal dus enkel WDUpload vereist zijn voor het werken met de Java2XML client. Vermits CLWebDAV een volledige WebDAV implementatie voorziet is het aantal argumenten van deze package echter nog een stuk uitgebreider. Een oproep zonder argument levert een samenvatting van de mogelijkheden. De WebDAV methodes kunnen als volgt worden toegepast: java -jar <jarpath>/CLWebdav.jar <args>
97
GET PUT DELETE MOVE COPY LOCK UNLOCK PROPFIND PROPPATCH MKCOL
host host host host host host host host host host
port port port port port port port port port port
[user] [user] [user] [user] [user] [user] [user] [user] [user] [user]
[password] [password] [password] [password] [password] [password] [password] [password] [password] [password]
resource resource resource resource resource resource resource resource resource resource
dest overwrite dest overwrite locktype scope propfind depth XML-file type
Figuur 4.2: Mogelijke argumenten bij CLWebdav met <args> een van de argumenten in Figuur 4.2.
Voorbeeld 4.2. Enkele voorbeelden van argumenten bij het gebruik van CLWebdav: Kopieert het bestand my le.txt naar my le.doc in de server root:
COPY 111.11.11.11 8080 johndoe mypass myfile.txt http://localhost/myfile.doc F Vraagt alle properties op van het bestand my le.txt:
PROPFIND 111.11.11.11 8080 johndoe mypass myfile.txt allprop 0 Past de properties van het bestand my le.txt, op basis van de (geldige) inhoud van het
XML-bestand prop.xml op de client:
PROPPATCH 111.11.11.11 8080 johndoe mypass myfile.txt prop.xml text/html
4.4.2 De server De volledige directory-structuur van de Java2XML server is te vinden in de volgende sectie. Vooreerst dient er een WebDAV server te worden opgezet om client uploads te aanvaarden. Hiervoor zijn er verschillende servers beschikbaar. Er dient enkel te worden gezorgd voor een correct destinatiepad (meestal /webapps/java2xml/upload_root) en eventuele toegangsrestricties (op basis van gebruikersnaam en paswoord). Het kan voor bepaalde klasse gebruikers bijvoorbeeld toegelaten zijn om nieuwe bestanden up te loaden, maar niet om bestanden van de server te verplaatsen of verwijderen. Indien Tomcat als webserver wordt gebruikt, dan kan daarnaast Apache worden genstalleerd, voorzien van 98
de mod dav WebDAV module. Ook andere packages zoals Slide of de WebDAV module opgenomen in Tomcat 4.0 en hoger kunnen gebruikt worden. De server is verkrijgbaar in een zip bestand dat reeds een volledige versie van Tomcat 3.1 en Cocoon 1.7.4 bevat en dat volledig klaar is voor gebruik. Enkel de aanpassingen van `java2xml.cfg', zoals hieronder besproken, dienen nog te worden doorgevoerd. Er is eveneens een server-versie voorzien die enkel de Java2XML server bevat. Deze kan gebruikt worden indien de server bijvoorbeeld onder een recentere versie van Tomcat en/of Cocoon zal genstalleerd worden. In dit geval dienen alle hieronder besproken aanpassingen te worden uitgevoerd. Wanneer een verschillende versie van Cocoon wordt gebruikt, dienen de `cocoon.properties' con guratiebestanden in de repository te worden vervangen door de versies meegeleverd met de betre ende Cocoon distributie. De repository werd eveneens getest met de alpha versies van Tomcat 4.0 en Cocoon 2.0 . Mits de eerder vermelde aanpassingen, werkt alles ook hier naar behoren. Het hele Java2XML server pakket dient dus terecht te komen in een subdirectory van /webapps. Vervolgens dient het java2xml.cfg bestand te worden gekopieerd naar Tomcat's con guratiedirectory (/conf). Alle \localhost" entries dienen vervangen te worden door de servernaam (en poort, indien verschillend van 80). Indien als installatiedirectory niet \java2xml" werd gekozen, dan dient dit eveneens te worden aangepast in het con guratiebestand. Om con icten te voorkomen kan het aangeraden zijn om, in het con guratiebestand, alle paden relatief ten opzichte van de `bin' directory te vervangen door absolute paden. Verschillende Tomcat installaties kunnen immers verschillende instellingen hebben voor de `document root'. De paden relatief t.o.v. de `classes' directory hoeven niet te worden aangepast! De server is beschikbaar in twee versies. Een versie die totaal leeg is en een versie met reeds een voorbeeld repository-inhoud. De laatste versie beschikt reeds over een databank (`java2xml' genaamd). Via het bestand `createDB.bat/sh' kan een nieuwe (lege) databank worden aangemaakt. De databanknaam wordt simpelweg als argument meegegeven. Indien de naam verschilt van `java2xml', dan moet dit tevens in het con guratiebestand worden aangepast. Tenslotte zijn er nog twee batch bestanden/shell scripts voorzien die aan serverzijde moeten draaien. `UpdateDB' zal elk uur een thread spawnen die de repository a oopt en informatie omtrent nieuwe bestanden toevoegt aan de databank. Het tijdsinterval kan worden aangepast in het batch bestand. `UpdateIndex' voert een analoge operatie uit voor de index, gebruikt door de full text search engine. Ook hier kan het default interval anders worden ingesteld. In de bestanden `rules.txt' en `urls.txt' dient evenwel de servernaam te worden ingesteld, evenals eventuele restricties op de af te scannen directories. Dit alles zorgt ervoor dat de kans op dode links (of ontbrekende links naar reeds toegevoegde bestanden) wel heel erg klein wordt. Alle weergegeven links worden immers eerst nagegaan in de databank. Indien de databank op geregelde tijdstippen wordt ge-update (bv. elk uur), dan kan een dode of ontbrekende link situatie slechts optreden onmiddellijk nadat een wijziging aan de repository gebeurde.
99
4.5
De directorystructuur
Onder Jakarta Tomcat worden server-applicaties over het algemeen geplaatst onder de webapps directory. De hele repository komt standaard in een subdirectory `java2xml' terecht, al kan die naam wel gewijzigd worden. In dat geval dient tevens het con guratiebestand `java2xml.cfg' te worden aangepast. De directorystructuur van de Java2XML server ziet er als volgt uit: !Tomcat home ! conf java2xml.cfg ! webapps ! java2xml cocoon.properties ! menu ! META-INF ! search ! stats ! upload root DocStyle.xsl LinkSheet.xsl ! WEB-INF cocoon.properties web.xml ! classes ! batch ! bdd ! com ! oreilly ! sun ! hypersonic ! javax ! org ! hsql ! w3c ! xml ! property ! request ! stats ! tmp ! upload ! xmldb createdb.bat/sh java2xml.* main.db rules.txt
100
Tomcat installatiepad Tomcat con guratiedirectory con guratiebestand standaard webapplicatie-pad Java2XML root Cocoon con guratiebestand menu-layout manifest lay-out search-engine stylesheets statistische info repository root stylesheet Javadoc XML stylesheet XML broncode Java2xml back-end Cocoon con guratiebestand servlet con guratiebestand servlet directory hulpklassen batch processor search-engine servlet hulp-package http-upload imports SAX-parser databank package servlet imports hulp-package databank package DOM-parser (databank) SAX-parser con guratie-klassen request servlet servlet voor statische info tijdelijke voor search engine http-upload servlet databank-manipulatie klassen aanmaak nieuwe databank voorbeeld databank search engine index search engine restricties
updateDB.bat/sh updateIndex.bat/sh urls.txt
databank-update batch proces search-engine update batch pr. search engine restricties
De Java2XML client is vervat in 4 packages (Java2XML.jar, Doc2XML.jar, JavaLink.jar en Wdupload.jar), tezamen met enkele batch bestanden/shell scripts om de werking te vereenvoudigen. 4.6
CD-inhoud
Hieronder volgt de inhoud van de CD-rom bij deze thesis. Er werden verschillende versies van de thesistekst voorzien (HTML, XML, PDF, ...), evenals de tools gebruikt bij de ontwikkeling van de repository en uiteraard ook de broncode en uitvoerbare code van de Java2XML client en server. Meer informatie omtrent de installatie kan teruggevonden worden in sectie 4.4 en de readme bestanden op de CD. !CD root ! application ! client ! ! ! server ! ! ! text ! ! ! ! ! ! tools ! ! ! ! ! ! ! ! ! ! ! ! !
Java2XML application Java2XML client client ecexutables client source code Java2XML server server ecexutables server source code thesis text XML Docbook version PDF version Postscript version TeX version browsable HTML version tools and applications Jakarta Ant make-tool Apache webserver UML modelling tool publishing framework Tomcat 4 and Cocoon 2 WebDAV client with GUI JDK 1.3 Java Compiler Compiler Java servlet dev. kit Java Tree Builder Apache WebDAV module Slide WebDAV plug-in Tomcat Servlet engine
bin src bin src docbook xml pdf pds tex XHTML ant apache argouml cocoon cocoon2 davexplorer java javacc jsdk jtb mod dav slide tomcat 101
4.7
Overzicht gebruikte software
Java 2 SDK, Standard Edition (J2SE), versie 1.3.0, van Sun
http://java.sun.com/j2se Java 2 SDK, Enterprise Edition (J2EE), versie 1.3 beta
http://java.sun.com/j2ee JOnAs 2.2.7 Java/XML applicatie-server/EJB-container.
http://www.evidian.com/jonas Apache webserver versie 1.3
http://www.apache.org Mod dav webdav module voor Apache
http://www.webdav.org/mod\_dav DAV Explorer WebDAV client versie 0.62
http://www.ics.uci.edu/$\sim $webdav Apache Tomcat servlet engine versie 3.1 en versie 4.0 Alpha
http://jakarta.apache.org/tomcat Cocoon 1.7.4 & Cocoon 2.0 Alpha publishing framework
http://xml.apache.org/cocoon XML-parsers: Xerces versie 1.2 , JAXP versie 1.0.1
http://java.sun.com/xml JavaCC en JTB parser generator versie 1.2.2
http://www.cs.purdue.edu/jtb Hypersonic SQL databank
http://www.hypersonicsql.com BDDBot search engine
http://www.endware.com/bddbot Ant make tool
http://jakarta.apache.org/ant ArgoUML design tool, versie 1.8
http://argouml.tigris.org
102
XMLSpy (demo) versie 3.5, XML/Stylesheet/DTD/Schema editor
http://www.xmlspy.com DocBook XML V4.1.2, DocBook stylesheets (LaTex en PDF conversie)
http://www.oasis-open.org/docbook Oreilly Sevlet support classes
http://www.servlets.com/resources/com.oreilly.servlet
De repository werd grotendeels ontwikkeld op een Windows NT systeem. Gezien het feit dat alles in Java werd geschreven, kon de repository nadien relatief vlekkeloos bruikbaar gemaakt worden op andere platformen die de JVM (Java Virtual Machine) ondersteunen. De enige moeilijkheid bleek de case-sensitivity van Unix-like systemen te zijn, evenals het verschil in le-seperator, waarmee aanvankelijk in het con guratiebestand niet steeds rekening werd gehouden. De laatste versie van de repository werd uiteindelijk getest en werkend bevonden op vier verschillende platformen: Windows NT (Intel Pentium), Windows ME (AMD Athlon), Linux (Mandrake 7.2 en 8.0 op een AMD Athlon) en Sun Solaris. Vooral op het laatste systeem kwamen de webservercapaciteiten pas echt goed tot hun recht.
103
Appendix A
Analyse en ontwerp A.1 UML-schema's A.2 Use cases A.3 Visitor Pattern A.4 Java XML DTD A.5 Java XML Schema A.6 Voorbeeld Java XML bestand A.7 Java XML stylesheet A.8 Het con guratiebestand A.9 Voorbeeld EJB's
i
i
Appendix B
Afkortingenlijst API ASCII B2B CGI CDATA CORBA CSS CVS DAV DBMS DOM DSSSL DTD EAR EJB FO FTP HTML HTTP IETF J2EE JAR JavaCC JDBC JDK JNDI JNI JSP JTB JVM MIF MIME
Application Programming Interface American Standard Code for Information Interchange Business-to-Business Common Gateway Interface Character Data Common Object Request Broker Architecture Cascading Style Sheets Concurrent Versioning System Distributed Authoring and Versioning Database Management System Document Object Model Document Style Semantics and Speci cation Language Document Type De nition Enterprise Application Resource Enterprise JavaBean Formatting Objects File Transmission Protocol Hypertext Markup Language Hypertext Transfer Protocol Internet Engineering Task Force Java 2 Enterprise Edition [Sun] Java Archive Java Compiler Compiler Java Database Connectivity Java Developers Toolkit Java Naming and Directory Interface Java Native Interface Java Server Pages Java Tree Builder Java Virtual machine Maker Interchange Format Multipurpose Internet Mail Extensions ii
MOF NT ODBC OMG OO PDF PCDATA PS PURL RCDATA RCS RMI RTF RUP SAX SDK SGML SSH SQL UC UML URC URI URL URN W3C WAR WebDAV WML WWW XHTML XLink XLL XML XML XPath XPointer XSD XSDL XSL XSL XSP XSLT
Meta Objects Facility New Technology [Microsoft] Open Database Connectivity Object Management Group Object Oriented Postscript Data Format Parsed Character Data Postscript Persistent Uniform Resource Locator Replacable Character Data Revision Control System Remote Method Invocation Rich Text Format Rational Uni ed Process Simple API for XML Software Development Kit Standard Generalized Markup Language Secure Shell Structured Query Language Use Case Uni ed Modeling Language Uniform Resource Characteristic Universal Resource Identi er Universal Resource Locator Uniform Rescource Name World Wide Web Consortium Web Application Resource WWW Distributed Authoring and Versioning Wireless Markup Language World Wide Web Extensible HyperText Markup Language XML Linking Language Extensible Linking Language Metadata Interchange Extensible Markup Language XML Path Language XML Pointer Language XML Schema Declaration XML Schema De nition Language Extensible Stylesheet Language FO XSL Formatting Objects XML Server Pages XSL Transformations
iii
Bibliogra e [1] Sharon Adler, Anders Berglund, Je Caruso, Stephen Deach, Paul Grosso, Eduardo Gutentag, Alex Milowski, Scott Parnell, Jeremy Richman, Steve Zilles, Extensible Stylesheet Language (XSL/XSLFO) Version 1.0, W3C Candidate Recommendation, 21 November 2000, http://www.w3.org/TR/xsl
[2] Alfred V. Aho, Ravi Sethi, Je rey D. Ullman, Compilers { Principles, Techniques and Tools, Addison-Wesley, 1986. [3] Brad Appleton, Patterns and Software: Essential Concepts and Terminology, http://www.enteract.com/$\sim $bradapp/docs/patterns-intro.html
[4] Eric Armstrong, The Java API for Xml Parsing (JAXP) Tutorial - Serial Access with the Simple API for XML (SAX) & XML and the Document Object Model (DOM), http://java.sun.com/xml/jaxp-docs-1.0.1/docs/tutorial [5] Tim Bray (Textuality), Dave Hollander, Andrew Layman, Namespaces in XML, World Wide Web Consortium, 14-January-1999, http://www.w3.org/TR/REC-xml-names
[6] Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, Extensible Markup Language (XML) 1.0 (Second Edition), W3C Recommendation, 6 October 2000, http://www.w3.org/TR/REC-xml
[7] James Clark, Steve DeRose, XSL Transformations (XSLT) Version 1.0, W3C Recommendation, 16 November 1999, http://www.w3.org/TR/xslt
[8] James Clark, Steve DeRose, XML Path Language (XPath) Version 1.0, W3C Recommendation, 16 November 1999, http://www.w3.org/TR/xpath
[9] C.J. Date : An Introduction to Database Systems, 6th ed., The Systems Programming Series, Addison-Wesley, 1995.
i
[10] Steve DeRose, Eve Maler, Ron Daniel Jr., XML Pointer Language (XPointer) Version 1.0, W3C Last Call Working Draft, 8 January 2001. http://www.w3.org/TR/xptr
[11] Steve DeRose, Eve Maler, David Orchard, XML Linking Language (XLink) Version 1.0, World Wide Web Consortium (W3C) Recommendation, 20 December 2000, http://www.w3.org/TR/xlink
[12] Bruce Eckel, Thinking in Java, 2nd Edition, Prentice Hall, 2000. [13] David C. Fallside, XML Schema Primer, W3C Proposed Recommendation, 30 Maart 2001, http://www.w3.org/TR/xmlschema-0
[14] David Flanagan: Java in a Nutshell, 3rd edition, O'Reilly, 1999. [15] Y. Goland, E. Whitehead, A. Faizi, S. Carter, D. Jensen: HTTP Extensions for Distributed Authoring { WEBDAV, Request for Comments 2518, http://andrew2.andrew.cmu.edu/rfc/rfc2518.html
[16] Elliotte Rusty Harold, XML Bible, IDG, 1999. [17] Jason Hunter, Java Servlet Programming, O'Reilly, 1998. [18] Robert Hustead, Mapping XML to Java, Employ the SAX API to map XML documents to Java objects, http://www.javaworld.com/javaworld/jw-08-2000/jw-0804-sax.html
[19] Ivar Jacobson, Martin Griss, Patrik Johnsson, Software Reuse, Addison Wesley, 1997. [20] Wallace Koehler, Web Document Morbidity and Change, http://www.ou.edu/cas/slis/courses/LIS5990A/slis5990/stability/Morbidity.htm
[21] Brett McLaughlin, Java and XML, O'Reilly, 2000. [22] Juston Ludwig, An Investigation of XML with Emphasis on Extensible Linking Language, http://pages.wooster.edu/ludwigj/xml/thesis.html
[23] Andrew Patzer, Danny Ayers, Hans Bergsten, Jason Diamond, Mike Bogovich, Matthew Ferris, Marc Fleury, Ari Halberstadt, Paul Houle, Sing Li, Piroz Mohseni, Ron Phillips, Krishna Vedati, Mark Wilcox, Stefan Zeiger, Professional Java Server Programming : J2EE Edition, Wrox Press Inc., 2000. [24] Rawn Shah, Integrating Databases with Java via JDBC, http://www.javaworld.com/javaworld/jw-05-1996/jw-05-shah.html
ii
[25] Stephen Spainhour, Robert Eckstein, Webmaster in a Nutshell, 2nd edition, O'Reilly, 1999. [26] Sun Microsystems, Enterprise JavaBeans Developer's Guide, http://eleni.netmode.ece.ntua.gr/docs/j2sdkee/guides/ejb/html/TOC.html
[27] Titia van der Werf-Davelaar, Identi cation, location and versioning of webresources, http://www.kb.nl/coop/donor/rapporten/URI.html
[28] Vannevar Bush, As We May Think, The Atlantic Monthly, 1945, http://www.theatlantic.com/unbound/flashbks/computer/bushf.htm
[29] James Whitehead, Jr., Collaborative Authoring on the Web: Introducing WebDAV, http://www.asis.org/Bulletin/Oct-98/webdav.html
iii
$9RRUEHHOG80/VFKHPD¶V *H]LHQ GH 22DDQSDN ZHUGHQ VWHHGV YRRU DDQYDQJ YDQ HONH LWHUDWLH LQ KHW VSLUDDOPRGHO GH QRGLJH XVH FDVHV HQ 80/ VFKHPD¶V RSJHVWHOG 'H 80/ VFKHPD¶V ZHUGHQ RSJHVWHOG LQ $UJR80/ HQ RSJHVODJHQ LQ KHW RYHUGUDDJEDUH ;0, IRUPDDW +LHUQD YROJHQ WZHH YRRUEHHOG80/VFKHPD¶VYRRUGH-DYD;0/FOLHQWHQGHVHDUFKVHUYOHW
)LJ$ 80/VFKHPDYRRUHHQHHUVWHLWHUDWLHYDQGH-DYD;0/FOLHQW
)LJ$ 80/VFKHPDYRRUGHLPSOHPHQWDWLHYDQHHQVHDUFKVHUYOHW
L
$;0/-DYD5HSRVLWRU\ 8VH&DVHV ,Q GH]H DSSHQGL[ ZHUGHQ HQNHOH YRRUEHHOG 8VH FDVHV RSJHQRPHQ RSJHVWHOG LQ GH RQWZHUSIDVH YDQ GH UHSRVWRU\ =H LOOXVWUHUHQ GH PRJHOLMNKHGHQ ZDDURYHU HHQ LGHDOH UHSRVWRU\ ]RX NXQQHQ EHVFKLNNHQHQYRUPGHQHHQVWUHHIGRHOELMGHHLJHQOLMNH RQWZLNNHOLQJ 8& 8SORDGDVRXUFHILOH $FWRU *RDO 3UHFRQGLWLRQ 5HODWHG8&V
&RQWULEXWLQJ'HYHORSHU &RPSLOHDQGXSORDGDVSHFLILF-DYD6RXUFH)LOH -DYDVRXUFHFRPSLOHVZLWKRXWZDUQLQJV 1RQH
0DLQIORZRI(YHQWV
$FWRU VLQWHQWLRQ 8SORDGD-DYDVRXUFHILOH (QWHUSDUDPHWHUV >VHHUHPDUNV@ >8SORDGVXFFHVIXO@
>8SORDGIDLOHG@
6WHS
6\VWHP VUHVSRQVH o 5HTXHVWSDUDPHWHUV>VHHUHPDUNV@ o $WWHPSWXSORDGXVLQJHQWHUHG SDUDPHWHUV o 'LVSOD\8SORDGVXFFHVIXOPHVVDJH VHUYHUUHVSRQVH o 'LVSOD\8SORDGIDLOHGPHVVDJH VHUYHUUHVSRQVH
5HPDUNV 5!! 2!!
UHTXLUHG RSWLRQDOo QRWUHTXLUHGRUGHIDXOWSURYLGHG
3DUDPHWHUV
5!! 1DPH 5!! 8VHUQDPH 5!! 3DVVZRUG 5!! 6HUYHUDGGUHVV 2!! 3RUW 2!! 2SWLRQV RYHUZULWH«
8& 5HWULHYHDVSHFLILFFODVV $FWRU *RDO 3UHFRQGLWLRQ 5HODWHG8&V
5HTXHVWLQJ'HYHORSHU 9LHZDFODVVLQDNQRZQSDFNDJH 1RQH 1RQH
L
0DLQIORZRI(YHQWV
6WHS
$FWRU VLQWHQWLRQ (QWHU85/RIUHSRVLWRU\ >/RJLQIDLOHG@ >/RJLQVXFFHVIXO@
6\VWHP VUHVSRQVH o 5HTXHVWLGHQWLILFDWLRQ>VHHUHPDUNV@ o 5HWXUQWRVWHS o 'LVSOD\FOLFNDEOHOLVWRIDOOSDFNDJHVLQ UHSRVLWRU\ o 'LVSOD\DOLVWRIDOOFODVVHVLQWKHSDFNDJH o +LJKOLJKWHGVRXUFHFRGHLVSUHVHQWHGRQ VFUHHQ
6HOHFWDSDFNDJH 6HOHFWDFODVV
$OWHUQDWLYH
$FWRU VLQWHQWLRQ (QWHU85/RIUHSRVLWRU\ H[WHQGHGZLWKSDFNDJHQDPH >/RJLQIDLOHG@ >/RJLQVXFFHVIXO@
6HOHFWDFODVV
6WHS
6\VWHP VUHVSRQVH o 5HTXHVWLGHQWLILFDWLRQ>VHHUHPDUNV@ o 5HWXUQWRVWHS o 'LVSOD\FOLFNDEOHOLVWRIDOOFODVVHVLQ SDFNDJH o +LJKOLJKWHGVRXUFHFRGHLVSUHVHQWHGRQ VFUHHQ
5HPDUNV ,GHQWLILFDWLRQ
5!! 5!!
/RJLQQDPH 3DVVZRUG
8& 5HWULHYHFRPPHQWV $FWRU *RDO 3UHFRQGLWLRQ 5HODWHG8&V
5HTXHVWLQJ'HYHORSHU 9LHZFRPPHQWVIRUDFHUWDLQFODVVRUPHWKRG 7KHFODVVLQTXHVWLRQKDVEHHQUHWULHYHG 8&
0DLQIORZRI(YHQWV
6WHS
$FWRU VLQWHQWLRQ $GHYHORSHUZLVKHVWRYLHZWKH -DYDGRFFRPPHQWVFRQFHUQLQJD FHUWDLQPHWKRGRUWKHZKROHFODVV LQJHQHUDO 7KHXVHUVFOLFNVRQDFODVVRU PHWKRGOLQN
LL
6\VWHP VUHVSRQVH o 7KHKLJKOLJKWHGFODVVLVYLVLEOHRQ VFUHHQ&ODVVDQGPHWKRGQDPHVDUH FOLFNDEOH o 7KH-DYDGRFFRPPHQWVIRUWKHFKRVHQ FODVVRUPHWKRGDUHGLVSOD\HG
8& 9LHZLPSRUWHGH[WHQGHGFODVVHVRULPSOHPHQWHGLQWHUIDFHV $FWRU *RDO 3UHFRQGLWLRQ 5HODWHG8&V
5HTXHVWLQJ'HYHORSHU 9LHZDVVRFLDWHGFODVVHVRULQWHUIDFHV 7KHFODVVLQTXHVWLRQKDVEHHQUHWULHYHG 8&
0DLQIORZRI(YHQWV
6WHS
$FWRU VLQWHQWLRQ $GHYHORSHUZLVKHVWRYLHZWKH FODVVHVRULQWHUIDFHVDFHUWDLQ FODVVLPSRUWVH[WHQGVRU LPSOHPHQWV 7KHXVHUVFOLFNVRQDQLPSRUW H[WHQGVRULPSOHPHQWVVWDWHPHQWV >WKHUHTXHVWHGILOHZDVQRWIRXQG@ >WKHUHTXHVWHGILOHZDVIRXQGDQG LVDVLQJOHFODVV@ >WKHUHTXHVWHGILOHZDVIRXQGDQG LVDSDFNDJH@ 7KHXVHUFOLFNVRQDOLQN
6\VWHP V UHVSRQVH o 7KHKLJKOLJKWHGFODVVLVYLVLEOHRQ VFUHHQ,PSRUWH[WHQGVDQGLPSOHPHQWV VWDWHPHQWVDUHFOLFNDEOH o 7KHV\VWHPDWWHPSWVWRUHWULHYHWKH UHTXHVWHGILOHV o $PHVVDJHLVGLVSOD\HGVWDWLQJWKDWWKH UHTXHVWHGILOHZDVQRWIRXQGLQWKH UHSRVLWRU\ o 7KHUHTXHVWHGFODVVLVUHSUHVHQWHGRQ VFUHHQ o $FOLFNDEOHOLVWRIDOOFODVVHVLQWKH SDFNDJHLVSUHVHQWHG o 7KHUHTXHVWHGKLJKOLJKWHGVRXUFHILOHLV VKRZQRQVFUHHQ
8& )LQGLQJDVXLWDEOHFODVV $FWRU *RDO 3UHFRQGLWLRQ 5HODWHG8&V
5HTXHVWLQJ'HYHORSHU 5HWULHYHDVXLWDEOHFODVVRUPHWKRGEDVHGXSRQDJLYHQGLVFULSWLRQ 1RQH 1RQH
0DLQIORZRI(YHQWV
6WHS
$FWRU VLQWHQWLRQ )LQGDFODVVWKDWVXLWVKLVQHHGV
6\VWHP VUHVSRQVH o 7KHPDLQVHDUFKSDJHFRQWDLQVDZLQGRZ IRUHQWHULQJDGHVFULSWLRQDQGDVHDUFKEXWWRQ 7KHDFWRUHQWHUVDGLVFULSWLRQLQ o 7KHV\VWHPUHWXUQVWKHUHVXOWLQJOLQNV WKHZLQGRZFKRRVHVZHWKHUD FRQMXQFWLYHRUGLVMXQFWLYH VHDUFKLVZDQWHGDQG SUHVVHV VHDUFK >VHDUFKVXFFHVIXO@ o $OLVWRIRQHRU PRUHOLQNVWRUHOHYDQW VRXUFHFRGHILOHVLVGLVSOD\HG >VHDUFKIDLOHG@ o 7KH PHVVDJHµQRUHOHYDQWGRFXPHQWV
LLL
7KHDFWRUIROORZVDOLQN
IRXQG¶LVGLVSOD\HG5HWXUQWRVWHS o WKHUHTXHVWHGVRXUFHILOHLVVKRZQRQ VFUHHQ
5HPDUNV 2SWLRQDOO\DGGLWLRQDOLGHQWLILFDWLRQPD\EHUHTXLUHGWRHQWHUWKHVHDUFKSDJH,QWKLVFDVHVWHSV DQGRI8&SUHFHGH6WHS 8& 5HWULHYHVWDWLVWLFDOLQIRUPDWLRQ $FWRU *RDO 3UHFRQGLWLRQ 5HODWHG8&V
0DQDJHU 5HYLHZVWDWLVWLFDOLQIRUPDWLRQFRQFHUQLQJVRXUFHILOHVLQUHSRVLWRU\ 1RQH 1RQH
0DLQIORZRI(YHQWV 6WHS
$FWRU VLQWHQWLRQ 9LHZVWDWLVWLFV >/RJLQIDLOHG@ >/RJLQVXFFHVIXO@ 6HOHFWDQRSWLRQ>VHHUHPDUNV@
6\VWHP VUHVSRQVH o 5HTXHVWLGHQWLILFDWLRQ>VHHUHPDUNV@ o 5HWXUQWRVWHS o 'LVSOD\RSWLRQVPHQX>VHHUHPDUNV@ o 'LVSOD\UHTXHVWHGLQIRUPDWLRQ
5HPDUNV ,GHQWLILFDWLRQ
5!! 5!!
/RJLQQDPH 3DVVZRUG
2SWLRQV x x x x x x x x x x x
9LHZOLVWRIDOOFODVVHVRIDVSHFLILFGHYHORSHU 9LHZDOOFODVVHVFUHDWHGDWRUDIWHUDVSHFLILFGDWH 9LHZDOOFODVVHVWKDWLPSRUWDFHUWDLQSDFNDJH 9LHZDOOFODVVHVWKDWXVHDFHUWDLQPHWKRG 9LHZDOOFODVVHVWKDWH[WHQGLPSOHPHQWDFHUWDLQFODVVLQWHUIDFH 9LHZRIFRGHOLQHVVXEPLWWHGWRUHSRVLWRU\ WRWDORUSHUGHYHORSHU 9LHZFODVVHVVXEPLWWHGWRUHSRVLWRU\ WRWDORUSHUGHYHORSHU 9LHZRIKLWVHDFKFODVVUHFHLYHGFODVVHVWKDWKDYHEHHQUHWULHYHGPRVWRIWHQ 9LHZRIWLPHVDFHUWDLQFODVVKDVEHHQLPSRUWHGRUH[WHQGHGE\DQRWKHUFODVV 6KRZWLPHOLQHKLVWRU\RIGHYHORSHGFODVVHV 0HDVXUHFRPSOH[LW\RIDFODVVSDFNDJH
LY
8& &UHDWLQJD-DUILOH $FWRU *RDO 3UHFRQGLWLRQ 5HODWHG8&V
5HTXHVWLQJ'HYHORSHU &UHDWHDMDUILOHWKDWLQFOXGHVWKHQHFHVVDU\ILOHVIRUDVSHFLILFFODVV 7KHXVHUKDVIRXQGWKHFODVVLQTXHVWLRQLQWKHUHSRVLWRU\ 8&
0DLQIORZRI(YHQWV 6\VWHP VUHVSRQVH o 7KHSDJHWKDWVKRZVWKHFODVVDOVR FRQWDLQVDOLQNRUEXWWRQQDPHGFUHDWH MDU o 7KHV\VWHPGHWHUPLQHVDOORWKHU FODVVHVWKHFODVVLQTXHVWLRQGHSHQGV XSRQDQGFUHDWHVDMDUILOH FRQWDLQLQJ VRXUFHDQGSUHFRPSLOHGFODVVHV LQD WHPSRUDU\GLUHFWRU\$OLQNWRWKHMDUILOH LVUHWXUQHG 7KHDFWRUSUHVVHVWKHOLQNWRWKHMDU o 7KHMDUILOHLVGRZQORDGHGWRWKH ILOH DFWRU VKDUGGLVN$IWHUZDUGVWKHILOHLV GHOHWHGIURPWKHWHPSRUDU\GLUHFWRU\DQG WKHRULJLQDOFODVVLVVKRZQDJDLQ 3RVVLEOHH[WHQVLRQ ,PSRUWRIWKLUGSDUW\FODVVHVSDFNDJHVMDUVGRFXPHQWDWLRQ
6WHS
$FWRU VLQWHQWLRQ /HWWKHV\VWHPFUHDWHDMDUILOHZLWK DOOWKHILOHVQHFHVVDU\WRUXQD FHUWDLQFODVV 7KHDFWRUSUHVVHVWKHEXWWRQ
8& &UHDWLQJD%XLOGILOH $FWRU *RDO 3UHFRQGLWLRQ 5HODWHG8&V
5HTXHVWLQJ'HYHORSHU &UHDWHDEXLOGILOHWKDWDOORZVWRFRPSLOHWKHUHTXHVWHGFODVV 7KHXVHUKDVIRXQGWKHFODVVLQTXHVWLRQLQWKHUHSRVLWRU\ 8&
0DLQIORZRI(YHQWV
6WHS
$FWRU VLQWHQWLRQ /HWWKHV\VWHPFUHDWHDMDUILOHZLWK DOOWKHILOHVQHFHVVDU\WRUXQD FHUWDLQFODVV 7KHDFWRUSUHVVHVWKHEXWWRQ
7KHDFWRUVDYHVWKHEXLGILOHWRKLV KDUGGULYH
Y
6\VWHP VUHVSRQVH o 7KHSDJHWKDWVKRZVWKHFODVVDOVR FRQWDLQVDOLQNRUEXWWRQQDPHGFUHDWH EXLOGILOH o 7KHV\VWHPGHWHUPLQHVDOORWKHU FODVVHVWKHFODVVLQTXHVWLRQGHSHQGV XSRQDQGFUHDWHVDEXLOGILOHWKDW FRPSLOHVDOOWKHVHFODVVHVLQWKHULJKW RUGHU7KHFRQWHQWVRIWKHEXLGILOHLV VKRZQRQVFUHHQ
$9LVLWRU3DWWHUQ 'H]H DSSHQGL[ LOOXVWUHHUW ppQ YDQ GH RQWZHUSVSDWURQHQ DDQJHZHQG ELM GH RQWZLNNHOLQJ YDQ GH -DYD;0/UHSRVLWRU\+HW9LVLWRUSDWURRQZHUG JHEUXLNWELMKHWRQWZHUSYDQHHQSDUVHUYRRUGH FRQYHUVLHYDQ -DYDEURQEHVWDQGHQQDDU;0/DDQGHKDQGYDQ-7% ]LHRRN +HWSDWURRQ EHVFKULMIWKHWYLVLWRUFRQFHSWGHZHUNLQJLPSOHPHQWDWLHHYHQDOVGHYRRU HQQDGHOHQ $XWKRU 6KLYHVK9LVZDQDWKDQ 'DWH6XEPLWWHG $SULO ,QWURGXFWLRQ 9LVLWRUSDWWHUQLVDEHKDYLRUDOGHVLJQSDWWHUQ2QHRIWKHPDLQFRQVLGHUDWLRQVLQGHFLGLQJXSRQD GDWD VWUXFWXUH IRU \RXU DSSOLFDWLRQ LV WKH W\SH RI RSHUDWLRQV \RX ZRXOG OLNH WR SHUIRUP RQ WKDW SDUWLFXODU GDWD LQ RWKHU ZRUGV WKH EHKDYLRU RI \RXU SURJUDP9LVLWRU SDWWHUQ LV XVHGZKHQ \RXU SURGXFW GHYHORSPHQW OLIH F\FOH UHTXLUHV IUHTXHQWDGGLWLRQUHPRYDORIRSHUDWLRQVZKLFK DUHWREH SHUIRUPHG RQ WKH GDWD VWUXFWXUH /LNH PDQ\ RWKHU GHVLJQ SDWWHUQV LW FDQ EH XVHG ZLWK DQ\ GDWD VWUXFWXUH 7DUJHW 9LVLWRU GHVLJQ SDWWHUQ WDUJHWV WKH NLQG RI DSSOLFDWLRQV LQ ZKLFK \RXU VWUXFWXUH RI GDWD GRHVQ W FKDQJH YHU\ RIWHQ EHVW LI LW GRHVQ W EXW WKH RSHUDWLRQV NHHS FKDQJLQJ YHU\ RIWHQ DV \RX SURJUHVVZLWK\RXUSURGXFWGHYHORSPHQW 7KHSDWWHUQ /HW V WDNH WKH H[DPSOH RI D WUHH ZKLFK FRQVLVWLQJ RI RQH W\SH RI QRGH ,Q & \RXU SUHRUGHU DOJRULWKPZRXOGSUREDEO\ORRNOLNHWKLV WUDY3UHRUGHU VWUXFWQRGH URRW+DQGOHU)XQFRSHUDWLRQ ^
L
7KH & VROXWLRQ WR VXFK D SUREOHP ZRXOG EH WR GHFODUH DQ DEVWUDFW EDVH FODVV FDOOHG VD\ &2SHUDWLRQ &ODVV&2SHUDWLRQ ^ +DQGOH1RGH VWUXFWQRGH QRGH `
LL
` &%W\SH1RGH $FFHSW2SHUDWLRQ &2SHUDWLRQ RSHUDWLRQ ^ RSHUDWLRQ!+DQGOH%W\SH1RGH WKLV ` 2SHUDWLRQFODVVKDVRQHIXQFWLRQIRUHDFKW\SHRIQRGH &ODVV&2SHUDWLRQ ^ +DQGOH$W\SH1RGH VWUXFWDQRGH QRGH +DQGOH%W\SH1RGH VWUXFWEQRGH QRGH +DQGOH&W\SH1RGH VWUXFWFQRGH QRGH $QGVRRQ ` +HQFH ZKLFK RI WKHVH IXQFWLRQV LV FDOOHG GHSHQGV RQ WZR WKLQJV :KLFK QRGH V $FFHSW2SHUDWLRQ LVFDOOHGDQGZKLFKRSHUDWLRQ V+DQGOH;;;1RGH LVFDOOHG 6R \RX VHH WUDYHUVDO DOJRULWKPV UHPDLQ LQGHSHQGHQW RI WKH QRGHV DQG RSHUDWLRQV +RZHYHU WKH PDMRU GUDZEDFN RI 9LVLWRU SDWWHUQ OLHV KHUH (DFK WLPH \RX DGG D W\SH RI QRGH \RX PRGLI\ RSHUDWLRQWRPDNHLWDZDUHRIWKDWQRGH 'UDZEDFNV 9LVLWRU SDWWHUQ FDQ RQO\ EH XVHG LQ FDVH \RX KDYH \RXU KLHUDUFK\ RI QRGHV ZHOO GHILQHG ,I \RX DGG D QRGH \RX KDYHWRDGGDIXQFWLRQ+DQGOH7KDWW\SH1RGH WRWKHDEVWUDFWFODVV&2SHUDWLRQ EUHDNLQJWKHZKROHVWUXFWXUHIURPWRSWRERWWRPZKLFKFRXOGEHDSUHWW\EDGLGHD 7KH RSHUDWLRQ REMHFW QHHGV WR DFFHVV WKH QRGH WR SHUIRUP WKH RSHUDWLRQ RYHU LW 7KLV UHTXLUHV QRGH WR H[SRVH LWV LQWHUQDO VWUXFWXUH WR WKH RSHUDWLRQ 1RZ LI WKH RSHUDWLRQ LV FRQVLGHUHG DV D ORJLFDO H[WHQVLRQ WR WKH QRGH DV PRVW & IDQV ZRXOG SXW LW WKH RSHUDWLRQ FRXOG EH JLYHQ VSHFLDOSULYLOHJH,Q&\RXFDQGRWKLVE\KDYLQJWKHRSHUDWLRQDVIULHQGRIQRGH 6SHFLILFDGYDQWDJHV 9LVLWRU SDWWHUQ PD\ EH XVHG IRU WRWDOO\ XQUHODWHG QRGH W\SHV DV ORQJ DV \RX FDQ WUDYHUVH WKHP
LLL
$-DYD;0/'7'
'H]H DSSHQGL[ LOOXVWUHHUW GH '7' RSJHVWHOG YRRU GH IRUPHOH GHILQLWH YDQ ;0/ EHVWDQGHQ JHJHQHUHHUGGRRUGH-DYD;0/FOLHQW "[POHQFRGLQJ 87)"!
'7'YRRU-DYD;0/ILOHV± 5DPL+DQVHQQH !
(/(0(17DOORFDWLRQBH[SUHVVLRQ 3&'$7$_DUJXPHQWV_SULPLWLYHBW\SH_DUUD\BGLPVBDQGBLQLWV ! (/(0(17DUJXPHQWBOLVW 3&'$7$_H[SUHVVLRQ ! (/(0(17DUJXPHQWV 3&'$7$_DUJXPHQWBOLVW ! (/(0(17DUUD\BGLPVBDQGBLQLWV 3&'$7$_H[SUHVVLRQ_DUUD\BLQLWLDOL]HU ! (/(0(17DUUD\BLQLWLDOL]HU 3&'$7$_YDULDEOHBLQLWLDOL]HU ! (/(0(17DVVLJQPHQWBRSHUDWRU 3&'$7$ ! (/(0(17EORFN EORFNBRSHQEORFNBVWDWHPHQW EORFNBFORVH ! (/(0(17EORFNBFORVH 3&'$7$_FRPPHQW ! (/(0(17EORFNBRSHQ 3&'$7$ ! (/(0(17EORFNBVWDWHPHQW 3&'$7$_VWDWHPHQW_ORFDOBYDULDEOHBGHFODUDWLRQ ! (/(0(17ERROHDQBOLWHUDO 3&'$7$ ! (/(0(17EUHDN 3&'$7$_FRPPHQW ! (/(0(17EUHDNBVWDWHPHQW 3&'$7$_EUHDN ! (/(0(17FDWFK 3&'$7$_IRUPDOBSDUDPHWHU_EORFN_FRPPHQW ! (/(0(17FODVVBERG\ ILHOGBGHFODUDWLRQLQLWLDOL]HU "ILHOGBGHFODUDWLRQ FRQVWUXFWRUBGHFODUDWLRQPHWKRGBGHFODUDWLRQ _ ILHOGBGHFODUDWLRQ_ FRQVWUXFWRUBGHFODUDWLRQ "PHWKRGBGHFODUDWLRQ _FRQVWUXFWRUBGHFODUDWLRQ ! (/(0(17FODVVBGHFODUDWLRQ PRGLILHUXQPRGLILHGBFODVVBGHFODUDWLRQ ! $77/,67FODVVBGHFODUDWLRQ,'&'$7$,03/,('! (/(0(17FODVVBQDPH 3&'$7$ ! (/(0(17FRPPHQW 3&'$7$_FRPPHQWBOLQH ! (/(0(17FRPPHQWBOLQH 3&'$7$ ! (/(0(17FRQVWUXFWRUBGHFODUDWLRQ 3&'$7$_PRGLILHU_FRQVWUXFWRUBQDPH_IRUPDOBSDUDPHWHUV_WKURZVBVWDWHPHQW_ H[SOLFLWBFRQVWUXFWRUBLQYRFDWLRQ_EORFNBVWDWHPHQW ! (/(0(17FRQVWUXFWRUBQDPH 3&'$7$ ! (/(0(17FRQWLQXH 3&'$7$ ! (/(0(17FRQWLQXHBVWDWHPHQW 3&'$7$_FRQWLQXH ! (/(0(17GR 3&'$7$ ! (/(0(17GRBVWDWHPHQW 3&'$7$_GR_VWDWHPHQW_ZKLOH_H[SUHVVLRQ ! (/(0(17H[SOLFLWBFRQVWUXFWRUBLQYRFDWLRQ 3&'$7$_DUJXPHQWV ! (/(0(17H[SUHVVLRQ 3&'$7$_OLWHUDO_DOORFDWLRQBH[SUHVVLRQ_DUJXPHQWV_H[SUHVVLRQ_W\SH_ DVVLJQPHQWBRSHUDWRU ! (/(0(17H[WHQGV 3&'$7$ ! (/(0(17ILHOGBGHFODUDWLRQ 3&'$7$_PRGLILHU_W\SH_YDULDEOHBGHFODUDWRU ! (/(0(17ILQDOO\ 3&'$7$_EORFN ! (/(0(17IRU 3&'$7$_FRPPHQW ! (/(0(17IRUBLQLW VWDWHPHQWBH[SUHVVLRQBOLVW_ORFDOBYDULDEOHBGHFODUDWLRQ ! (/(0(17IRUBVWDWHPHQW 3&'$7$_IRU_IRUBLQLW_H[SUHVVLRQ_VWDWHPHQW_IRUBXSGDWH ! (/(0(17IRUBXSGDWH VWDWHPHQWBH[SUHVVLRQBOLVW ! (/(0(17IRUPDOBSDUDPHWHU PRGLILHUW\SHYDULDEOHBGHFODUDWRUBLG ! (/(0(17IRUPDOBSDUDPHWHUV 3&'$7$_IRUPDOBSDUDPHWHU ! (/(0(17LI 3&'$7$_FRPPHQW ! (/(0(17LIBVWDWHPHQW 3&'$7$_LI_H[SUHVVLRQ_VWDWHPHQW_FRPPHQW ! (/(0(17LPSOHPHQWV 3&'$7$_QDPHBOLVW ! (/(0(17LPSRUWBGHFODUDWLRQ 3&'$7$_LPSRUWBSDFNDJH_FRPPHQW ! (/(0(17LPSRUWBSDFNDJH 3&'$7$ ! (/(0(17LQLWLDOL]HU PRGLILHUEORFN ! (/(0(17MDYD[POBURRW MDYDBVRXUFHBFRGHVWDWLVWLFV ! (/(0(17MDYDBVRXUFHBFRGH SDFNDJHBGHFODUDWLRQLPSRUWBGHFODUDWLRQW\SHBGHFODUDWLRQFRPPHQW _ SDFNDJHB GHFODUDWLRQ_LPSRUWBGHFODUDWLRQ W\SHBGHFODUDWLRQ ! (/(0(17OLWHUDO 3&'$7$_QXOOBOLWHUDO_ERROHDQBOLWHUDO_FRPPHQW ! (/(0(17ORFDOBYDULDEOHBGHFODUDWLRQ PRGLILHUW\SHYDULDEOHBGHFODUDWRU ! (/(0(17PHWKRGBGHFODUDWLRQ 3&'$7$_PRGLILHU_UHVXOWBW\SH_PHWKRGBGHFODUDWRU_EORFN_QDPHBOLVW !
L
$77/,67PHWKRGBGHFODUDWLRQ,'&'$7$,03/,('! (/(0(17PHWKRGBGHFODUDWRU PHWKRGBQDPHIRUPDOBSDUDPHWHUV ! (/(0(17PHWKRGBQDPH 3&'$7$ ! (/(0(17PRGLILHU 3&'$7$_FRPPHQW ! (/(0(17QDPHBOLVW 3&'$7$ ! (/(0(17QUBRIBFODVVHV(037
LL
$-DYD;0/6FKHPD
'H]H DSSHQGL[ LOOXVWUHHUW KHW ;0/ 6FKHPD RSJHVWHOG YRRU GH IRUPHOH GHILQLWH YDQ ;0/ EHVWDQGHQJHJHQHUHHUGGRRUGH-DYD;0/FOLHQW VFKHPD[POQV KWWS ZZZZRUJ ;0/6FKHPD ! ;0/6FKHPDIRU-DYD;0/JHQHUDWHGILOHV! &RS\ULJKW5DPL+DQVHQQH!
HOHPHQWQDPH DOORFDWLRQBH[SUHVVLRQ! FRPSOH[7\SHFRQWHQW PL[HG! JURXSPD[2FFXUV
PLQ2FFXUV ! FKRLFH! HOHPHQWQDPH DUJXPHQWV! HOHPHQWQDPH SULPLWLYHBW\SH! HOHPHQWQDPH DUUD\BGLPVBDQGBLQLWV! FKRLFH! JURXS! FRPSOH[7\SH! HOHPHQW! HOHPHQWQDPH DUJXPHQWBOLVW! FRPSOH[7\SHFRQWHQW PL[HG! JURXSPD[2FFXUV
PLQ2FFXUV ! FKRLFH! HOHPHQWQDPH H[SUHVVLRQ! FKRLFH! JURXS! FRPSOH[7\SH! HOHPHQW!
HOHPHQWQDPH DUJXPHQWV! FRPSOH[7\SHFRQWHQW PL[HG! JURXSPD[2FFXUV
PLQ2FFXUV ! FKRLFH! HOHPHQWQDPH DUJXPHQWBOLVW! FKRLFH! JURXS! FRPSOH[7\SH! HOHPHQW!
HOHPHQWQDPH DUUD\BGLPVBDQGBLQLWV! FRPSOH[7\SHFRQWHQW PL[HG! JURXSPD[2FFXUV
PLQ2FFXUV ! FKRLFH! HOHPHQWQDPH H[SUHVVLRQ! HOHPHQWQDPH DUUD\BLQLWLDOL]HU! FKRLFH! JURXS! FRPSOH[7\SH! HOHPHQW!
HOHPHQWQDPH DUUD\BLQLWLDOL]HU! FRPSOH[7\SHFRQWHQW PL[HG! JURXSPD[2FFXUV
PLQ2FFXUV ! FKRLFH! HOHPHQWQDPH YDULDEOHBLQLWLDOL]HU! FKRLFH! JURXS! FRPSOH[7\SH! HOHPHQW!
HOHPHQWQDPH DVVLJQPHQWBRSHUDWRU! VLPSOH7\SHQDPH DVVLJQPHQWBRSHUDWRUEDVH VWULQJ! HOHPHQW! HOHPHQWQDPH EORFN! FRPSOH[7\SHFRQWHQW HOHPHQW2QO\! VHTXHQFH! HOHPHQWQDPH EORFNBRSHQ! HOHPHQWQDPH EORFNBVWDWHPHQWPD[2FFXUV
PLQ2FFXUV ! HOHPHQWQDPH EORFNBFORVH!
L
VHTXHQFH! FRPSOH[7\SH! HOHPHQW!
HOHPHQWQDPH EORFNBFORVH! FRPSOH[7\SHFRQWHQW PL[HG! JURXSPD[2FFXUV
PLQ2FFXUV ! FKRLFH! HOHPHQWQDPH FRPPHQW! FKRLFH! JURXS! FRPSOH[7\SH! HOHPHQW!
HOHPHQWQDPH EORFNBRSHQ! VLPSOH7\SHQDPH EORFNBRSHQEDVH VWULQJ! HOHPHQW!
HOHPHQWQDPH EORFNBVWDWHPHQW! FRPSOH[7\SHFRQWHQW PL[HG! JURXSPD[2FFXUV
PLQ2FFXUV ! FKRLFH! HOHPHQWQDPH VWDWHPHQW! HOHPHQWQDPH ORFDOBYDULDEOHBGHFODUDWLRQ! FKRLFH! JURXS! FRPSOH[7\SH! HOHPHQW!
HOHPHQWQDPH ERROHDQBOLWHUDO! VLPSOH7\SHQDPH ERROHDQBOLWHUDOEDVH VWULQJ! HOHPHQW! HOHPHQWQDPH EUHDN! FRPSOH[7\SHFRQWHQW PL[HG! JURXSPD[2FFXUV
PLQ2FFXUV ! FKRLFH! HOHPHQWQDPH FRPPHQW! FKRLFH! JURXS! FRPSOH[7\SH! HOHPHQW! HOHPHQWQDPH EUHDNBVWDWHPHQW! FRPSOH[7\SHFRQWHQW PL[HG! JURXSPD[2FFXUV
PLQ2FFXUV ! FKRLFH! HOHPHQWQDPH EUHDN! FKRLFH! JURXS! FRPSOH[7\SH! HOHPHQW!
HOHPHQWQDPH FDWFK! FRPSOH[7\SHFRQWHQW PL[HG! JURXSPD[2FFXUV
PLQ2FFXUV ! FKRLFH! HOHPHQWQDPH IRUPDOBSDUDPHWHU! HOHPHQWQDPH EORFN! HOHPHQWQDPH FRPPHQW! FKRLFH! JURXS! FRPSOH[7\SH! HOHPHQW!
HOHPHQWQDPH FODVVBERG\! FRPSOH[7\SHFRQWHQW HOHPHQW2QO\! FKRLFH! VHTXHQFH! JURXSPLQ2FFXUV PD[2FFXUV ! VHTXHQFH! HOHPHQWQDPH ILHOGBGHFODUDWLRQPD[2FFXUV
! HOHPHQWQDPH LQLWLDOL]HU! VHTXHQFH! JURXS! HOHPHQWQDPH ILHOGBGHFODUDWLRQPD[2FFXUV
!
LL
HOHPHQWQDPH FRQVWUXFWRUBGHFODUDWLRQPD[2FFXUV
! HOHPHQWQDPH PHWKRGBGHFODUDWLRQPD[2FFXUV
! VHTXHQFH! VHTXHQFH! JURXSPLQ2FFXUV PD[2FFXUV ! FKRLFH! HOHPHQWQDPH ILHOGBGHFODUDWLRQPD[2FFXUV
! HOHPHQWQDPH FRQVWUXFWRUBGHFODUDWLRQ PD[2FFXUV
! FKRLFH! JURXS! HOHPHQWQDPH PHWKRGBGHFODUDWLRQPD[2FFXUV
! VHTXHQFH! HOHPHQWQDPH FRQVWUXFWRUBGHFODUDWLRQPD[2FFXUV
! FKRLFH! FRPSOH[7\SH! HOHPHQW! HOHPHQWQDPH FODVVBGHFODUDWLRQ! FRPSOH[7\SHFRQWHQW HOHPHQW2QO\! VHTXHQFH! HOHPHQWQDPH PRGLILHU! HOHPHQWQDPH XQPRGLILHGBFODVVBGHFODUDWLRQ! VHTXHQFH! DWWULEXWHQDPH ,'W\SH VWULQJPLQ2FFXUV ! FRPSOH[7\SH! HOHPHQW! HOHPHQWQDPH FODVVBQDPH! VLPSOH7\SHQDPH FODVVBQDPHEDVH VWULQJ! HOHPHQW! HOHPHQWQDPH FRPPHQW! FRPSOH[7\SHFRQWHQW PL[HG! JURXSPD[2FFXUV
PLQ2FFXUV ! FKRLFH! HOHPHQWQDPH FRPPHQWBOLQH! FKRLFH! JURXS! FRPSOH[7\SH! HOHPHQW!
HOHPHQWQDPH FRPPHQWBOLQH! VLPSOH7\SHQDPH FRPPHQWBOLQHEDVH VWULQJ! HOHPHQW!
HOHPHQWQDPH FRQVWUXFWRUBGHFODUDWLRQ! FRPSOH[7\SHFRQWHQW PL[HG! JURXSPD[2FFXUV
PLQ2FFXUV ! FKRLFH! HOHPHQWQDPH PRGLILHU! HOHPHQWQDPH FRQVWUXFWRUBQDPH! HOHPHQWQDPH IRUPDOBSDUDPHWHUV! HOHPHQWQDPH WKURZVBVWDWHPHQW! HOHPHQWQDPH H[SOLFLWBFRQVWUXFWRUBLQYRFDWLRQ! HOHPHQWQDPH EORFNBVWDWHPHQW! FKRLFH! JURXS! FRPSOH[7\SH! HOHPHQW! HOHPHQWQDPH FRQVWUXFWRUBQDPH! VLPSOH7\SHQDPH FRQVWUXFWRUBQDPHEDVH VWULQJ! HOHPHQW! HOHPHQWQDPH FRQWLQXH! VLPSOH7\SHQDPH FRQWLQXHEDVH VWULQJ! HOHPHQW! HOHPHQWQDPH FRQWLQXHBVWDWHPHQW! FRPSOH[7\SHFRQWHQW PL[HG! JURXSPD[2FFXUV
PLQ2FFXUV ! FKRLFH! HOHPHQWQDPH FRQWLQXH! FKRLFH! JURXS!
LLL
FRPSOH[7\SH! HOHPHQW!
HOHPHQWQDPH GR! VLPSOH7\SHQDPH GREDVH VWULQJ! HOHPHQW! HOHPHQWQDPH GRBVWDWHPHQW! FRPSOH[7\SHFRQWHQW PL[HG! JURXSPD[2FFXUV
PLQ2FFXUV ! FKRLFH! HOHPHQWQDPH GR! HOHPHQWQDPH VWDWHPHQW! HOHPHQWQDPH ZKLOH! HOHPHQWQDPH H[SUHVVLRQ! FKRLFH! JURXS! FRPSOH[7\SH! HOHPHQW!
HOHPHQWQDPH H[SOLFLWBFRQVWUXFWRUBLQYRFDWLRQ! FRPSOH[7\SHFRQWHQW PL[HG! JURXSPD[2FFXUV
PLQ2FFXUV ! FKRLFH! HOHPHQWQDPH DUJXPHQWV! FKRLFH! JURXS! FRPSOH[7\SH! HOHPHQW!
HOHPHQWQDPH H[SUHVVLRQ! FRPSOH[7\SHFRQWHQW PL[HG! JURXSPD[2FFXUV
PLQ2FFXUV ! FKRLFH! HOHPHQWQDPH OLWHUDO! HOHPHQWQDPH DOORFDWLRQBH[SUHVVLRQ! HOHPHQWQDPH DUJXPHQWV! HOHPHQWQDPH H[SUHVVLRQ! HOHPHQWQDPH W\SH! HOHPHQWQDPH DVVLJQPHQWBRSHUDWRU! FKRLFH! JURXS! FRPSOH[7\SH! HOHPHQW! HOHPHQWQDPH H[WHQGV! VLPSOH7\SHQDPH H[WHQGVEDVH VWULQJ! HOHPHQW!
HOHPHQWQDPH ILHOGBGHFODUDWLRQ! FRPSOH[7\SHFRQWHQW PL[HG! JURXSPD[2FFXUV
PLQ2FFXUV ! FKRLFH! HOHPHQWQDPH PRGLILHU! HOHPHQWQDPH W\SH! HOHPHQWQDPH YDULDEOHBGHFODUDWRU! FKRLFH! JURXS! FRPSOH[7\SH! HOHPHQW! HOHPHQWQDPH ILQDOO\! FRPSOH[7\SHFRQWHQW PL[HG! JURXSPD[2FFXUV
PLQ2FFXUV ! FKRLFH! HOHPHQWQDPH EORFN! FKRLFH! JURXS! FRPSOH[7\SH! HOHPHQW! HOHPHQWQDPH IRU! FRPSOH[7\SHFRQWHQW PL[HG! JURXSPD[2FFXUV
PLQ2FFXUV ! FKRLFH! HOHPHQWQDPH FRPPHQW!
LY
FKRLFH! JURXS! FRPSOH[7\SH! HOHPHQW!
HOHPHQWQDPH IRUBLQLW! FRPSOH[7\SHFRQWHQW HOHPHQW2QO\! FKRLFH! HOHPHQWQDPH VWDWHPHQWBH[SUHVVLRQBOLVW! HOHPHQWQDPH ORFDOBYDULDEOHBGHFODUDWLRQ! FKRLFH! FRPSOH[7\SH! HOHPHQW! HOHPHQWQDPH IRUBVWDWHPHQW! FRPSOH[7\SHFRQWHQW PL[HG! JURXSPD[2FFXUV
PLQ2FFXUV ! FKRLFH! HOHPHQWQDPH IRU! HOHPHQWQDPH IRUBLQLW! HOHPHQWQDPH H[SUHVVLRQ! HOHPHQWQDPH VWDWHPHQW! HOHPHQWQDPH IRUBXSGDWH! FKRLFH! JURXS! FRPSOH[7\SH! HOHPHQW!
HOHPHQWQDPH IRUBXSGDWH! FRPSOH[7\SHFRQWHQW HOHPHQW2QO\! HOHPHQWQDPH VWDWHPHQWBH[SUHVVLRQBOLVW! FRPSOH[7\SH! HOHPHQW! HOHPHQWQDPH IRUPDOBSDUDPHWHU! FRPSOH[7\SHFRQWHQW HOHPHQW2QO\! VHTXHQFH! HOHPHQWQDPH PRGLILHU! HOHPHQWQDPH W\SH! HOHPHQWQDPH YDULDEOHBGHFODUDWRUBLG! VHTXHQFH! FRPSOH[7\SH! HOHPHQW! HOHPHQWQDPH IRUPDOBSDUDPHWHUV! FRPSOH[7\SHFRQWHQW PL[HG! JURXSPD[2FFXUV
PLQ2FFXUV ! FKRLFH! HOHPHQWQDPH IRUPDOBSDUDPHWHU! FKRLFH! JURXS! FRPSOH[7\SH! HOHPHQW! HOHPHQWQDPH LI! FRPSOH[7\SHFRQWHQW PL[HG! JURXSPD[2FFXUV
PLQ2FFXUV ! FKRLFH! HOHPHQWQDPH FRPPHQW! FKRLFH! JURXS! FRPSOH[7\SH! HOHPHQW! HOHPHQWQDPH LIBVWDWHPHQW! FRPSOH[7\SHFRQWHQW PL[HG! JURXSPD[2FFXUV
PLQ2FFXUV ! FKRLFH! HOHPHQWQDPH LI! HOHPHQWQDPH H[SUHVVLRQ! HOHPHQWQDPH VWDWHPHQW! HOHPHQWQDPH FRPPHQW! FKRLFH! JURXS! FRPSOH[7\SH! HOHPHQW!
Y
HOHPHQWQDPH LPSOHPHQWV! FRPSOH[7\SHFRQWHQW PL[HG! JURXSPD[2FFXUV
PLQ2FFXUV ! FKRLFH! HOHPHQWQDPH QDPHBOLVW! FKRLFH! JURXS! FRPSOH[7\SH! HOHPHQW!
HOHPHQWQDPH LPSRUWBGHFODUDWLRQ! FRPSOH[7\SHFRQWHQW PL[HG! JURXSPD[2FFXUV
PLQ2FFXUV ! FKRLFH! HOHPHQWQDPH LPSRUWBSDFNDJH! HOHPHQWQDPH FRPPHQW! FKRLFH! JURXS! FRPSOH[7\SH! HOHPHQW!
HOHPHQWQDPH LPSRUWBSDFNDJH! VLPSOH7\SHQDPH LPSRUWBSDFNDJHEDVH VWULQJ! HOHPHQW! HOHPHQWQDPH LQLWLDOL]HU! FRPSOH[7\SHFRQWHQW HOHPHQW2QO\! VHTXHQFH! HOHPHQWQDPH PRGLILHU! HOHPHQWQDPH EORFN! VHTXHQFH! FRPSOH[7\SH! HOHPHQW!
HOHPHQWQDPH MDYD[POBURRW! FRPSOH[7\SHFRQWHQW HOHPHQW2QO\! VHTXHQFH! HOHPHQWQDPH MDYDBVRXUFHBFRGH! HOHPHQWQDPH VWDWLVWLFV! VHTXHQFH! FRPSOH[7\SH! HOHPHQW!
HOHPHQWQDPH MDYDBVRXUFHBFRGH! FRPSOH[7\SHFRQWHQW HOHPHQW2QO\! FKRLFH! VHTXHQFH! HOHPHQWQDPH SDFNDJHBGHFODUDWLRQ! HOHPHQWQDPH LPSRUWBGHFODUDWLRQPD[2FFXUV
! HOHPHQWQDPH W\SHBGHFODUDWLRQPD[2FFXUV
! HOHPHQWQDPH FRPPHQWPD[2FFXUV
PLQ2FFXUV ! VHTXHQFH! VHTXHQFH! FKRLFH! HOHPHQWQDPH SDFNDJHBGHFODUDWLRQ! HOHPHQWQDPH LPSRUWBGHFODUDWLRQPD[2FFXUV
! FKRLFH! HOHPHQWQDPH W\SHBGHFODUDWLRQ! VHTXHQFH! FKRLFH! FRPSOH[7\SH! HOHPHQW! HOHPHQWQDPH OLWHUDO! FRPSOH[7\SHFRQWHQW PL[HG! JURXSPD[2FFXUV
PLQ2FFXUV ! FKRLFH! HOHPHQWQDPH QXOOBOLWHUDO! HOHPHQWQDPH ERROHDQBOLWHUDO! HOHPHQWQDPH FRPPHQW! FKRLFH! JURXS! FRPSOH[7\SH! HOHPHQW!
YL
HOHPHQWQDPH ORFDOBYDULDEOHBGHFODUDWLRQ! FRPSOH[7\SHFRQWHQW HOHPHQW2QO\! VHTXHQFH! HOHPHQWQDPH PRGLILHU! HOHPHQWQDPH W\SH! HOHPHQWQDPH YDULDEOHBGHFODUDWRU! VHTXHQFH! FRPSOH[7\SH! HOHPHQW!
HOHPHQWQDPH PHWKRGBGHFODUDWLRQ! FRPSOH[7\SHFRQWHQW PL[HG! JURXSPD[2FFXUV
PLQ2FFXUV ! FKRLFH! HOHPHQWQDPH PRGLILHU! HOHPHQWQDPH UHVXOWBW\SH! HOHPHQWQDPH PHWKRGBGHFODUDWRU! HOHPHQWQDPH EORFN! HOHPHQWQDPH QDPHBOLVW! FKRLFH! JURXS!
DWWULEXWHQDPH ,'W\SH VWULQJPLQ2FFXUV ! FRPSOH[7\SH! HOHPHQW! HOHPHQWQDPH PHWKRGBGHFODUDWRU! FRPSOH[7\SHFRQWHQW HOHPHQW2QO\! VHTXHQFH! HOHPHQWQDPH PHWKRGBQDPH! HOHPHQWQDPH IRUPDOBSDUDPHWHUV! VHTXHQFH! FRPSOH[7\SH! HOHPHQW!
HOHPHQWQDPH PHWKRGBQDPH! VLPSOH7\SHQDPH PHWKRGBQDPHEDVH VWULQJ! HOHPHQW! HOHPHQWQDPH PRGLILHU! FRPSOH[7\SHFRQWHQW PL[HG! JURXSPD[2FFXUV
PLQ2FFXUV ! FKRLFH! HOHPHQWQDPH FRPPHQW! FKRLFH! JURXS! FRPSOH[7\SH! HOHPHQW!
HOHPHQWQDPH QDPHBOLVW! VLPSOH7\SHQDPH QDPHBOLVWEDVH VWULQJ! HOHPHQW! HOHPHQWQDPH QUBRIBFODVVHV! FRPSOH[7\SHFRQWHQW HPSW\! DWWULEXWHQDPH QUW\SH VWULQJPLQ2FFXUV ! FRPSOH[7\SH! HOHPHQW! HOHPHQWQDPH QUBRIBFRGHOLQHV! FRPSOH[7\SHFRQWHQW HPSW\! DWWULEXWHQDPH QUW\SH VWULQJPLQ2FFXUV ! FRPSOH[7\SH! HOHPHQW!
HOHPHQWQDPH QUBRIBPHWKRGV! FRPSOH[7\SHFRQWHQW HPSW\! DWWULEXWHQDPH QUW\SH VWULQJPLQ2FFXUV ! FRPSOH[7\SH! HOHPHQW! HOHPHQWQDPH QUBRIBVWDWHPHQWV! FRPSOH[7\SHFRQWHQW HPSW\! DWWULEXWHQDPH QUW\SH VWULQJPLQ2FFXUV ! FRPSOH[7\SH!
YLL
HOHPHQW!
HOHPHQWQDPH QXOOBOLWHUDO! VLPSOH7\SHQDPH QXOOBOLWHUDOEDVH VWULQJ! HOHPHQW! HOHPHQWQDPH SDFNDJH! FRPSOH[7\SHFRQWHQW PL[HG! JURXSPD[2FFXUV
PLQ2FFXUV ! FKRLFH! HOHPHQWQDPH FRPPHQW! FKRLFH! JURXS! FRPSOH[7\SH! HOHPHQW! HOHPHQWQDPH SDFNDJHBGHFODUDWLRQ! FRPSOH[7\SHFRQWHQW PL[HG! JURXSPD[2FFXUV
PLQ2FFXUV ! FKRLFH! HOHPHQWQDPH SDFNDJH!
HOHPHQWQDPH SDFNDJHBQDPH! FKRLFH! JURXS! FRPSOH[7\SH! HOHPHQW!
HOHPHQWQDPH SDFNDJHBQDPH! VLPSOH7\SHQDPH SDFNDJHBQDPHEDVH VWULQJ! HOHPHQW! HOHPHQWQDPH SUHBGHFUHPHQWBH[SUHVVLRQ! FRPSOH[7\SHFRQWHQW PL[HG! JURXSPD[2FFXUV
PLQ2FFXUV ! FKRLFH! HOHPHQWQDPH FRPPHQW! FKRLFH! JURXS! FRPSOH[7\SH! HOHPHQW!
HOHPHQWQDPH SUHBLQFUHPHQWBH[SUHVVLRQ! VLPSOH7\SHQDPH SUHBLQFUHPHQWBH[SUHVVLRQEDVH VWULQJ! HOHPHQW! HOHPHQWQDPH SULPLWLYHBW\SH! FRPSOH[7\SHFRQWHQW PL[HG! JURXSPD[2FFXUV
PLQ2FFXUV ! FKRLFH! HOHPHQWQDPH FRPPHQW! FKRLFH! JURXS! FRPSOH[7\SH! HOHPHQW! HOHPHQWQDPH UHVXOWBW\SH! FRPSOH[7\SHFRQWHQW PL[HG! JURXSPD[2FFXUV
PLQ2FFXUV ! FKRLFH! HOHPHQWQDPH W\SH! HOHPHQWQDPH FRPPHQW! FKRLFH! JURXS! FRPSOH[7\SH! HOHPHQW! HOHPHQWQDPH UHWXUQ! FRPSOH[7\SHFRQWHQW PL[HG! JURXSPD[2FFXUV
PLQ2FFXUV ! FKRLFH! HOHPHQWQDPH FRPPHQW! FKRLFH! JURXS! FRPSOH[7\SH! HOHPHQW!
YLLL
HOHPHQWQDPH UHWXUQBVWDWHPHQW! FRPSOH[7\SHFRQWHQW PL[HG! JURXSPD[2FFXUV
PLQ2FFXUV ! FKRLFH! HOHPHQWQDPH UHWXUQ! HOHPHQWQDPH H[SUHVVLRQ! FKRLFH! JURXS! FRPSOH[7\SH! HOHPHQW!
HOHPHQWQDPH VWDWHPHQW! FRPSOH[7\SHFRQWHQW PL[HG! JURXSPD[2FFXUV
PLQ2FFXUV ! FKRLFH! HOHPHQWQDPH WU\BVWDWHPHQW! HOHPHQWQDPH LIBVWDWHPHQW! HOHPHQWQDPH WKURZBVWDWHPHQW! HOHPHQWQDPH EORFN! HOHPHQWQDPH VWDWHPHQWBH[SUHVVLRQ! HOHPHQWQDPH UHWXUQBVWDWHPHQW! HOHPHQWQDPH IRUBVWDWHPHQW! HOHPHQWQDPH VZLWFKBVWDWHPHQW! HOHPHQWQDPH EUHDNBVWDWHPHQW! HOHPHQWQDPH GRBVWDWHPHQW! HOHPHQWQDPH ZKLOHBVWDWHPHQW! HOHPHQWQDPH FRQWLQXHBVWDWHPHQW! FKRLFH! JURXS!
DWWULEXWHQDPH ,'W\SH VWULQJPLQ2FFXUV ! FRPSOH[7\SH! HOHPHQW! HOHPHQWQDPH VWDWHPHQWBH[SUHVVLRQ! FRPSOH[7\SHFRQWHQW PL[HG! JURXSPD[2FFXUV
PLQ2FFXUV ! FKRLFH! HOHPHQWQDPH DVVLJQPHQWBRSHUDWRU! HOHPHQWQDPH H[SUHVVLRQ! HOHPHQWQDPH DUJXPHQWV HOHPHQWQDPH FRPPHQW! HOHPHQWQDPH SUHBLQFUHPHQWBH[SUHVVLRQ! HOHPHQWQDPH SUHBGHFUHPHQWBH[SUHVVLRQ! HOHPHQWQDPH OLWHUDO! HOHPHQWQDPH DOORFDWLRQBH[SUHVVLRQ! FKRLFH! JURXS! FRPSOH[7\SH! HOHPHQW! HOHPHQWQDPH VWDWHPHQWBH[SUHVVLRQBOLVW! FRPSOH[7\SHFRQWHQW HOHPHQW2QO\! HOHPHQWQDPH VWDWHPHQWBH[SUHVVLRQ! FRPSOH[7\SH! HOHPHQW! HOHPHQWQDPH VWDWLVWLFV! FRPSOH[7\SHFRQWHQW HOHPHQW2QO\! VHTXHQFH! HOHPHQWQDPH QUBRIBFRGHOLQHV! HOHPHQWQDPH QUBRIBFODVVHV! HOHPHQWQDPH QUBRIBPHWKRGV! HOHPHQWQDPH QUBRIBVWDWHPHQWV! VHTXHQFH! FRPSOH[7\SH! HOHPHQW!
HOHPHQWQDPH VZLWFK! VLPSOH7\SHQDPH VZLWFKEDVH VWULQJ! HOHPHQW! HOHPHQWQDPH VZLWFKBODEHO! FRPSOH[7\SHFRQWHQW PL[HG!
L[
JURXSPD[2FFXUV
PLQ2FFXUV ! FKRLFH! HOHPHQWQDPH H[SUHVVLRQ! HOHPHQW QDPH FRPPHQW! FKRLFH! JURXS! FRPSOH[7\SH! HOHPHQW!
HOHPHQWQDPH VZLWFKBVWDWHPHQW! FRPSOH[7\SHFRQWHQW PL[HG! JURXSPD[2FFXUV
PLQ2FFXUV ! FKRLFH! HOHPHQWQDPH VZLWFK! HOHPHQWQDPH H[SUHVVLRQ! HOHPHQWQDPH VZLWFKBODEHO! HOHPHQWQDPH EORFNBVWDWHPHQW! FKRLFH! JURXS! FRPSOH[7\SH! HOHPHQW! HOHPHQWQDPH WKURZ! FRPSOH[7\SHFRQWHQW PL[HG! JURXSPD[2FFXUV
PLQ2FFXUV ! FKRLFH! HOHPHQWQDPH FRPPHQW! FKRLFH! JURXS! FRPSOH[7\SH! HOHPHQW!
HOHPHQWQDPH WKURZBVWDWHPHQW! FRPSOH[7\SHFRQWHQW PL[HG! JURXSPD[2FFXUV
PLQ2FFXUV ! FKRLFH! HOHPHQWQDPH WKURZ! HOHPHQWQDPH H[SUHVVLRQ! FKRLFH! JURXS! FRPSOH[7\SH! HOHPHQW! HOHPHQWQDPH WKURZVBVWDWHPHQW! FRPSOH[7\SHFRQWHQW PL[HG! JURXSPD[2FFXUV
PLQ2FFXUV ! FKRLFH! HOHPHQWQDPH QDPHBOLVW! FKRLFH! JURXS! FRPSOH[7\SH! HOHPHQW! HOHPHQWQDPH WU\! FRPSOH[7\SHFRQWHQW PL[HG! JURXSPD[2FFXUV
PLQ2FFXUV ! FKRLFH! HOHPHQWQDPH FRPPHQW! FKRLFH! JURXS! FRPSOH[7\SH! HOHPHQW! HOHPHQWQDPH WU\BVWDWHPHQW! FRPSOH[7\SHFRQWHQW HOHPHQW2QO\! VHTXHQFH! HOHPHQWQDPH WU\! HOHPHQWQDPH EORFN ! HOHPHQWQDPH FDWFK! HOHPHQWQDPH ILQDOO\! VHTXHQFH! FRPSOH[7\SH! HOHPHQW! HOHPHQWQDPH W\SH! FRPSOH[7\SHFRQWHQW PL[HG!
[
JURXSPD[2FFXUV
PLQ2FFXUV ! FKRLFH! HOHPHQWQDPH SULPLWLYHBW\SH! HOHPHQWQDPH FRPPHQW! FKRLFH! JURXS! FRPSOH[7\SH! HOHPHQW! HOHPHQWQDPH W\SHBGHFODUDWLRQ! FRPSOH[7\SHFRQWHQW HOHPHQW2QO\! HOHPHQWQDPH FODVVBGHFODUDWLRQ! FRPSOH[7\SH! HOHPHQW!
HOHPHQWQDPH XQPRGLILHGBFODVVBGHFODUDWLRQ! FRPSOH[7\SHFRQWHQW PL[HG! JURXSPD[2FFXUV
PLQ2FFXUV ! FKRLFH! HOHPHQWQDPH FODVVBQDPH! HOHPHQWQDPH H[WHQGV! HOHPHQWQDPH LPSOHPHQWV! HOHPHQWQDPH FODVVBERG\! HOHPHQWQDPH FRPPHQW! FKRLFH! JURXS! FRPSOH[7\SH! HOHPHQW!
HOHPHQWQDPH YDULDEOHBGHFODUDWRU! FRPSOH[7\SHFRQWHQW PL[HG! JURXSPD[2FFXUV
PLQ2FFXUV ! FKRLFH! HOHPHQWQDPH YDULDEOHBGHFODUDWRUBLG! HOHPHQWQDPH YDULDEOHBLQLWLDOL]HU! FKRLFH! JURXS! FRPSOH[7\SH! HOHPHQW! HOHPHQWQDPH YDULDEOHBGHFODUDWRUBLG! FRPSOH[7\SHFRQWHQW PL[HG! JURXSPD[2FFXUV
PLQ2FFXUV ! FKRLFH! HOHPHQWQDPH YDULDEOHBQDPH! FKRLFH! JURXS! FRPSOH[7\SH! HOHPHQW!
HOHPHQWQDPH YDULDEOHBLQLWLDOL]HU! FRPSOH[7\SHFRQWHQW HOHPHQW2QO\! FKRLFH! HOHPHQWQDPH DUUD\BLQLWLDOL]HU! HOHPHQWQDPH H[SUHVVLRQ! FKRLFH! FRPSOH[7\SH! HOHPHQW!
HOHPHQWQDPH YDULDEOHBQDPH! VLPSOH7\SHQDPH YDULDEOHBQDPHEDVH VWULQJ! HOHPHQW! HOHPHQWQDPH ZKLOH! FRPSOH[7\SHFRQWHQW PL[HG! JURXSPD[2FFXUV
PLQ2FFXUV ! FKRLFH! HOHPHQWQDPH FRPPHQW! FKRLFH! JURXS! FRPSOH[7\SH! HOHPHQW! HOHPHQWQDPH ZKLOHBVWDWHPHQW! FRPSOH[7\SHFRQWHQW PL[HG! JURXSPD[2FFXUV
PLQ2FFXUV !
[L
FKRLFH! HOHPHQWQDPH ZKLOH! HOHPHQWQDPH H[SUHVVLRQ! HOHPHQWQDPH VWDWHPHQW! FKRLFH! JURXS! FRPSOH[7\SH! HOHPHQW! VFKHPD!
[LL
$9RRUEHHOG-DYD;0/EHVWDQG
'H]H DSSHQGL[ LOOXVWUHHUW HHQ YRRUEHHOG ;0/ EHVWDQG ]RDOV JHJHQHUHHUG GRRU GH -DYD;0/ FOLHQW'LWLVGHYRUPYRRUGHOLQNLQVHUWLH+HWRQGHUVWDDQGHEHVWDQGYROGRHWDDQGH'7'HQKHW ;0/ZHHUJHJHYHQLQDSSHQGLFHV$HQ$ "[POYHUVLRQ HQFRGLQJ 87)"! -DYD;0/ILOHFUHDWHGE\-DYD;0/± ! MDYD[POBURRW! MDYDBVRXUFHBFRGH! LPSRUWBGHFODUDWLRQ!LPSRUW LPSRUWBSDFNDJH! QDPH!MDYDXWLO QDPH! LPSRUWBSDFNDJH! LPSRUWBGHFODUDWLRQ! LPSRUWBGHFODUDWLRQ!LPSRUW LPSRUWBSDFNDJH! QDPH!MDYDLR QDPH! LPSRUWBSDFNDJH! LPSRUWBGHFODUDWLRQ! W\SHBGHFODUDWLRQ! FODVVBGHFODUDWLRQ,' ! PRGLILHU! XQPRGLILHGBFODVVBGHFODUDWLRQ! FRPPHQW! FRPPHQWBOLQH!
FRPPHQWBOLQH! FRPPHQWBOLQH! FRPPHQWBOLQH! FRPPHQWBOLQH! 7KLVFODVVEXLOGVDOLVWRIDOOILOHVLQ DVSHFLILHGGLUHFWRU\DQG FRPPHQWBOLQH! FRPPHQWBOLQH! LWVVXEGLUHFWRULHV,IWKHVXSSOLHGSDWK LVQRWIRXQGDQHPSW\YHFWRU FRPPHQWBOLQH! FRPPHQWBOLQH! ZLOOEHUHWXUQHG FRPPHQWBOLQH! FRPPHQWBOLQH! FRPPHQWBOLQH! FRPPHQWBOLQH! #DXWKRU5DPL+DQVHQQH FRPPHQWBOLQH! FRPPHQWBOLQH! #YHUVLRQ9HUVLRQ FRPPHQWBOLQH! FRPPHQWBOLQH! FRPPHQWBOLQH! FRPPHQW! FODVV FODVVBQDPH!'LU:DONHU FODVVBQDPH! H[WHQGV! H[WHQGV! LPSOHPHQWV! LPSOHPHQWV! ^ FODVVBERG\! ILHOGBGHFODUDWLRQ! PRGLILHU!SULYDWH PRGLILHU! W\SH! QDPH!9HFWRU QDPH! W\SH! YDULDEOHBGHFODUDWRU! YDULDEOHBGHFODUDWRUBLG! YDULDEOHBQDPH!ILOHV YDULDEOHBQDPH! YDULDEOHBGHFODUDWRUBLG! YDULDEOHBGHFODUDWRU! ILHOGBGHFODUDWLRQ! ILHOGBGHFODUDWLRQ! PRGLILHU!SULYDWH PRGLILHU! W\SH! QDPH!6WULQJ QDPH! W\SH! YDULDEOHBGHFODUDWRU! YDULDEOHBGHFODUDWRUBLG! YDULDEOHBQDPH!EDVH3DWK YDULDEOHBQDPH! YDULDEOHBGHFODUDWRUBLG! YDULDEOHBGHFODUDWRU! ILHOGBGHFODUDWLRQ! FRQVWUXFWRUBGHFODUDWLRQ! PRGLILHU! FRQVWUXFWRUBQDPH! FRPPHQW!
L
FRPPHQWBOLQH!
FRPPHQWBOLQH! FRPPHQWBOLQH! &RQVWUXFWRU FRPPHQWBOLQH! FRPPHQWBOLQH! FRPPHQWBOLQH! FRPPHQWBOLQH! #SDUDPEDVH3DWK7KHSDWKWRWKH GLUHFWRU\WRLQGH[ FRPPHQWBOLQH! FRPPHQWBOLQH!
FRPPHQWBOLQH! FRPPHQW! 'LU:DONHU FRQVWUXFWRUBQDPH! IRUPDOBSDUDPHWHUV! IRUPDOBSDUDPHWHU! PRGLILHU! W\SH! QDPH!6WULQJ QDPH! W\SH! YDULDEOHBGHFODUDWRUBLG! YDULDEOHBQDPH!EDVH3DWK YDULDEOHBQDPH! YDULDEOHBGHFODUDWRUBLG! IRUPDOBSDUDPHWHU! IRUPDOBSDUDPHWHUV! WKURZVBVWDWHPHQW! WKURZVBVWDWHPHQW! ^ EORFNBVWDWHPHQW! VWDWHPHQW,' ! VWDWHPHQWBH[SUHVVLRQ!WKLVEDVH3DWK DVVLJQPHQWBRSHUDWRU! DVVLJQPHQWBRSHUDWRU! H[SUHVVLRQ! QDPH!EDVH3DWK QDPH! H[SUHVVLRQ! VWDWHPHQWBH[SUHVVLRQ!
VWDWHPHQW! EORFNBVWDWHPHQW! ` FRQVWUXFWRUBGHFODUDWLRQ! PHWKRGBGHFODUDWLRQ,' ! FRPPHQW! FRPPHQWBOLQH!
FRPPHQWBOLQH! FRPPHQWBOLQH! 7KLVPHWKRGLVXVHGWRVWDUWWKH GLUHFWRU\ZDONLQJSURFHVV FRPPHQWBOLQH! FRPPHQWBOLQH! FRPPHQWBOLQH! FRPPHQWBOLQH! #UHWXUQ7KH9HFWRUFRQWDLQLQJDOO ILOHQDPHV FRPPHQWBOLQH! FRPPHQWBOLQH! FRPPHQWBOLQH! FRPPHQW! PRGLILHU!SXEOLF PRGLILHU! UHVXOWBW\SH! W\SH! QDPH!9HFWRU QDPH! W\SH! UHVXOWBW\SH! PHWKRGBGHFODUDWRU! PHWKRGBQDPH!ZDON PHWKRGBQDPH! IRUPDOBSDUDPHWHUV! IRUPDOBSDUDPHWHUV! PHWKRGBGHFODUDWRU! EORFN! EORFNBRSHQ!^ EORFNBRSHQ! EORFNBVWDWHPHQW! VWDWHPHQW,' ! VWDWHPHQWBH[SUHVVLRQ! QDPH! FRPPHQW! FRPPHQWBOLQH!FXUUHQWOLVWLV HPSWLHG FRPPHQWBOLQH! FRPPHQW! ILOHV QDPH! DVVLJQPHQWBRSHUDWRU! DVVLJQPHQWBRSHUDWRU! H[SUHVVLRQ! DOORFDWLRQBH[SUHVVLRQ!QHZ QDPH!9HFWRU QDPH! DUJXPHQWV! DUJXPHQWV! DOORFDWLRQBH[SUHVVLRQ! H[SUHVVLRQ! VWDWHPHQWBH[SUHVVLRQ! VWDWHPHQW! EORFNBVWDWHPHQW! EORFNBVWDWHPHQW!
LL
VWDWHPHQW,' ! VWDWHPHQWBH[SUHVVLRQ! QDPH!ZDON QDPH! DUJXPHQWV! DUJXPHQWBOLVW! H[SUHVVLRQ! QDPH!EDVH3DWK QDPH! H[SUHVVLRQ! DUJXPHQWBOLVW! DUJXPHQWV! VWDWHPHQWBH[SUHVVLRQ! VWDWHPHQW! EORFNBVWDWHPHQW! EORFNBVWDWHPHQW! VWDWHPHQW,' ! UHWXUQBVWDWHPHQW! UHWXUQ!UHWXUQ UHWXUQ! H[SUHVVLRQ! QDPH!ILOHV QDPH! H[SUHVVLRQ! UHWXUQBVWDWHPHQW! VWDWHPHQW! EORFNBVWDWHPHQW! EORFNBFORVH!` EORFNBFORVH! EORFN! PHWKRGBGHFODUDWLRQ! PHWKRGBGHFODUDWLRQ ,' ! FRPPHQW! FRPPHQWBOLQH!
FRPPHQWBOLQH! FRPPHQWBOLQH! 7KLVPHWKRGUHFXUVLYHO\EXLOGVD YHFWRUFRQWDLQLQJDOOILOHQDPHV FRPPHQWBOLQH! FRPPHQWBOLQH! LQDJLYHGLUHFWRU\DQG VXEGLUHFWRULHV FRPPHQWBOLQH! FRPPHQWBOLQH! FRPPHQWBOLQH! FRPPHQWBOLQH! #SDUDPSDWK7KHSDWKWRWKHGLUHFWRU\ WRLQGH[ FRPPHQWBOLQH! FRPPHQWBOLQH! FRPPHQWBOLQH! FRPPHQW! PRGLILHU!SULYDWH PRGLILHU! UHVXOWBW\SH!YRLG UHVXOWBW\SH! PHWKRGBGHFODUDWRU! PHWKRGBQDPH!ZDON PHWKRGBQDPH! IRUPDOBSDUDPHWHUV! IRUPDOBSDUDPHWHU! PRGLILHU! W\SH! QDPH!6WULQJ QDPH! W\SH! YDULDEOHBGHFODUDWRUBLG! YDULDEOHBQDPH!SDWK YDULDEOHBQDPH! YDULDEOHBGHFODUDWRUBLG! IRUPDOBSDUDPHWHU! IRUPDOBSDUDPHWHUV! PHWKRGBGHFODUDWRU! EORFN! EORFNBRSHQ!^ EORFNBRSHQ! EORFNBVWDWHPHQW! ORFDOBYDULDEOHBGHFODUDWLRQ! PRGLILHU! W\SH! QDPH!)LOH QDPH! W\SH! YDULDEOHBGHFODUDWRU! YDULDEOHBGHFODUDWRUBLG! YDULDEOHBQDPH!I YDULDEOHBQDPH! YDULDEOHBGHFODUDWRUBLG! YDULDEOHBLQLWLDOL]HU! H[SUHVVLRQ! DOORFDWLRQBH[SUHVVLRQ!QHZ QDPH!)LOH QDPH! DUJXPHQWV! DUJXPHQWBOLVW! H[SUHVVLRQ! QDPH!SDWK QDPH! H[SUHVVLRQ!
LLL
DUJXPHQWBOLVW! DUJXPHQWV! DOORFDWLRQBH[SUHVVLRQ! H[SUHVVLRQ! YDULDEOHBLQLWLDOL]HU! YDULDEOHBGHFODUDWRU! ORFDOBYDULDEOHBGHFODUDWLRQ! EORFNBVWDWHPHQW! EORFNBVWDWHPHQW! VWDWHPHQW,' ! LIBVWDWHPHQW! LI!LI LI! H[SUHVVLRQ! QDPH!ILV)LOH QDPH! DUJXPHQWV! DUJXPHQWV! H[SUHVVLRQ! VWDWHPHQW,' ! VWDWHPHQWBH[SUHVVLRQ! QDPH!ILOHVDGG(OHPHQW QDPH! DUJXPHQWV! DUJXPHQWBOLVW! H[SUHVVLRQ! QDPH!SDWK QDPH! H[SUHVVLRQ! DUJXPHQWBOLVW! DUJXPHQWV! VWDWHPHQWBH[SUHVVLRQ! VWDWHPHQW! HOVH VWDWHPHQW,' ! LIBVWDWHPHQW! LI!LI LI! H[SUHVVLRQ! QDPH!ILV'LUHFWRU\ QDPH! DUJXPHQWV! DUJXPHQWV! H[SUHVVLRQ! VWDWHPHQW,' ! EORFN! EORFNBRSHQ!^ EORFNBRSHQ! EORFNBVWDWHPHQW! VWDWHPHQW,' ! LIBVWDWHPHQW! LI!LI LI! H[SUHVVLRQ! QDPH!SDWKHQGV:LWK QDPH! DUJXPHQWV! DUJXPHQWBOLVW! H[SUHVVLRQ! QDPH!)LOHVHSDUDWRU QDPH! H[SUHVVLRQ! DUJXPHQWBOLVW! DUJXPHQWV! H[SUHVVLRQ! VWDWHPHQW,' ! VWDWHPHQWBH[SUHVVLRQ! QDPH!SDWK QDPH! DVVLJQPHQWBRSHUDWRU! DVVLJQPHQWBRSHUDWRU! H[SUHVVLRQ! QDPH!)LOHVHSDUDWRU QDPH! H[SUHVVLRQ! VWDWHPHQWBH[SUHVVLRQ! VWDWHPHQW! LIBVWDWHPHQW! VWDWHPHQW! EORFNBVWDWHPHQW! EORFNBVWDWHPHQW! ORFDOBYDULDEOHBGHFODUDWLRQ! PRGLILHU! W\SH!
LY
QDPH!6WULQJ QDPH! W\SH! YDULDEOHBGHFODUDWRU! YDULDEOHBGHFODUDWRUBLG! YDULDEOHBQDPH!OLVW YDULDEOHBQDPH! >@ YDULDEOHBGHFODUDWRUBLG!
YDULDEOHBLQLWLDOL]HU! H[SUHVVLRQ! QDPH!IOLVW QDPH! DUJXPHQWV! DUJXPHQWV! H[SUHVVLRQ! YDULDEOHBLQLWLDOL]HU! YDULDEOHBGHFODUDWRU! ORFDOBYDULDEOHBGHFODUDWLRQ! EORFNBVWDWHPHQW! EORFNBVWDWHPHQW! VWDWHPHQW,' ! IRUBVWDWHPHQW! IRU! FRPPHQW! FRPPHQWBOLQH!3URFHVVDOOILOHV UHFXUVLYO\ FRPPHQWBOLQH! FRPPHQW! IRU IRU! IRUBLQLW! ORFDOBYDULDEOHBGHFODUDWLRQ! PRGLILHU! W\SH! SULPLWLYHBW\SH! LQW SULPLWLYHBW\SH! W\SH! YDULDEOHBGHFODUDWRU! YDULDEOHBGHFODUDWRUBLG! YDULDEOHBQDPH!L YDULDEOHBQDPH! YDULDEOHBGHFODUDWRUBLG! YDULDEOHBLQLWLDOL]HU! H[SUHVVLRQ! OLWHUDO! OLWHUDO! H[SUHVVLRQ! YDULDEOHBLQLWLDOL]HU! YDULDEOHBGHFODUDWRU! ORFDOBYDULDEOHBGHFODUDWLRQ! IRUBLQLW! H[SUHVVLRQ! QDPH!L QDPH! OW QDPH!OLVWOHQJWK QDPH! H[SUHVVLRQ! IRUBXSGDWH! VWDWHPHQWBH[SUHVVLRQBOLVW! VWDWHPHQWBH[SUHVVLRQ! QDPH!L QDPH! VWDWHPHQWBH[SUHVVLRQ! VWDWHPHQWBH[SUHVVLRQBOLVW! IRUBXSGDWH! VWDWHPHQW,' ! EORFN! EORFNBRSHQ!^ EORFNBRSHQ! EORFNBVWDWHPHQW! VWDWHPHQW,' ! VWDWHPHQWBH[SUHVVLRQ! QDPH!ZDON QDPH! DUJXPHQWV! DUJXPHQWBOLVW! H[SUHVVLRQ! QDPH!SDWK QDPH! QDPH!OLVW QDPH! > H[SUHVVLRQ!
Y
QDPH!L QDPH! H[SUHVVLRQ! @ H[SUHVVLRQ! DUJXPHQWBOLVW! DUJXPHQWV! VWDWHPHQWBH[SUHVVLRQ! VWDWHPHQW! EORFNBVWDWHPHQW! EORFNBFORVH!` EORFNBFORVH! EORFN! VWDWHPHQW! IRUBVWDWHPHQW! VWDWHPHQW! EORFNBVWDWHPHQW! EORFNBFORVH!` EORFNBFORVH! EORFN! VWDWHPHQW! LIBVWDWHPHQW! VWDWHPHQW! LIBVWDWHPHQW! VWDWHPHQW! EORFNBVWDWHPHQW! EORFNBFORVH!` EORFNBFORVH! EORFN! PHWKRGBGHFODUDWLRQ! PHWKRGBGHFODUDWLRQ,' ! FRPPHQW! FRPPHQWBOLQH!
FRPPHQWBOLQH! FRPPHQWBOLQH! $PDLQSURJUDPXVHG IRUWHVWLQJ SXUSRVHVRQO\ FRPPHQWBOLQH! FRPPHQWBOLQH! FRPPHQWBOLQH! FRPPHQW! PRGLILHU!SXEOLFVWDWLF PRGLILHU! UHVXOWBW\SH!YRLG UHVXOWBW\SH! PHWKRGBGHFODUDWRU! PHWKRGBQDPH!PDLQ PHWKRGBQDPH! IRUPDOBSDUDPHWHUV! IRUPDOBSDUDPHWHU! PRGLILHU! W\SH! QDPH!6WULQJ QDPH! >@ W\SH! YDULDEOHBGHFODUDWRUBLG! YDULDEOHBQDPH!DUJV YDULDEOHBQDPH! YDULDEOHBGHFODUDWRUBLG! IRUPDOBSDUDPHWHU! IRUPDOBSDUDPHWHUV! PHWKRGBGHFODUDWRU! WKURZV QDPHBOLVW! QDPH!,2([FHSWLRQ QDPH! QDPHBOLVW! EORFN! EORFNBRSHQ!^ EORFNBRSHQ! EORFNBVWDWHPHQW! ORFDOBYDULDEOHBGHFODUDWLRQ! PRGLILHU! W\SH! SULPLWLYHBW\SH!LQW SULPLWLYHBW\SH! W\SH! YDULDEOHBGHFODUDWRU! YDULDEOHBGHFODUDWRUBLG! YDULDEOHBQDPH!L YDULDEOHBQDPH! YDULDEOHBGHFODUDWRUBLG! YDULDEOHBGHFODUDWRU! ORFDOBYDULDEOHBGHFODUDWLRQ! EORFNBVWDWHPHQW! EORFNBVWDWHPHQW! ORFDOBYDULDEOHBGHFODUDWLRQ! PRGLILHU! W\SH! QDPH!'LU:DONHU QDPH! W\SH! YDULDEOHBGHFODUDWRU! YDULDEOHBGHFODUDWRUBLG! YDULDEOHBQDPH!Z YDULDEOHBQDPH!
YL
YDULDEOHBGHFODUDWRUBLG!
YDULDEOHBLQLWLDOL]HU! H[SUHVVLRQ! DOORFDWLRQBH[SUHVVLRQ!QHZ QDPH!'LU:DONHU QDPH! DUJXPHQWV! DUJXPHQWBOLVW! H[SUHVVLRQ! OLWHUDO! OLWHUDO! H[SUHVVLRQ! DUJXPHQWBOLVW! DUJXPHQWV! DOORFDWLRQBH[SUHVVLRQ! H[SUHVVLRQ! YDULDEOHBLQLWLDOL]HU! YDULDEOHBGHFODUDWRU! ORFDOBYDULDEOHBGHFODUDWLRQ! EORFNBVWDWHPHQW! EORFNBVWDWHPHQW! ORFDOBYDULDEOHBGHFODUDWLRQ! PRGLILHU! W\SH! QDPH!9HFWRU QDPH! W\SH! YDULDEOHBGHFODUDWRU! YDULDEOHBGHFODUDWRUBLG! YDULDEOHBQDPH!I YDULDEOHBQDPH! YDULDEOHBGHFODUDWRUBLG! YDULDEOHBLQLWLDOL]HU! H[SUHVVLRQ! QDPH!ZZDON QDPH! DUJXPHQWV! DUJXPHQWV! H[SUHVVLRQ! YDULDEOHBLQLWLDOL]HU! YDULDEOHBGHFODUDWRU! ORFDOBYDULDEOHBGHFODUDWLRQ!
EORFNBVWDWHPHQW! EORFNBVWDWHPHQW! VWDWHPHQW,' ! IRUBVWDWHPHQW! IRU!IRU IRU! IRUBLQLW! VWDWHPHQWBH[SUHVVLRQBOLVW! VWDWHPHQWBH[SUHVVLRQ! QDPH!L QDPH! DVVLJQPHQWBRSHUDWRU! DVVLJQPHQWBRSHUDWRU! H[SUHVVLRQ! OLWHUDO! OLWHUDO! H[SUHVVLRQ! VWDWHPHQWBH[SUHVVLRQ! VWDWHPHQWBH[SUHVVLRQBOLVW! IRUBLQLW! H[SUHVVLRQ! QDPH!L QDPH! OW QDPH!IVL]H QDPH! DUJXPHQWV! DUJXPHQWV! H[SUHVVLRQ! IRUBXSGDWH! VWDWHPHQWBH[SUHVVLRQBOLVW! VWDWHPHQWBH[SUHVVLRQ! QDPH!L QDPH! VWDWHPHQWBH[SUHVVLRQ! VWDWHPHQWBH[SUHVVLRQBOLVW! IRUBXSGDWH! VWDWHPHQW,' ! EORFN! EORFNBRSHQ!^ EORFNBRSHQ! EORFNBVWDWHPHQW!
YLL
ORFDOBYDULDEOHBGHFODUDWLRQ! PRGLILHU! W\SH! QDPH!6WULQJ QDPH! W\SH! YDULDEOHBGHFODUDWRU! YDULDEOHBGHFODUDWRUBLG! YDULDEOHBQDPH!ILOH YDULDEOHBQDPH! YDULDEOHBGHFODUDWRUBLG!
YDULDEOHBLQLWLDOL]HU! H[SUHVVLRQ! W\SH! QDPH!6WULQJ QDPH! W\SH! QDPH!IHOHPHQW$W QDPH! DUJXPHQWV! DUJXPHQWBOLVW! H[SUHVVLRQ! QDPH!L QDPH! H[SUHVVLRQ! DUJXPHQWBOLVW! DUJXPHQWV! H[SUHVVLRQ! YDULDEOHBLQLWLDOL]HU! YDULDEOHBGHFODUDWRU! ORFDOBYDULDEOHBGHFODUDWLRQ! EORFNBVWDWHPHQW! EORFNBVWDWHPHQW! VWDWHPHQW,' ! VWDWHPHQWBH[SUHVVLRQ! QDPH!6\VWHPRXWSULQWOQ QDPH! DUJXPHQWV! DUJXPHQWBOLVW! H[SUHVVLRQ! QDPH!ILOH QDPH! H[SUHVVLRQ! DUJXPHQWBOLVW! DUJXPHQWV! VWDWHPHQWBH[SUHVVLRQ! VWDWHPHQW! EORFNBVWDWHPHQW! EORFNBFORVH!` EORFNBFORVH! EORFN! VWDWHPHQW! IRUBVWDWHPHQW! VWDWHPHQW! EORFNBVWDWHPHQW! EORFNBVWDWHPHQW! VWDWHPHQW,' ! VWDWHPHQWBH[SUHVVLRQ! QDPH!6\VWHPRXWSULQWOQ QDPH! DUJXPHQWV! DUJXPHQWBOLVW! H[SUHVVLRQ! OLWHUDO!?Q OLWHUDO! QDPH!L QDPH! OLWHUDO!ILOHVLQFXUUHQWGLUHFWRU\DQG VXEGLUHFWRULHV OLWHUDO! H[SUHVVLRQ! DUJXPHQWBOLVW! DUJXPHQWV! VWDWHPHQWBH[SUHVVLRQ! VWDWHPHQW! EORFNBVWDWHPHQW! EORFNBFORVH!` EORFNBFORVH! EORFN! PHWKRGBGHFODUDWLRQ! FODVVBERG\! ` XQPRGLILHGBFODVVBGHFODUDWLRQ! FODVVBGHFODUDWLRQ! W\SHBGHFODUDWLRQ! MDYDBVRXUFHBFRGH!
YLLL
VWDWLVWLFV! QUBRIBFRGHOLQHVQU ! QUBRIBFODVVHVQU ! QUBRIBPHWKRGVQU ! QUBRIBVWDWHPHQWVQU ! VWDWLVWLFV! MDYD[POBURRW!
L[
$9RRUEHHOG-DYD;0/6W\OHVKHHW
'H]H DSSHQGL[ LOOXVWUHHUW HHQ YRRUEHHOG VW\OHVKHHW YRRU WRHSDVVLQJ RS GH -DYD ;0/ EHVWDQGHQ ]RDOV JHJHQHUHHUG GRRU GH -DYD;0/ FOLHQW 'H]H VW\OHVKHHW ZRUGW DDQJHZHQG LQ GH UHSRVLWRU\ HQSDVWKLJKOLJKWLQJWRHHYHQDOVHHQFRQYHUVLHYDQVLPSHOH[OLQNVQDDU+70/K\SHUOLQNV "[POYHUVLRQ "!
([DPSOHVW\OHVKHHWIRU-DYD;0/JHQHUDWHGILOHV ZLWKV\QWD[KLJKOLJKWLQJ ! &RS\ULJKW5DPL+DQVHQQH
!
[VO VW\OHVKHHW[POQV [VO KWWS ZZZZRUJ ;6/7UDQVIRUP YHUVLRQ [POQV [OLQN KWWS ZZZZRUJ [OLQNQDPHVSDFH! [VO WHPSODWHPDWFK MDYD[POBURRW! ERG\EJFRORU IIIIIIOLQN ))$YOLQN ! WDEOHFHOOSDGGLQJ ! WU! [VO DSSO\WHPSODWHVVHOHFW OLQHV! [VO DSSO\WHPSODWHVVHOHFW MDYDBVRXUFHBFRGH! WU! WDEOH! ERG\! [VO WHPSODWH! [VO WHPSODWHPDWFK OLQHV! WGYDOLJQ WRS! [VO DSSO\WHPSODWHV! WG! [VO WHPSODWH!
[VO WHPSODWHPDWFK OLQH! [VO YDOXHRIVHOHFW #QU! [VO WHPSODWH!
[VO WHPSODWHPDWFK MDYDBVRXUFHBFRGH! WGYDOLJQ WRS! [VO DSSO\WHPSODWHV! WG! [VO WHPSODWH! [VO WHPSODWHPDWFK SDFNDJH! %! [VO DSSO\WHPSODWHV! %! [VO WHPSODWH!
[VO WHPSODWHPDWFK PRGLILHU! IRQWFRORU II! [VO DSSO\WHPSODWHV! IRQW! [VO WHPSODWH!
[VO WHPSODWHPDWFK PHWKRGBQDPH! L! IRQWFRORU IID! [VO DSSO\WHPSODWHV! IRQW! L! [VO WHPSODWH! [VO WHPSODWHPDWFK VWDWHPHQW! [VO DSSO\WHPSODWHV! [VO WHPSODWH! [VO WHPSODWHPDWFK EORFN! EORFNTXRWH! [VO DSSO\WHPSODWHV! EORFNTXRWH! [VO WHPSODWH!
L
[VO WHPSODWHPDWFK LIBVWDWHPHQW! [VO DSSO\WHPSODWHV! [VO WHPSODWH! [VO WHPSODWHPDWFK OLWHUDO! IRQWFRORU II! [VO DSSO\WHPSODWHV! IRQW! [VO WHPSODWH!
[VO WHPSODWHPDWFK DUJXPHQWV! IRQWFRORU ! [VO DSSO\WHPSODWHV! IRQW! [VO WHPSODWH!
[VO WHPSODWHPDWFK LPSRUWBGHFODUDWLRQ! IRQWFRORU II! %! [VO DSSO\WHPSODWHV! %! EU! IRQW! [VO WHPSODWH! [VO WHPSODWHPDWFK FODVVBGHFODUDWLRQ! EU! [VO DSSO\WHPSODWHV! [VO WHPSODWH!
[VO WHPSODWHPDWFK WU\! %! [VO DSSO\WHPSODWHV! %! [VO WHPSODWH!
[VO WHPSODWHPDWFK FDWFK! [VO DSSO\WHPSODWHV! [VO WHPSODWH!
[VO WHPSODWHPDWFK ILQDOO\! [VO DSSO\WHPSODWHV! [VO WHPSODWH!
[VO WHPSODWHPDWFK FODVVBERG\! EORFNTXRWH! [VO DSSO\WHPSODWHV! EORFNTXRWH! [VO WHPSODWH! [VO WHPSODWHPDWFK FODVVBQDPH! %! IRQWFRORU II! [VO DSSO\WHPSODWHV! IRQW! %! [VO WHPSODWH!
[VO WHPSODWHPDWFK EORFNBVWDWHPHQW! EU! [VO DSSO\WHPSODWHV! [VO WHPSODWH!
[VO WHPSODWHPDWFK PHWKRGBGHFODUDWLRQ! EU! [VO DSSO\WHPSODWHV! [VO WHPSODWH!
[VO WHPSODWHPDWFK YDULDEOHBQDPH! E! [VO DSSO\WHPSODWHV! E! [VO WHPSODWH!
LL
[VO WHPSODWHPDWFK FRPPHQW! IRQWFRORU DDDDDD! [VO DSSO\WHPSODWHV! IRQW! EU! [VO WHPSODWH!
[VO WHPSODWHPDWFK SDFNDJHBQDPH! %! [VO DSSO\WHPSODWHV! %! [VO WHPSODWH! [VO WHPSODWHPDWFK QDPH! [VO DSSO\WHPSODWHV! [VO WHPSODWH!
[VO WHPSODWHPDWFK SDFNDJHBGHFODUDWLRQ! %! IRQWFRORU II! EU! [VO DSSO\WHPSODWHV! EU! EU! IRQW! %! [VO WHPSODWH! [VO WHPSODWHPDWFK LI! E! [VO DSSO\WHPSODWHV! E! [VO WHPSODWH! [VO WHPSODWHPDWFK IRU! E! [VO DSSO\WHPSODWHV! E! [VO WHPSODWH!
[VO WHPSODWHPDWFK GR! E! [VO DSSO\WHPSODWHV! E! [VO WHPSODWH!
[VO WHPSODWHPDWFK ZKLOH! E! [VO DSSO\WHPSODWHV! E! [VO WHPSODWH!
[VO WHPSODWHPDWFK EORFNBFORVH! EU! [VO DSSO\WHPSODWHV! [VO WHPSODWH!
[VO WHPSODWHPDWFK FRPPHQWBOLQH! [VO DSSO\WHPSODWHV! EU! [VO WHPSODWH!
[VO WHPSODWHPDWFK LPSRUWBSDFNDJH! [VO DSSO\WHPSODWHV! [VO WHPSODWH! [VO WHPSODWHPDWFK QDPHBOLVW! [VO DSSO\WHPSODWHV! [VO WHPSODWH!
[VO WHPSODWHPDWFK XQPRGLILHGBFODVVBGHFODUDWLRQ! [VO DSSO\WHPSODWHV! [VO WHPSODWH! [VO VW\OHVKHHW!
LLL
$+HW-DYD;0/FRQILJXUDWLHEHVWDQG
+HW MDYD[POFIJ EHVWDQG GLHQW WH ZRUGHQ JHSODDWVW LQ GH µ 7RPFDWBKRPH!FRQI¶ GLUHFWRU\ 9HUYROJHQV GLHQW HON YRRUNRPHQ YDQ µORFDOKRVW¶ WH ZRUGHQ YHUYDQJHQ GRRU GH VHUYHUQDDP HQ ZRUGHQ DOOH GLUHFWRULHV UHODWLHI WRY GH µ 7RPFDWBKRPH!ELQ¶ GLUHFWRU\ ZRUGHQ EHVW YHUYDQJHQ GRRU DEVROXWHSDGHQ+LHURQGHUYROJWHHQYRRUEHHOGYDQKHWFRQILJXUDWLHEHVWDQGPHW ZDWH[WUDLQIRUPDWLH EDVH3DWK%LQ DSSVWRPFDWZHEDSSVMDYD[POXSORDGBURRW
'LW SDG YHUZLMVW VWDQGDDUG QDDU GH GRFXPHQW URRW YDQ GH UHSRVLWRU\ UHODWLHIWRY GHµWRPFDWBKRPHELQ¶GLUHFWRU\ HQZRUGWEHVWDEVROXXWJHPDDNW EDVH3DWK XSORDGBURRW
'LW SDG YHUZLMVW VWDQGDDUG QDDU GH GRFXPHQW URRW YDQ GH UHSRVLWRU\ UHODWLHIWRY GHµ:(%,1)FODVVHV¶GLUHFWRU\ HQPDJUHODWLHIEOLMYHQ VWDWV3DWK%LQ DSSVWRPFDWZHEDSSVMDYD[POVWDWV
'LW SDG YHUZLMVW VWDQGDDUG QDDU GH ORFDWLH YDQ GH VWDWLVWLHNHQ UHODWLHI WRY GH µWRPFDWBKRPHELQ¶GLUHFWRU\ HQZRUGWEHVWDEVROXXWJHPDDNW VWDWV3DWK VWDWV
'LWSDGYHUZLMVWVWDQGDDUGQDDUORFDWLHYDQGHVWDWLVWLHNHQ UHODWLHIWRYGHµ:(% ,1)FODVVHV¶GLUHFWRU\ HQPDJUHODWLHIEOLMYHQ VHUYOHW KWWS ZZZM[POFRP MDYD[POVHUYOHWUHTXHVW5HTXH VW
'H]H 85/ JHHIW GH ORFDWLH YDQ GH UHTXHVW VHUYOHW DDQ +LHU GLHQHQ VHUYHUQDDP HQ SRRUWWHZRUGHQLQJHYXOG GRFVW\OHVKHHW KWWS ZZZM[POFRP MDYD[POXSORDGBURRW'RF VW\OH[VO
'H]H 85/ JHHIW GH ORFDWLH YDQ GH -DYDGRF ;0/ VW\OHVKHHW DDQ +LHU GLHQHQ VHUYHUQDDPHQSRRUWWHZRUGHQLQJHYXOG VUFVW\OHVKHHW KWWS ZZZM[POFRP MDYD[POXSORDGBURRW/LQ N6KHHW[VO
'H]H 85/ JHHIW GH ORFDWLH YDQ GH -DYD VRXUFH ;0/ VW\OHVKHHW DDQ +LHU GLHQHQ VHUYHUQDDPHQSRRUW WHZRUGHQLQJHYXOG VWDWVVW\OHVKHHW KWWS ZZZM[POFRP MDYD[POVWDWVVWDWV[ VO
'H]H 85/ JHHIW GH ORFDWLH YDQ GH VW\OHVKHHW YRRU GH VWDWLVWLHNHQ DDQ +LHU GLHQHQ VHUYHUQDDPHQSRRUWWHZRUGHQLQJHYXOG GDWDEDVH MDYD[PO
'LWLVGHQDDPYDQGHMDYD[POGDWDEDQN'H]HPDJRQJHZLM]LJGEOLMYHQWHQ]LMHHQ QLHXZHGDWDEDQNZHUGDDQJHPDDNWRQGHUHHQDQGHUHQDDP
L
GE3DWK DSSVWRPFDWZHEDSSVMDYD[PO:(%,1)FODVVHV
'LW SDG YHUZLMVW VWDQGDDUG QDDU GH GDWDEDQN GLUHFWRU\ UHODWLHI WRY GH µWRPFDWBKRPHELQ¶GLUHFWRU\ HQZRUGWEHVWDEVROXXWJHPDDNW VHDUFKILOHV DSSVWRPFDWZHEDSSVMDYD[POVHDUFK
'LW SDG YHUZLMVW VWDQGDDUG QDDU GH VHDUFK HQJLQH UHODWLHI WRY GH µWRPFDWBKRPHELQ¶GLUHFWRU\ HQZRUGWEHVWDEVROXXWJHPDDNW FODVVHVGLU DSSVWRPFDWZHEDSSVMDYD[PO:(%,1)FODVVHV
'LWSDGYHUZLMVWVWDQGDDUGQDDUGHFODVVHVGLU UHODWLHIWRYGHµWRPFDWBKRPHELQ¶ GLUHFWRU\ HQZRUGWEHVWDEVROXXWJHPDDNW
FDFKH RQ *HHIW DDQ RI FDFKLQJ DDQ GDQ ZHO DI ZRUGW JH]HW 9RRU YROOHGLJ G\QDPLVFKH OLQNJHQHUDWLHGLHQWFDFKLQJWHZRUGHQDIJH]HW EFRORU ))))&&
+LHU ZRUGW GH DFKWHUJURQGNOHXU YDQ GH G\QDPLVFK JHJHQHUHHUGH +70/;0/ DDQJHJHYHQ %LM KHW YHUDQGHUHQ YDQ GH]H NOHXU ZRUGHQ EHVW RRN GH VWDWLVFKH +70/ SDJLQD¶VYDQKHWPHQXDDQJHSDVW
LL
$ 9RRUEHHOG(-%¶V
2QGHUVWDDQGH -DYD NODVVHQ YRUPHQ HHQ YRRUEHHOG (QWLW\ HQ 6HVVLRQ EHDQ YRRU KHW RSVODDQ YDQ PHWKRGHLQIRUPDWLH XLW HHQ -DYD;0/ EHVWDQG LQ HHQ -'%& GDWDEDQN'H]H FRQWDLQHU PDQDJHG (-%¶V ZHUGHQ HQNHO QRJ H[SHULPHQWHHO JHEUXLNW LQ FRPELQDWLH PHW GH -DYD ;0/ UHSRVLWRU\ 9RRUORSLJ ZRUGW HU QRJ JHEUXLN JHPDDNW YDQ LQJHEHGGH 64/VWDWHPHQWV YRRU WRHJDQJ WRW GH GDWDEDQN +RPH,QWHUIDFH
0HWKRG+RPHMDYD
([DPSOH(QWLW\%HDQ± +RPHLQWHUIDFH
5DPL+DQVHQQH
LPSRUWMDYDXWLO LPSRUWMDYDUPL LPSRUWMDYD[HME
SXEOLFLQWHUIDFH0HWKRG+RPH H[WHQGV(-%+RPH ^
SXEOLFVWDWLFILQDO6WULQJ&203B1$0( MDYD FRPSHQYHME0HWKRG
SXEOLFVWDWLFILQDO6WULQJ-1',B1$0( 0HWKRG SXEOLF0HWKRGFUHDWH 6WULQJSDFNDJH1DPH 6WULQJFODVV1DPH 6WULQJPHWKRG1DPH 6WULQJDUJXPHQWV WKURZV5HPRWH([FHSWLRQ&UHDWH([FHSWLRQ SXEOLF0HWKRGILQG%\3ULPDU\.H\ 0HWKRG3.SN WKURZV5HPRWH([FHSWLRQ)LQGHU([FHSWLRQ `
SXEOLF&ROOHFWLRQILQG$OO WKURZV5HPRWH([FHSWLRQ
5HPRWH,QWHUIDFH
0HWKRGMDYD
([DPSOH(QWLW\%HDQ± 5HPRWHLQWHUIDFH
5DPL+DQVHQQH
LPSRUWMDYDUPL LPSRUWMDYDXWLO LPSRUWMDYD[HME
SXEOLFLQWHUIDFH0HWKRG H[WHQGV(-%2EMHFW ^
SXEOLF6WULQJJHW3DFNDJH1DPH WKURZV5HPRWH([FHSWLRQ
SXEOLFYRLGVHW3DFNDJH1DPH 6WULQJSDFNDJH1DPH WKURZV5HPRWH([FHSWLRQ SXEOLF6WULQJJHW&ODVV1DPH WKURZV5HPRWH([FHSWLRQ
SXEOLF YRLGVHW&ODVV1DPH 6WULQJFODVV1DPH WKURZV5HPRWH([FHSWLRQ
L
SXEOLF6WULQJJHW0HWKRG1DPH WKURZV5HPRWH([FHSWLRQ
SXEOLFYRLGVHW0HWKRG1DPH 6WULQJPHWKRG1DPH WKURZV5HPRWH([FHSWLRQ SXEOLF6WULQJJHW$UJXPHQWV WKURZV5HPRWH([FHSWLRQ
`
SXEOLFYRLGVHW$UJXPHQWV 6WULQJDUJXPHQWV WKURZV5HPRWH([FHSWLRQ
(QWLW\%HDQ
0HWKRG%HDQMDYD
([DPSOH(QWLW\%HDQ± %HDQFODVV
5DPL+DQVHQQH
LPSRUWMDYD[QDPLQJ,QLWLDO&RQWH[W LPSRUWMDYDXWLO SXEOLFFODVV0HWKRG%HDQ H[WHQGV(QWLW\6XSSRUW ^ SXEOLF6WULQJSDFNDJH1DPH SXEOLF6WULQJFODVV1DPH SXEOLF6WULQJPHWKRG1DPH SXEOLF6WULQJDUJXPHQWV
SXEOLF6WULQJJHW3DFNDJH1DPH ^ UHWXUQSDFNDJH1DPH `
SXEOLFYRLGVHW3DFNDJH1DPH 6WULQJSDFNDJH1DPH ^ WKLVSDFNDJH1DPH SDFNDJH1DPH ` SXEOLF6WULQJJHW&ODVV1DPH ^ UHWXUQFODVV1DPH `
SXEOLFYRLGVHW&ODVV1DPH 6WULQJFODVV1DPH ^ WKLVFODVV1DPH FODVV1DPH ` SXEOLF6WULQJJHW0HWKRG1DPH ^ UHWXUQPHWKRG1DPH `
SXEOLFYRLGVHW0HWKRG1DPH 6WULQJPHWKRG1DPH ^ WKLVPHWKRG1DPH PHWKRG1DPH ` SXEOLF6WULQJJHW$UJXPHQWV ^ UHWXUQDUJXPHQWV `
SXEOLFYRLGVHW$UJXPHQWV 6WULQJDUJXPHQWV ^ WKLVDUJXPHQWV DUJXPHQWV ` SXEOLF6WULQJHME&UHDWH
6WULQJSDFNDJH1DPH
LL
^
`
`
6WULQJFODVV1DPH 6WULQJPHWKRG1DPH 6WULQJDUJXPHQWV
VHW3DFNDJH1DPH SDFNDJH1DPH VHW&ODVV1DPH FODVV1DPH VHW0HWKRG1DPH PHWKRG1DPH VHW$UJXPHQWV DUJXPHQWV UHWXUQSDFNDJH1DPH
SXEOLFYRLGHME3RVW&UHDWH 6WULQJSDFNDJH1DPH 6WULQJFODVV1DPH 6WULQJPHWKRG1DPH 6WULQJDUJXPHQWV ^ `
3ULPDU\NH\FODVV
0HWKRG3.MDYD
([DPSOH(QWLW\%HDQ± 3ULPDU\.H\FODVV
5DPL+DQVHQQH
SXEOLFFODVV0HWKRG3. LPSOHPHQWVMDYDLR6HULDOL]DEOH ^ SXEOLF6WULQJSDFNDJH1DPH SXEOLF6WULQJFODVV1DPH SXEOLF6WULQJPHWKRG1DPH SXEOLF6WULQJ DUJXPHQWV
SXEOLFERROHDQHTXDOV 2EMHFWSN ^ UHWXUQ 0HWKRG3. SN SDFNDJH1DPHHTXDOV SDFNDJH1DPH 0HWKRG3. SN FODVV1DPHHTXDOV FODVV1DPH 0HWKRG3. SN PHWKRG1DPHHTXDOV PHWKRG1DPH 0HWKRG3. SN DUJXPHQWVHTXDOV DUJXPHQWV ` SXEOLFLQWKDVK&RGH ^ UHWXUQ QHZ6WULQJ SDFNDJH1DPH FODVV1DPH PHWKRG1DPH DUJXPHQWV KDVK&RGH `
`
SXEOLF6WULQJWR6WULQJ ^ LI SDFNDJH1DPHHTXDOV UHWXUQ SDFNDJH1DPH FODVV1DPH PHWKRG1DPH DUJXPHQWV HOVH UHWXUQ SDFNDJH1DPH FODVV1DPH PHWKRG1DPH DUJXPHQWV `
LLL
0HWKRGEHDQPDQLIHVW
"[POYHUVLRQ HQFRGLQJ &S"! HMEMDU! GHVFULSWLRQ!6WRUH0HWKRG(QWLW\%HDQ GHVFULSWLRQ! GLVSOD\QDPH!7HVW GLVSOD\QDPH! HQWHUSULVHEHDQV! HQWLW\! GLVSOD\QDPH!0HWKRG(-% GLVSOD\QDPH! HMEQDPH!0HWKRG HMEQDPH! KRPH!0HWKRG+RPH KRPH! UHPRWH!0HWKRG UHPRWH! HMEFODVV!0HWKRG%HDQ HMEFODVV! SHUVLVWHQFHW\SH!&RQWDLQHU SHUVLVWHQFHW\SH! SULPNH\FODVV!0HWKRG3. SULPNH\FODVV! UHHQWUDQW!7UXH UHHQWUDQW! FPSILHOG! GHVFULSWLRQ!0HWKRG3DFNDJHQDPH GHVFULSWLRQ! ILHOGQDPH!SDFNDJH1DPH ILHOGQDPH! FPSILHOG! FPSILHOG! GHVFULSWLRQ!0HWKRG&ODVVQDPH GHVFULSWLRQ! ILHOGQDPH!FODVV1DPH ILHOGQDPH! FPSILHOG! FPSILHOG! GHVFULSWLRQ!0HWKRG0HWKRGQDPH GHVFULSWLRQ! ILHOGQDPH!PHWKRG1DPH ILHOGQDPH! FPSILHOG! FPSILHOG! GHVFULSWLRQ!0HWKRG$UJXPHQWV GHVFULSWLRQ! ILHOGQDPH!DUJXPHQWV ILHOGQDPH! FPSILHOG! HQWLW\! HQWHUSULVHEHDQV! HMEMDU! 0HWKRG6HVVLRQ%HDQFODVVHV +RPHLQWHUIDFH
6WRUH0HWKRG+RPHMDYD
([DPSOH6HVVLRQ%HDQ± +RPHLQWHUIDFH
5DPL+DQVHQQH
LPSRUWMDYDLR6HULDOL]DEOH LPSRUWMDYDUPL5HPRWH([FHSWLRQ LPSRUWMDYD[HME&UHDWH([FHSWLRQ LPSRUWMDYD[HME(-%+RPH
SXEOLFLQWHUIDFH6WRUH0HWKRG+RPHH[WHQGV(-%+RPH^
`
SXEOLF6WRUH0HWKRGFUHDWH WKURZV5HPRWH([FHSWLRQ&UHDWH([FHSWLRQ
5HPRWHLQWHUIDFH
6WRUH0HWKRGMDYD
([DPSOH6HVVLRQ%HDQ± 5HPRWHLQWHUIDFH
5DPL+DQVHQQH
LPSRUWMDYD[HME(-%2EMHFW LPSRUWMDYDUPL5HPRWH([FHSWLRQ
SXEOLFLQWHUIDFH6WRUH0HWKRGH[WHQGV(-%2EMHFW^
LY
`
SXEOLFYRLGVWRUH 6WULQJSDFNDJH1DPH 6WULQJFODVV1DPH 6WULQJPHWKRG1DPH 6WULQJDUJXPHQWV WKURZV5HPRWH([FHSWLRQ
6HVVLRQEHDQ
6WRUH0HWKRG%HDQMDYD
([DPSOH6HVVLRQ%HDQ± %HDQFODVV
6WRUHVPHWKRGLQIRLQD-'%&GDWDEDVH
5DPL+DQVHQQH
LPSRUWMDYDUPL5HPRWH([FHSWLRQ LPSRUWMDYD[HME6HVVLRQ%HDQ LPSRUWMDYD[HME6HVVLRQ&RQWH[W
SXEOLFFODVV6WRUH0HWKRG%HDQLPSOHPHQWV6HVVLRQ%HDQ^ SXEOLF6WRUH0HWKRG%HDQ ^` SXEOLFYRLGHME&UHDWH ^` SXEOLFYRLGHME5HPRYH ^`
SXEOLF YRLGHME$FWLYDWH ^`
SXEOLFYRLGHME3DVVLYDWH ^`
SXEOLFYRLGVHW6HVVLRQ&RQWH[W 6HVVLRQ&RQWH[WVF ^` SXEOLFYRLGVWRUH
`
`
6WULQJSDFNDJH1DPH 6WULQJFODVV1DPH 6WULQJPHWKRG1DPH 6WULQJDUJXPHQWV ^
6WRUH0HWKRGEHDQPDQLIHVW "[POYHUVLRQ HQFRGLQJ &S"!
HMEMDU! GHVFULSWLRQ!6WRUH0HWKRG6HVVLRQ%HDQ GHVFULSWLRQ! GLVSOD\QDPH!6WRUH0HWKRG GLVSOD\QDPH! HQWHUSULVHEHDQV! VHVVLRQ! HMEQDPH!6WRUH0HWKRG HMEQDPH! KRPH!6WRUH0HWKRG+RPH KRPH! UHPRWH!6WRUH0HWKRG UHPRWH! HMEFODVV!6WRUH0HWKRG%HDQ HMEFODVV! VHVVLRQW\SH!6WDWHOHVV VHVVLRQW\SH! WUDQVDFWLRQW\SH!%HDQ WUDQVDFWLRQW\SH! VHVVLRQ! HQWHUSULVHEHDQV! HMEMDU!
Y
