Java and XSLT
Werbung
Java and XSLT Schlagwortsuche Suche Bücher A-Z Suchen Eine Einführung in XML Neuerscheinungen Buchreihen von Brett McLaughlin Programmbereiche C/C++ Programmierung Design & Grafik Inhalt: Java Linux Macintosh .Net Open Source Was ist das eigentlich? Wie benutze ich das? Warum sollte ich XML verwenden? Dieser Text ist das einleitende Kapitel aus Java und XML, in aktualisierter und leicht gekürzter Form. Wir stellen den Text hier zur Verfügung, da er sehr praxisnah in XML einführt und in dieser Form in der zweiten Auflage von Java and XML, deren Übersetzung in Arbeit ist, nicht mehr enthalten sein wird (Brett McLaughlin verzichtet in der neuen Auflage zugunsten fortgeschrittenerer Themen auf eine ausführlichere Einführung in XML). Oracle Perl Python Sicherheit System- & Netzwerkadministration Unix Visual Basic Web & Internet Windows XML Weitere Infos Katalog bestellen Mailinglisten abonnieren Archiv XML. Diese drei Buchstaben haben so ziemlich jeden Entwickler auf der ganzen Welt irgendwann in den letzten zwei Jahren erschauern lassen. Auch wenn diese Schauer oft aus Angst, sich noch ein Kürzel merken zu müssen, gespannter Erwartung auf eine neue Technologie oder aus Verärgerung darüber, daß noch eine weitere Quelle der Verwirrung für heutige Entwickler hinzukommt, entstanden sind, waren es doch allesamt Schauer. Erstaunlicherweise war jede dieser Reaktionen auf XML gerechtfertigt. XML ist ein weiteres Kürzel, das man sich merken muß, und besitzt auch noch eine schwindlig machende Reihe von Kollegen: XSL, XSLT, PI, DTD, XHTML und weitere. Es enthält auch ein gewaltiges Versprechen: Was Java für die Portabilität von Code geleistet hat, das verspricht XML für die Portabilität von Daten. Sun hat in den letzten Monaten sogar den ziemlich ehrgeizigen Slogan "Java + XML = portabler Code + portable Daten" geprägt. Und ja, XML führt zu einer nicht zu vernachlässigenden Verwirrung. Wir werden uns hier aufmachen, XML zu entmystifizieren - ohne so abstrakt und allgemein zu bleiben, daß der Nutzen verlorengeht, und ohne so tief einzusteigen, daß dieser Text nur eine weitere langweilige Spezifikation wird, die man durchackern muß. Diese Einführung ist für Sie, den Java-Entwickler, geschrieben, der die Aufregung verstehen und die Werkzeuge verwenden will, die XML so mitbringt. Heutige Web-Applikationen müssen sich mit Problemen herumschlagen, über die vor zehn Jahren noch niemand nachgedacht hat. Systeme, die über Tausende von Kilometern verteilt sind, müssen schnell und fehlerlos zusammenarbeiten. Daten aus heterogenen Systemen, Datenbanken, Verzeichnisdiensten und Anwendungen müssen untereinander übertragen werden, ohne daß dabei auch nur eine einzige Nachkommastelle verlorengeht. Applikationen müssen nicht nur mit anderen Geschäftskomponenten kommunizieren können, sondern auch mit anderen Firmen und anderen Technologien. Clients sind nicht mehr nur Thick Clients, sondern können auch Web-Browser, die HTML unterstützen, Mobiltelefone, die das Wireless Application Protocol (WAP) unterstützen, oder Taschen-Organizer mit ganz anderen Formatierungssprachen sein. Daten und deren Umformung und Konvertierung sind zum kritischen Herzstück jeder heutzutage entwikkelten Applikation geworden. XML ermöglicht es Programmierern, alle diese Anforderungen zu erfüllen. Außerdem steht speziell Java-Entwicklern ein ganzes Arsenal von APIs zur Verfügung, mit denen sie XML und http://www.oreilly.de/artikel/xml_einf.html (1 of 20) [6/10/2002 2:14:00 PM] Java and XSLT dessen Freundeskreis verwenden können, ohne jemals eine Integrierte JavaEntwicklungsumgebung (IDE) verlassen zu müssen. Wir werden XML immer als Werkzeug, nicht als Schlagwort oder als das neueste Spielzeug behandeln. Behalten wir das im Hinterkopf, und fangen wir an, darüber zu reden, was XML eigentlich ist. Was ist das eigentlich? XML ist die Extensible Markup Language. Wie ihr Vorgänger SGML ist auch XML eine MetaSprache, mit der andere Sprachen definiert werden. XML ist aber viel einfacher und weniger umständlich als SGML. XML ist eine Markup-Sprache, die weder die zur Verfügung stehenden Tags noch die Grammatik der Zielsprache spezifiziert. Die Tag-Menge einer Markup-Sprache definiert die Markup-Tags, die der Parser der Sprache versteht. Beispielsweise gibt es in HTML eine genau festgelegte Menge von Tags. Sie können den Tag <TABLE>, aber nicht den Tag <CHAIR> verwenden. Der erste Tag hat eine festgelegte Bedeutung für eine Applikation, die die Daten verwendet, und wird dazu benutzt, den Anfang einer Tabelle in HTML anzuzeigen. Der zweite Tag dagegen hat keine spezielle Bedeutung. Die meisten Browser werden ihn zwar einfach ignorieren, aber es können auch unerwartete Dinge passieren, wenn dieser Tag verwendet wird. Das liegt daran, daß die Tag-Menge von HTML ein Bestandteil der Sprachdefinition ist. In jeder neuen HTML-Version werden neue Tags definiert. Wenn ein Tag aber nicht definiert ist, dann kann er auch nicht als Bestandteil der Markup-Sprache benutzt werden, ohne daß beim Parsen des Dokuments ein Fehler gemeldet wird. Die Grammatik einer Markup-Sprache definiert die korrekte Verwendung der Tags der Sprache. Lassen Sie uns auch hier wieder HTML als Beispiel verwenden. Bei Verwendung des <TABLE>-Tags kann eine Reihe von Attributen angegeben werden, etwa die Breite, die Hintergrundfarbe und die Ausrichtung. Sie können aber nicht den Typ der Tabelle angegeben, weil die Grammatik von HTML das nicht zuläßt. Dadurch, daß XML weder die Tags noch die Grammatik definiert, ist die Sprache beliebig erweiterbar, daher auch ihr Name. Wenn Sie gern den Tag <TABLE> verwenden und darin mehrere <CHAIR>-Tags verschachteln möchten, dann können Sie das tun. Wenn Sie ein TYPEAttribut für den Tag <CHAIR> definieren möchten, dann können Sie das ebenfalls tun. Wenn Sie das möchten, dann können Sie Ihre Tags auch nach Ihren Kindern oder Ihren Kollegen benennen. Um das zu demonstrieren, werfen Sie am besten einmal einen Blick auf die in Beispiel 1 gezeigte XML-Datei. Beispiel 1: Ein Beispiel für eine XML-Datei <?xml version="1.0"?> <dining-room> <table type="round" wood="maple"> <manufacturer>Das Holzlädchen</manufacturer> <price>$1999.99</price> </table> <chair wood="maple"> <quantity>2</quantity> <quality>ausgezeichnet</quality> <cushion included="true"> <color>blau</color> </cushion> </chair> <chair wood="oak"> <quantity>3</quantity> <quality>durchschnittlich</quality> </chair> </dining-room> http://www.oreilly.de/artikel/xml_einf.html (2 of 20) [6/10/2002 2:14:00 PM] Java and XSLT Wenn Sie noch nie eine XML-Datei gesehen haben, sich aber mit HTML oder einer anderen Markup-Sprache auskennen, dann wird Ihnen das vielleicht ein wenig komisch vorkommen. Das liegt daran, daß die verwendeten Tags und die verwendete Grammatik frei erfunden sind. Keine Webseite und keine Spezifikation definiert die Tags <table>, <chair> und <cushion> (obwohl das möglich wäre, genauso wie die XHTML-Spezifikation HTML-Tags in XML definiert); sie sind vollständig aus der Luft gegriffen. Das ist die große Stärke von XML: Sie können damit den Inhalt Ihrer Daten beliebig definieren, solange Sie sich an die allgemeine Struktur halten, die von XML vorgeschrieben wird. Wir werden später noch detailliert auf einige andere Einschränkungen eingehen, aber im Moment reicht es, wenn Sie sich klarmachen, daß XML geschaffen wurde, um die größtmögliche Flexibilität beim Formatieren von Daten zu erhalten. Obwohl diese Flexibilität eine der größten Stärken von XML ist, ist sie auch eine der größten Schwächen: Weil XML-Dokumente auf so viele verschiedene Arten und Weisen und zu so vielen verschiedenen Zwecken verarbeitet werden können, gibt es eine große Anzahl von XMLbezogenen Standards, die die Übersetzung und die Spezifikation von Daten beschreiben. Diese zusätzlichen Kürzel und ihre stetige Gemeinschaft mit XML führen oft zu Verwirrung darüber, was XML eigentlich ist und was nicht. Oftmals meint jemand, der von "XML" spricht, nicht die Extensible Markup Language selbst, sondern alle oder einige XML-Werkzeuge. Auch wenn diese manchmal gesondert erwähnt werden, sollten Sie immer im Hinterkopf behalten, daß "XML" nicht einfach XML bedeutet; meistens ist damit "XML und all die tollen Möglichkeiten, es zu verarbeiten und zu benutzen" gemeint. Mit diesen Vorbemerkungen können wir jetzt einige der wichtigsten XML-Kürzel definieren und für jedes davon eine kurze Beschreibung liefern. Mit diesen Beschreibungen sollten Sie eine anfängliche Vorstellung davon erhalten, wie die einzelnen XML-Werkzeuge zusammenpassen und was XML ist und was nicht. Wir vermeiden hier die Diskussion von Publishing Engines, Applikationen und Werkzeugen für XML. Statt dessen behandeln wir in diesem Überblick nur die diversen Spezifikationen und Empfehlungen in ihren unterschiedlichen Stadien der Beschlußfassung. Die meisten davon sind Initiativen des W3C, des World Wide Web Consortium. Diese Gruppe definiert Standards für die XMLGemeinde, mit denen eine gemeinsame Wissensbasis für diese Technologie aufgebaut werden kann, ähnlich wie Sun Standards für Java und die zugehörigen APIs liefert. Nähere Informationen zum W3C finden Sie unter http://www.w3.org. XML XML ist natürlich die Mutter all dieser drei- und vierbuchstabigen Abkürzungen. Es definiert die Kernsprache selbst und liefert ein metadatenartiges Framework. XML für sich genommen hat nur einen sehr eingeschränkten Nutzen; es definiert nur dieses Framework. Aber all die diversen Technologien, die auf XML aufbauen, liefern Entwicklern und Autoren von Inhalten eine noch nicht dagewesene Flexibilität bei der Verwaltung und Übertragung von Daten. XML ist derzeit eine vollständige W3C-Empfehlung, wird sich also nicht mehr ändern, bis eine neue Version veröffentlicht wird. Die vollständige XML 1.0-Spezifikation finden Sie unter http://www.w3.org/XML/. Diese Spezifikation ist selbst für XML-Experten mühsam zu lesen; eine sehr gute Version dieser Spezifikation mit Randbemerkungen finden Sie jedoch unter http://www.xml.com. Für unsere Erläuterungen müssen Sie nur zwei grundlegende Konzepte im Zusammenhang mit XML-Dokumenten verstehen. Das erste besagt, daß jedes XML-Dokument wohlgeformt (wellformed) sein muß, um überhaupt irgendeinen Nutzen zu haben und korrekt geparst werden zu können. Ein wohlgeformtes Dokument ist ein Dokument, bei dem jeder geöffnete Tag auch wieder geschlossen wird, bei dem die Verschachtelungsreihenfolge nicht durchbrochen wird und das hinsichtlich der Spezifikation syntaktisch korrekt ist. Sie fragen sich jetzt vielleicht, ob wir nicht ein paar Absätze weiter oben gerade behauptet haben, daß XML keine Syntaxregeln habe. Das stimmt jedoch nicht ganz; wir haben dort gesagt, daß es keine grammatikalischen Regeln hat. Das Dokument kann zwar eigene Tags und Attribute definieren, muß aber trotzdem noch den allgemeinen Regeln und Prinzipien folgen. Diese Prinzipien werden dann von XML-fähigen http://www.oreilly.de/artikel/xml_einf.html (3 of 20) [6/10/2002 2:14:00 PM] Java and XSLT Applikationen und Parsern benutzt, um das Dokument zu verstehen und irgendwelche Aktionen auf den Daten auszuführen, wie z.B. den Preis für einen Stuhl zu suchen oder eine PDF-Datei aus den Daten im Dokument zu erzeugen. Das zweite grundlegende Konzept hinsichtlich XML-Dokumenten besagt, daß sie gültig (valid) sein können, es aber nicht sein müssen. Ein gültiges Dokument ist ein Dokument, das seiner Document Type Definition (DTD) gehorcht, auf die wir gleich eingehen werden. Vereinfacht gesagt definiert eine DTD die Grammatik und Tag-Menge für eine bestimmte XMLFormatierung. Wenn ein Dokument eine DTD spezifiziert und den darin festgelegten Regeln dann auch folgt, dann ist dieses Dokument ein gültiges XML-Dokument. XML-Dokumente können auch durch ein Schema in ihrer Freiheit eingeschränkt werden: eine neue Möglichkeit, XML-Formate vorzuschreiben, die DTDs ersetzen wird. Machen Sie sich keine Sorgen, wenn das alles noch etwas verwirrend ist; wir haben noch einen weiten Weg vor uns und werden uns alle diese Spezifikationen aus der XML-Welt noch etwas genauer ansehen. Zunächst gibt es aber einige Kürzel und Spezifikationen, die in einem XML-Dokument verwendet werden. Diese schauen wir uns als nächstes an. PI Eine PI in einem XML-Dokument ist eine Verarbeitungsanweisung (processing instruction). Eine Verarbeitungsanweisung teilt einer Applikation mit, eine bestimmte Aufgabe durchzuführen. PIs sind zwar nur ein kleiner Bestandteil der XML-Spezifikation, aber gleichwohl wichtig genug, um einen eigenen Abschnitt in unserer Behandlung der XML-Kürzel verdient zu haben. Eine PI unterscheidet sich von anderen XML-Dateien, weil sie einen Befehl an entweder den XML-Parser oder ein Programm repräsentiert, das das XML-Dokument verwendet. In unserem Beispieldokument in Beispiel 1 ist die erste Zeile, die die XML-Version angibt, eine Verarbeitungsanweisung. Sie teilt dem Parser mit, welche XML-Version verwendet wird. Verarbeitungsanweisungen haben die Form <?ziel anweisungen?>. Alle PIs mit dem Ziel XML sind ein Bestandteil der Standardmenge von PIs, die alle Parser verstehen sollten, und werden oft XML-Anweisungen genannt, aber PIs können auch Informationen angeben, die von Applikationen, die den Parser nur benutzen, verwendet werden. In solchen Fällen könnte der Applikation ein Schlüsselwort (wie etwa "cocoon") zugeordnet werden, das dann als Ziel der PI benutzt werden kann. Verarbeitungsanweisungen werden extrem wichtig, wenn XML-Daten in XML-fähigen Applikationen benutzt werden. Um ein etwas aussagekräftigeres Beispiel zu geben: Denken Sie sich eine Applikation, die unsere Beispiel-XML-Datei verarbeitet und daraus auf der Basis des Lagerbestands und der Informationen im XML-Dokument einen Werbeprospekt für einen Möbelladen generiert. Eine Verarbeitungsanweisung könnte die Applikation wissen lassen, daß manche Möbel auf einer "Gesucht"-Liste stehen und an eine andere Applikation weitergeleitet werden müssen, beispielsweise eine Applikation, die Bestellungen abarbeitet. Solche Möbel sollten natürlich nicht im Werbeprospekt auftauchen. Ein XML-Parser erkennt die PIs mit externen Zielen und leitet diese unverändert an die externe Applikation weiter. DTD Eine DTD ist eine Dokumenttyp-Definition (document type definition). Eine DTD legt eine Reihe von Einschränkungen für ein XML-Dokument (oder eine Reihe von Dokumenten) fest. Die DTD für sich genommen ist keine Spezifikation, sondern als ein Bestandteil der XMLSpezifikation definiert. In einem XML-Dokument kann eine Dokumenttyp-Definition sowohl Markup-Beschränkungen enthalten als auch auf ein externes Dokument mit solchen Beschränkungen verweisen. Die Summe dieser beiden Mengen von Beschränkungen bildet die Dokumenttyp-Definition. Eine DTD definiert, wie ein XML-Dokument aufgebaut werden muß. Schauen Sie sich noch einmal das XML-Dokument in Beispiel 1 an. Wir konnten zwar unsere eigenen Tags verwenden, aber dieses Dokument ist für eine andere Applikation oder sogar für einen anderen Menschen nutzlos, wenn diese nicht verstehen, was unsere Tags bedeuten. Obwohl man sich mit ein wenig gesundem Menschenverstand denken kann, was die meisten Tags bedeuten, gibt es doch noch Mehrdeutigkeiten. Besagt der Tag <quantity>, wie viele http://www.oreilly.de/artikel/xml_einf.html (4 of 20) [6/10/2002 2:14:00 PM] Java and XSLT Stühle noch am Lager sind? Kann ein wood-Attribut in einem <chair>-Tag angegeben werden? Diese Fragen müssen für ein XML-Dokument beantwortet werden, damit es von einem XML-Parser ordnungsgemäß überprüft ("validiert") werden kann. Ein Dokument gilt als gültig, wenn es den Einschränkungen gehorcht, die die DTD für die Formatierung der XML-Daten auferlegt. Das ist besonders wichtig, wenn Daten zwischen Applikationen übertragen werden sollen, weil es dann eine Übereinkunft geben muß, wie die Daten formatiert sind, und welche Syntax gelten soll, damit sich die Systeme verstehen können. Sie werden sich erinnern, daß wir weiter oben geschrieben haben, daß eine DTD die Einschränkungen für ein bestimmtes XML-Dokument oder eine Reihe von Dokumenten festlegt. Ein Entwickler oder Autor schreibt auch diese DTD als zusätzliches Dokument, das in seinen XML-Dateien referenziert wird, oder setzt es in die XML-Datei ein. Die DTD ist das, was den XML-Daten ihre Portabilität ermöglicht. Beispielsweise könnte sie definieren, daß für das Attribut wood nur "ahorn", "kiefer", "eiche" und "mahagoni" zulässige Werte sind. Damit kann der Parser feststellen, ob der Inhalt eines Dokuments akzeptabel ist, und so Datenfehler verhindern. Eine DTD definiert auch, inwieweit das Verschachteln von Tags erlaubt ist. Beispielsweise könnte sie vorschreiben, daß der Tag <cushion> nur eingeschachtelt im Tag <chair> vorkommen darf. Auf diese Art und Weise kann eine andere Applikation, die unsere Beispiel-XML-Datei bekommt, wissen, wie sie die Datei verarbeiten und wie sie darin suchen soll. Die DTD ist der Puzzlestein, der der Erweiterbarkeit eines XML-Dokuments Portabilität hinzufügt, was nicht nur zu flexiblen Daten führt, sondern auch zu Daten, die von jedem Rechner verarbeitet und validiert werden können, der Zugriff auf die DTD des Dokuments hat. Namensräume Das Konzept der Namensräume ist eines der wenigen Konzepte aus dem XML-Bereich, aus dem kein Kürzel gemacht worden ist. Es hat sogar einen Namen, der den Zweck erahnen läßt! Ein Namensraum ist eine Verknüpfung zwischen einem Element-Präfix und einem URI. Diese Verknüpfung wird zur Auflösung von Namensraum-Kollisionen und zum Definieren von Datenstrukturen verwendet, die dem Parser den Umgang mit Kollisionen ermöglichen. Als ein Beispiel für eine mögliche Namensraum-Kollision stellen Sie sich bitte ein XML-Dokument vor, in dem es ein <price>-Tag für einen Stuhl gibt, das zwischen <chair> und </chair> stehen muß. Die Definition eines Stuhles enthält aber auch einen <cushion>-Tag, der auch wiederum einen <price>-Tag haben kann. Bedenken Sie auch, daß das Dokument ein anderes XML-Dokument referenzieren kann, das etwa Copyright-Informationen enthält. Beide Dokumente enthalten dann möglicherweise <date>- oder <company>-Tags. Solcherart in Konflikt stehende Tags führen zu einer Mehrdeutigkeit, welcher Tag eigentlich was bedeutet. Diese Mehrdeutigkeit ist für einen XML-Parser ein ernsthaftes Problem. Soll der <price>-Tag je nach dem Element, in dem er enthalten ist, unterschiedlich interpretiert werden? Oder hat der Autor hier einen Fehler gemacht, den Tag in zwei unterschiedlichen Kontexten zu verwenden? Ohne zusätzliche Namensraum-Informationen ist es nicht möglich zu entscheiden, ob hier ein Fehler im Aufbau des XML-Dokuments vorliegt, oder, falls das nicht der Fall ist, wie die Daten in den miteinander in Konflikt stehenden Tags interpretiert werden sollen. Die XML-Namensraum-Empfehlung definiert einen Mechanismus, um diese Namen zu qualifizieren. Dieser Mechanismus verwendet URIs, aber darum müssen wir uns im Moment nicht weiter kümmern. Durch eine Qualifizierung sowohl der richtigen Verwendung als auch der Stellung von Tags wie <price> in unserem Beispiel kann man sich eher albern wirkende Tags wie <chair-price> und <cushion-price> ersparen. Statt dessen wird ein Namensraum mit einem Präfix eines XML-Elements verknüpft, was zu Tags wie <chair:price> und <cushion:price> führt. Ein XML-Parser kann dann zwischen diesen beiden Namensräumen unterscheiden, ohne völlig verschiedene Elementnamen benutzen zu müssen. Namensräume werden meistens in XML-Dokumenten verwendet, können aber auch in Schemata und XSLStylesheets wie auch in anderen XML-bezogenen Spezifikationen vorkommen. Die Empfehlung zu Namensräumen finden Sie unter http://www.w3.org/TR/REC-xml-names. XSL und XSLT http://www.oreilly.de/artikel/xml_einf.html (5 of 20) [6/10/2002 2:14:00 PM] Java and XSLT XSL ist die Extensible Stylesheet Language. XSL transformiert und übersetzt XML-Dateien von einem XML-Format in ein anderes. Stellen Sie sich beispielsweise vor, daß ein und dasselbe XML-Dokument in HTML, PDF und PostScript angezeigt werden muß. Ohne XSL müßte das XML-Dokument manuell dupliziert und dann in jedes dieser drei Formate konvertiert werden. Statt dessen stellt XSL einen Mechanismus bereit, in dem sogenannte Stylesheets ("Vorlagen") definiert werden, die diese Konvertierungsaufgaben übernehmen. Anstatt für eine andere Repräsentation die Daten ändern zu müssen, sorgt XSL für eine vollständige Trennung der Daten (dem Inhalt) von deren Präsentation. Wenn ein XML-Dokument auf eine andere Repräsentation abgebildet werden muß, dann ist XSL eine hervorragende Lösung. Es stellt eine Methode zur Verfügung, die mit dem Schreiben eines Java-Programms vergleichbar ist, das Daten in ein PDFoder HTML-Dokument konvertiert, verwendet aber eine standardisierte Schnittstelle, die diese Aufgabe erledigt. Um diese Umformung durchzuführen, kann ein XSL-Dokument Formatierungsobjekte enthalten. Diese Formatierungsobjekte sind Tags mit besonderen Namen, die durch den passenden Inhalt für den Ziel-Dokumenten-Typ ersetzt werden. Ein häufig vorkommendes Formatierungsobjekt kann beispielsweise einen Tag definieren, den ein Prozessor bei der Umwandlung eines XMLDokuments in PDF verwendet. In diesem Fall würde der Tag durch PDF-spezifische Informationen ersetzt werden. XSL hat seit kurzem den Status einer "Proposed Recommendation", weitere Informationen zu XSL finden Sie unter http://www.w3.org/TR/xsl. Wir werden uns hier mehr auf XSLT konzentrieren, einen vollständig textbasierten Umwandlungsvorgang. Während einer XSLT (Extensible Stylesheet Language Transformation) werden ein XSL-Text-Stylesheet und ein textuelles XML-Dokument "zusammengeführt", und das Ergebnis sind die entsprechend dem XSL-Stylesheet formatierten XML-Daten. Um dieses schwierige Konzept etwas zu verdeutlichen, schauen Sie sich bitte eine weitere XML-Datei an, die in Beispiel 2 zu sehen ist. Beispiel 2: Eine weitere XML-Beispieldatei XML File <?xml version="1.0"?> <?xml-stylesheet href="hello.xsl" type="text/xsl"?> <!-- Here is a sample XML file --> <page> <title>Testseite</title> <content> <paragraph>What you see is what you get!</paragraph> </content> </page> Dieses Dokument definiert sich selbst als XML Version 1.0 und nennt dann das dazugehörige XSL-Stylesheet, hello.xsl. Das sieht ähnlich wie die Verwendung einer DTD aus: So wie eine DTD in XML referenziert werden kann, um anzugeben, wie die Daten strukturiert werden können, kann eine XSL-Datei referenziert werden, um zu bestimmen, wie die Daten präsentiert und angezeigt werden sollen. Beispiel 3 zeigt das referenzierte XSL-Stylesheet. Beispiel 3: Das Stylesheet für Beispiel 2 <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:template match="page"> <html> <head> <title> <xsl:value-of select="title"/> </title> http://www.oreilly.de/artikel/xml_einf.html (6 of 20) [6/10/2002 2:14:00 PM] Java and XSLT </head> <body bgcolor="#ffffff"> <xsl:apply-templates/> </body> </html> </xsl:template> <xsl:template match="paragraph"> <p align="center"> <i> <xsl:apply-templates/> </i> </p> </xsl:template> </xsl:stylesheet> Dieses Stylesheet wurde dafür entworfen, unser einfaches XML-Dokument und dessen Daten in HTML-Code umzuwandeln, der in einem Web-Browser angezeigt werden kann. Auf die meisten Details kommen wir später noch zurück; hier wollen wir nur auf die <xsl:template match="[element name]">-Tags eingehen. Jedesmal, wenn ein solcher Tag auftritt, wird das Element beim passenden Tag wie etwa paragraph durch den Inhalt des XSL-Stylesheets ersetzt; in diesem Fall ein <p>-Tag durch einen kursiven Font. Das Ergebnis der Transformation des XML-Dokuments durch das XSL-Stylesheet sehen Sie in Beispiel 4. Beispiel 4: HTML-Ergebnis zu den Beispielen 2 und 3 <html> <head> <title> Testseite </title> </head> <body bgcolor="#ffffff"> <p align="center"> <i> What you see is what you get! </i> </p> </body> </html> Machen Sie sich jetzt noch keine Sorgen darüber, daß Sie nicht alle Feinheiten von XSL und XSLT verstehen; merken Sie sich im Moment nur, daß man mit XML und XSL hochflexible Dokumentenformate aus den gleichen zugrundeliegenden XML-Daten bekommen kann. XSLT ist seit 1999 offizielle W3C-Empfehlungen, Sie können sie unter http://www.w3.org/TR/xslt einsehen. Weitere Informationen zu XSL und XSLT finden Sie in Kapitel 6, XML umwandeln von Java und XML und in den Büchern XSLT und Java and XSLT. XPath XPath (XML Path Language) ist eine eigenständige Spezifikation, wird aber massiv von XSLT verwendet. Die XPath-Spezifikation definiert, wie ein bestimmtes Element in einem XMLDokument gefunden werden kann. Das geschieht durch das Referenzieren bestimmter Knoten (nodes) im XML-Dokument, wobei Knoten hier ein beliebiges Stückchen XML-Daten bedeutet, wozu Elemente, Attribute und textuelle Daten gehören. In der XPath-Spezifikation gilt ein XMLDokument als Baum aus diesen Knoten, und jeder Knoten kann durch seine Position im Baum angegeben werden. Wir brauchen nicht näher auf XPath eingehen, wenn wir nicht XSL und http://www.oreilly.de/artikel/xml_einf.html (7 of 20) [6/10/2002 2:14:00 PM] Java and XSLT XSLT genauer besprechen, aber prinzipiell werden Sie XPath immer dann verwenden müssen, wenn Sie eine Referenz auf ein bestimmtes Stückchen Daten in einem XML-Dokument brauchen. Um Ihnen zu zeigen, was Sie erwartet, folgt hier als Beispiel ein XPath-Ausdruck: *[not(self::JavaXML:Title)] Dieser Ausdruck hier wertet alle Kindelemente des aktuellen Elements aus, deren Name nicht JavaXML:Title ist. Für das Dokumentenfragment <JavaXML:Book> <JavaXML:Title>Java and XML</JavaXML:Title> <JavaXML:Content> <!-- Hier stehen die Kapitel --> </JavaXML:Content> <JavaXML:Copyright>&OReillyCopyright;</JavaXML:Copyright> </JavaXML:Book> ergibt das Auswerten des Ausdrucks für das Element JavaXML:Book als aktuellem Knoten die Elemente JavaXML:Content und JavaXML:Copyright. Die vollständige XPathSpezifikation ist online unter http://www.w3.org/TR/xpath nachzulesen. XML Schema XML Schema wurde entworfen, um DTDs zu ersetzen und zu erweitern. XML Schema ist ein XML-zentriertes Mittel, um XML-Dokumente einzuschränken. Obwohl wir uns bisher nur kurz mit DTDs auseinandergesetzt haben, gibt es bei diesen doch einige ziemlich kritische Einschränkungen: Sie kennen die Hierarchie nicht, haben Schwierigkeiten beim Umgang mit Namensraum-Konflikten, und es ist mit ihnen nicht möglich, Beziehungen zwischen XMLDokumenten anzugeben. Das ist auch verständlich, denn die Mitglieder der Arbeitsgruppe, die die Spezifikation erarbeitete, konnten nicht ahnen, daß XML auf so viele verschiedene Arten und Weisen verwendet werden würde! Die Einschränkungen von DTD sind aber für XML-Autoren und -Entwickler ziemlich unangenehm geworden. Am wichtigsten an XML Schema ist, daß es DTDs wieder mit XML auf eine Linie bringt. Das klingt möglicherweise verwirrend, aber denken Sie daran, daß jedes Kürzel, über das wir bisher geredet haben, XML-Dokumente verwendet, um seinen Zweck zu definieren. XSL-Stylesheets, Namensräume und alle anderen verwenden XML, um bestimmte Anwendungen und Eigenschaften von XML zu definieren. Aber eine DTD ist etwas ganz anderes. Eine DTD sieht nicht aus wie XML, besitzt nicht die hierarchische Struktur von XML und repräsentiert Daten nicht auf die gleiche Weise. Das macht DTDs zu einem Außenseiter in der XML-Welt, und weil DTDs derzeit definieren, wie XML-Dokumente aufgebaut sein müssen, hat dies zu einiger Verwirrung geführt. XML Schema behebt dieses Problem, indem es zu XML selbst zurückkehrt, um XML zu definieren. Wir haben bereits ziemlich viel über das "Definieren von Daten über Daten" gesprochen, und XML Schema macht ebenfalls genau dies. Die XML SchemaSpezifikation bringt XML dem Ziel näher, alle Konstrukte in der gleichen Sprache zu haben, anstelle mit DTDs als einer notwendigen, aber üblen Abweichung zu jonglieren. Die W3C- und XML-Entwickler waren so klug zu erkennen, daß es vergebliche Liebesmüh sein würde, DTDs zu verbessern. Statt dessen wurde zusätzlich XML Schema entwickelt, das DTDs ersetzen soll und dabei die Probleme behebt, mit denen DTDs nicht zurechtkommen. Außerdem wird an Verbesserungen im Hinblick auf die derzeit uneinheitliche Verwendung von XML gearbeitet. XML Schema ist seit Mai 2001 eine abgeschlossene offizielle W3C-Empfehlung. Sie besteht aus drei Teilen: Part 0, Primer (http://www.w3.org/TR/xmlschema-0/) ist ein nützliches Tutorial, Part 1, Structures (http://www.w3.org/TR/xmlschema-1/) und Part 2, Datatypes (http://www.w3.org/TR/xmlschema-2/) sind die eigentliche Schema-Spezifikation. http://www.oreilly.de/artikel/xml_einf.html (8 of 20) [6/10/2002 2:14:00 PM] Java and XSLT Und alle anderen ... Wir sind jetzt durch eine sehr kurze Einführung einiger der wichtigsten Spezifikationen aus dem XML-Bereich, die wir in diesem Buch behandeln werden, hindurchgerast. Ihnen fallen möglicherweise noch ein oder zwei Kürzel ein, die wir bisher noch nicht behandelt haben, wenn nicht sogar mehr. Wir haben hier nur die Abkürzungen ausgewählt, die für unsere Beschreibung der Verarbeitung von XML in Java besonders wichtig sind. Es gibt noch eine ganze Reihe weitere, von denen einige hier mit den URLs der entsprechenden Empfehlungen oder Arbeitspapiere aufgeführt sind: ● ● ● ● ● ● Resource Description Framework (RDF): http://www.w3.org/RDF/ XLink: http://www.w3.org/TR/xlink/ XPointer: http://www.w3.org/TR/xptr/ XHTML: http://www.w3.org/TR/xhtml-basic/ XMLBase: http://www.w3.org/TR/xmlbase/ XQuery: http://www.w3.org/TR/xquery/ Auch diese Liste ist bei weitem nicht vollständig, laufend kommen weitere neue Technologien hinzu. Nur weil wir nicht alle nennen können, sollten Sie aber nicht denken, daß sie weniger wichtig sind; sie sind nur nicht so unabdingbar, wenn es um die Manipulation von XML-Daten in Java geht. Zum vollständigen Verständnis und zum Beherrschen von XML gehört natürlich auch die Kenntnis dieser Spezifikationen neben denen, die wir detaillierter besprochen haben. Wie benutze ich das? All die großartigen Ideen, die XML uns gebracht hat, sind nicht besonders nützlich ohne die Werkzeuge, mit denen wir sie in unseren gewohnten Programmierumgebungen verwenden können. Glücklicherweise ist XML von Anfang an zusammen mit Java verwendet worden, und Java enthält die vollständigste Menge von APIs zur direkten Verwendung von XML. Zwar holen C, C++ und Perl schnell auf, aber Java setzt weiterhin die Standards, wie XML in Applikationen verwendet werden soll. Es gibt zwei grundlegende Abschnitte während des Lebenszyklus eines XML-Dokuments aus Applikationssicht, wie in Abbildung 1 zu sehen ist. Zuerst wird das Dokument geparst, und dann werden die Daten manipuliert. Abbildung 1: Die Sicht der Applikation auf den Lebenszyklus eines XML-Dokuments Als Java-Entwickler können wir uns glücklich schätzen, daß wir einfache Möglichkeiten haben, diese Aufgaben und andere zu erledigen. SAX http://www.oreilly.de/artikel/xml_einf.html (9 of 20) [6/10/2002 2:14:00 PM] Java and XSLT SAX ist die Simple API for XML. Es stellt ein ereignisbasiertes Framework zum Parsen von XML-Daten bereit, also für den Prozeß des Durchlesens des Dokuments und des Zerteilens der Daten in benutzbare Teile. Für jeden Schritt definiert SAX Ereignisse, die auftreten können. Beispielsweise definiert SAX ein Interface org.xml.sax.ContentHandler, das Methoden wie startDocument( ) und endElement( ) definiert. Das Implementieren dieses Interfaces ermöglicht die vollständige Kontrolle über die einzelnen Abschnitte des XMLParsing-Vorgangs. Es gibt ein ähnliches Interface für die Behandlung von Fehlern und lexikalischen Konstrukten. Eine Reihe von Fehlern und Warnungen ist definiert, was das Reagieren auf Situationen ermöglicht, die beim Parsen von XML-Dokumenten auftreten können, wie etwa das Auftreten ungültiger oder nicht wohlgeformter Dokumente. Es kann zusätzliches Verhalten hinzugefügt und der Parsing-Vorgang auf diese Weise angepaßt werden, was die Definition sehr applikationsspezifischer Aufgaben ermöglicht, und alles mit einem StandardInterface auf XML-Dokumente. Die SAX-API-Dokumente und weitere Informationen über die aktuelle Version SAX 2.0 finden Sie unter http://www.megginson.com/SAX. Bevor wir hier weitermachen, ist es wichtig, ein häufiges Mißverständnis über SAX aufzuklären. SAX wird oft mit einem XML-Parser verwechselt. Wir besprechen SAX hier sogar als eine Möglichkeit, XML-Daten zu parsen. SAX stellt aber ein Framework bereit, das Parser verwenden können, und definiert Ereignisse, die im Parsing-Vorgang überwacht werden können. SAX muß einen Parser bekommen, damit überhaupt XML geparst werden kann. Das hat zu vielen hervorragenden Parsern in Java geführt, darunter Project X von Sun, Xerces von der Apache Software Foundation, XML-Parser von Oracle und XML4J von IBM. All diese Parser können in die SAX-APIs eingestöpselt werden und führen zu geparsten XML-Daten. SAX-APIs bieten ein Mittel, um ein Dokument zu parsen, sind aber selbst keine XML-Parser. DOM DOM ist eine API für das Document Object Model. Während SAX nur den Zugriff auf die Daten in einem XML-Dokument ermöglicht, wurde DOM entworfen, um diese Daten auch manipulieren zu können. DOM wurde als Verfahren entworfen, das ein XML-Dokument als Baum repräsentiert. Weil ein Baum eine uralte Datenrepräsentation ist, ist das Traversieren und Manipulieren von Baumstrukturen in den meisten Programmiersprachen sehr einfach zu bewerkstelligen - so auch in Java. DOM liest das gesamte XML-Dokument in den Speicher ein und speichert alle Daten in Knoten (nodes), so daß man sehr schnell auf das gesamte Dokument zugreifen kann: Es befindet sich vollständig im Speicher, solange der DOM-Baum existiert. Jeder Knoten repräsentiert ein Datenstückchen, das aus dem ursprünglichen Dokument geholt wurde. DOM hat aber einen bedeutsamen Nachteil. Weil DOM das gesamte Dokument in den Speicher liest, können die zur Verfügung stehenden Ressourcen stark in Anspruch genommen werden, was eine Applikation erheblich bremsen oder sogar unbenutzbar machen kann. Je größer und komplexer das Dokument ist, um so auffälliger wird dieser Performance-Verlust. Denken Sie daran, daß DOM zwar eine gute Möglichkeit zum Manipulieren von XML-Daten ist, aber bei weitem nicht die einzige. Wir werden uns eine ganze Zeitlang mit DOM beschäftigen, aber auch Code schreiben, der die Daten direkt von SAX aus manipuliert. Die Anforderungen Ihrer Applikation werden in den meisten Fällen schon darauf hindeuten, welche Lösung für Ihr jeweiliges Entwicklungsprojekt die beste ist. Die DOM-Empfehlungen des W3C können Sie unter http://www.w3.org/DOM nachlesen. JAXP JAXP ist die Java API for XML Parsing von Sun. Dies ist ein relativ neues Werkzeug im Arsenal des XML-Entwicklers, das die SAX- und DOM-APIs vervollständigen soll. Es steht aber nicht in Konkurrenz zu diesen APIs und soll sie auch nicht ersetzen, sondern fügt einfach nur ein paar bequeme Methoden hinzu, die die Verwendung der XML-APIs erleichtern sollen. JAXP gehorcht den SAX- und DOM-Spezifikationen sowie der Namensraum-Empfehlung, die wir http://www.oreilly.de/artikel/xml_einf.html (10 of 20) [6/10/2002 2:14:00 PM] Java and XSLT weiter oben besprochen haben. JAXP definiert das Verhalten von SAX oder DOM nicht um, stellt aber sicher, daß alle XML-konformen Parser von Java-Applikationen aus über eine standardisierte Abstraktionsschicht erreicht werden können. Man erwartet, daß sich JAXP mit SAX und DOM weiterentwickeln wird. Im Moment ist JAXP 1.1 beispielsweise in J2SETM 1.4 und J2EETM 1.3 eingebaut und als optionales Paket für JDK 1.1.8 erhältlich. Die vollständige JAXP-Spezifikation finden Sie unter http://java.sun.com/xml. Diese drei APIs stellen den Werkzeugkasten des Java-Programmierers dar, wenn es um XML geht. Sie liefern einen Mechanismus, um XML-Daten in normalem Java-Code zu lesen und zu manipulieren, auch wenn das vielleicht nicht ihr eigentlicher Zweck ist. Diese APIs werden im gesamten Buch unsere Arbeitspferde sein, und wir werden lernen, jeden Aspekt der enthaltenen Klassen zu verwenden. Warum sollte ich XML verwenden? Sie haben jetzt einen ersten Eindruck von der Buchstabensuppe der XML-Technologien gewonnen. Ihnen ist auch klar geworden, daß XML mehr ist als einfach eine weitere Präsentationsschicht. Aber Sie sind sich nicht sicher, wie XML in die Applikationen paßt, die Sie bei der Arbeit verwenden. Sie haben Zweifel, ob Sie Ihren Chef davon überzeugen können, Sie während der Arbeitszeit mehr über XML lernen zu lassen, weil Sie nicht wissen, wie XML Ihnen helfen kann, bessere Applikationen zu entwickeln. Sie denken sogar darüber nach, einige XMLWerkzeuge zu evaluieren, wissen aber nicht, wo Sie anfangen sollen. Wenn dies Ihre jetzige Situation beschreibt und Sie von der neuen Technologie begeistert sind, aber nicht wissen, wie Sie jetzt weitermachen sollen, dann lesen Sie weiter! In diesem Abschnitt werden wir XML in die Scheinwerfer von realen Applikationen rücken und Ihnen Gründe dafür liefern, warum Sie XML bereits heute in Ihren Applikationen verwenden sollten. Zuerst schauen wir uns an, wie XML bereits in Applikationen verwendet wird, und liefern Ihnen die Informationen, mit denen Sie Ihren Chef überzeugen können, daß "alle das machen". Anschließend schauen wir uns die vorhandene Unterstützung für XML und verwandte Technologien an - alles im Hinblick auf Java-Applikationen. In Java gibt es eine Vielzahl von verfügbaren Parsern, Umformern, Publishing Engines und Frameworks, die extra für XML entworfen worden sind. Schließlich werden wir einen Blick darauf werfen, in welche Richtung sich XML bewegt und wie es in sechs Monaten und einem Jahr aussehen wird. Das ist die Information, mit der Sie den Chef Ihres Chefs überzeugen können, daß XML nicht nur dabei hilft, mit den Mitbewerbern mitzuhalten, sondern auch dabei eine führende Stellung in der Industrie einzunehmen - und Ihnen die nächste Beförderung einbringt! Java und XML: Wie geschaffen füreinander Selbst wenn Sie bereits überzeugt sind, daß XML eine großartige Technologie ist und daß es die Welt im Sturm erobern wird, haben wir noch keine Gründe dafür geliefert, warum es hier um Java und XML geht und nicht nur um XML allein. Java ist nämlich das ideale Gegenstück zu XML. Das kann man in einem einzigen Satz begründen: Java bedeutet portablen Code, und XML bedeutet portable Daten. Beide Technologien für sich sind schon großartig, haben aber noch Einschränkungen. Entwickler müssen sich Formate für Netzwerkdaten und Präsentationsformate ausdenken und Technologien wie JavaServer PagesTM (JSP) verwenden, die keine echte Trennung zwischen Inhalt und Präsentationsschicht bieten. XML bedeutet einfach Metadaten, und ohne Programme wie Parser und XSL-Prozessoren ist XML nicht mehr als "Vaporware", heiße Luft also. Java und XML zusammen füllen aber die Lücken im Gesamtbild der Anwendungsentwicklung. Das Verwenden von Java-Code stellt sicher, daß jedes Betriebssystem und jede Hardware mit einer JavaTM Virtual Machine ( JVM) Ihren kompilierten Bytecode ausführen kann. Fügen Sie dazu die Fähigkeit hinzu, Ein- und Ausgaben in Ihrer Applikation mit einer http://www.oreilly.de/artikel/xml_einf.html (11 of 20) [6/10/2002 2:14:00 PM] Java and XSLT systemunabhängigen, standardisierten Datenschicht repräsentieren zu können, und Ihre Daten sind portabel. Ihre Applikation ist damit vollständig portabel und kann mit anderen Applikationen mit den gleichen (weithin akzeptierten) Standards kommunizieren. Und als wenn das noch nicht genug wäre, hat Java von allen Programmiersprachen den umfangreichsten Satz an APIs, Parsern, Prozessoren, Publishing Frameworks und Werkzeugen für XML. Schauen wir uns mit diesem Synergiegedanken im Kopf an, wie diese beiden Technologien zusammenpassen, und zwar sowohl heute als auch morgen. XML heute Viele Entwickler und Hochtechnologie-Firmen haben zwar den Eindruck, daß XML ein hochaktuelles Thema ist und "Buzzword-Status" erreicht hat, aber das es für unternehmenskritische Anwendungen, auf die sich diese Firmen so sehr verlassen, noch nicht geeignet ist. Diese Annahme ist grundfalsch. XML und die zugehörigen Technologien, über die wir gesprochen haben, haben sich noch schneller einen sicheren Platz in der Applikationsentwicklung gesichert, als das bei Java der Fall war, als es vor einigen Jahren angekündigt wurde. Tatsächlich ist XML möglicherweise die einzige Neuerung in der Welt der Softwareentwicklung, die in der Bedeutung mit der Java-Plattform mithalten kann. Für uns als Entwickler ist es ein Glücksfall, daß sich diese Technologien ergänzen, anstatt miteinander zu konkurrieren. Mit Java und XML steht die Portabilität von Applikationen und Daten heute so hoch im Kurs wie noch nie und wird bereits massiv verwendet, auch jetzt, während Sie gerade diesen Text lesen. XML als Präsentationsschicht Der beliebteste Anwendungszweck von XML ist die Trennung von Inhalt und Präsentation. In dieser Situation definieren wir den Applikations-Inhalt als die Daten, die einem Client angezeigt werden müssen, und die Applikations-Präsentation als die Formatierung dieser Daten. Beispielsweise wären der Benutzername und die Adresse des Benutzers im Verwaltungsteil eines Bestellsystems Inhalt, während die HTML-formatierte Seite mit Bildern und Firmenlogo die Präsentation wäre. Der hauptsächliche Unterschied besteht darin, daß der Inhalt in der Applikation überall gleich und überall gleichermaßen gültig ist, unabhängig davon, welche clientspezifische Formatierung notwendig ist. Die Präsentation dagegen ist von der Art des Clients abhängig (Web-Browser, WAP-Telefon, Java-Applikation) und von dessen Fähigkeiten (HTML 4.0, Wireless Markup Language (WML), JavaTM Swing), die Daten darzustellen. XML dient dazu, den Inhalt zu repräsentieren, während XSL und XSLT eine für den Client passende Präsentation liefern. Eine der wichtigsten Herausforderungen für heutige Applikationen, und insbesondere für WebApplikationen, ist die Vielzahl von Clients, die diese Applikation eventuell verwenden wollen. Vor zehn Jahren verwendeten die Anwender fast immer PCs, bei denen die Software auf ihren Desktop-Rechnern installiert wurde; vor drei Jahren waren die Applikations-Clients fast immer Internet-Web-Browser, die HTML verstanden. Heutige Clients benutzen Web-Browser auf einer Vielzahl von Betriebssystemen, drahtlosen Mobiltelefonen, die die Wireless Markup Language (WML) unterstützen, und Taschen-Organizern, die eine Untermenge von HTML unterstützen. Diese Vielfalt von Client-Typen führt oft dazu, daß es viele Versionen von einer Applikation gibt - je eine pro unterstütztem Client - und trotzdem nicht alle vorkommenden Clients unterstützt werden. Obwohl eine Applikation ein Mobiltelefon natürlich nicht unterstützen muß, ist es sicherlich von Vorteil, wenn die Angestellten oder die Kunden den Dienst benutzen können, wenn sie ein solches haben; und auch wenn man mit einem Taschen-Organizer nicht alles das machen kann, was man mit einem Web-Browser macht, würden Geschäftsreisende, die ihre Spesenabrechnungen online bearbeiten, das sicherlich auch gern mit dem Organizer erledigen. Der Übergang von Software mit hoher Funktionalität, die nur bestimmte Clients unterstützt, zu Software mit einer Standardfunktionalität, die einer gewaltigen Vielzahl von Client-Typen zur Verfügung steht, hat viele Entwickler und Firmen ratlos gemacht. XML kann das Mittel gegen diese Ratlosigkeit sein. http://www.oreilly.de/artikel/xml_einf.html (12 of 20) [6/10/2002 2:14:00 PM] Java and XSLT Wir haben zwar weiter oben gesagt, daß XML keine Präsentationstechnologie ist, aber es kann durchaus dazu verwendet werden, eine Präsentationsschicht zu erzeugen. Wenn Sie meinen, daß diese beiden Aussagen doch das gleiche sind, dann überlegen Sie sich einmal folgendes: HTML ist eine Präsentationstechnologie. Es ist eine Markup-Sprache, die speziell für grafische Ansichten von Inhalten mit Web-Browser-Clients entworfen wurde. Aber HTML ist in keiner Weise eine gute Datenrepräsentation. Ein HTML-Dokument ist nicht leicht zu parsen, zu durchsuchen oder zu manipulieren. Es hat nur ein lose definiertes Format und besteht mindestens zur Hälfte, wenn nicht noch zu einem größeren Teil, aus Präsentationsinformationen - und die eigentlichen Daten sind nur ein kleiner Teil des Dokumentes. XML ist dagegen etwas ganz anderes, es ist eine daten-gesteuerte Markup-Sprache. Fast alles in einem XML-Dokument sind Daten und deren Struktur. Nur Anweisungen an den XML-Parser oder die umgebende Applikation sind nicht daten-zentriert. XML kann aufgrund seiner strikten Struktur, die eine DTD oder ein Schema erzwingen kann, einfach mit APIs und Werkzeugen durchsucht und manipuliert werden. Das macht XML alles andere als präsentationsorientiert. Aber XML kann gemeinsam mit den Begleittechnologien XSL und XSLT zur Präsentation verwendet werden. XSL ermöglicht die Definition von Präsentations- und Formatierkonstrukten sowie Anweisungen, wie diese Konstrukte auf die Daten in einem XML-Dokument anzuwenden sind. Und mit Hilfe von XSLT kann der ursprüngliche XML-Code einem Client auf vielerlei Weise angezeigt werden, darunter auch in sehr komplexem HTML. Trotzdem bleibt das zugrundeliegende XML-Dokument von irgendwelchen präsentationsspezifischen Informationen getrennt und kann genauso einfach in einen ganz anderen Präsentationsstil wie etwa ein SwingBenutzer-Interface überführt werden, ohne daß der zugrundeliegende Inhalt geändert werden müßte. Die vielleicht mächtigste Komponente, die XML und XSL zur Präsentation beisteuern, ist die Fähigkeit, mehrere Stylesheets für ein XML-Dokument anzugeben oder XSL-Stylesheets extern auf ein XML-Dokument aufzusetzen. Das fügt der Präsentation noch eine weitere Flexibilitätsebene hinzu, weil nicht nur ein und dasselbe XML-Dokument für verschiedene Präsentationen verwendet werden kann, sondern ein Publishing Framework, das eine Umformung durchführt, kann auch ermitteln, was für ein Client das XML-Dokument anfordert, und auf dieser Basis das richtige Stylesheet auswählen. Es gibt zwar kein standardisiertes Verfahren für diesen Vorgang und auch keine standardisierte Menge von Codes für die verschiedenen Client-Typen, aber ein XML-Publishing Framework kann Möglichkeiten bereitstellen, um eine solche dynamische Umformung zu gewährleisten. Der Vorgang, mehrere XSL-Stylesheets in einem XML-Dokument anzugeben, ist nicht herstellerabhängig, weswegen die einzigen Framework-Details, über die Sie sich in Ihrem XML-Dokument Gedanken machen müssen, die eine oder andere zusätzliche Verarbeitungsanweisung sein könnten. Weil diese einfach ignoriert werden, wenn eine Applikation sie nicht unterstützt, bleiben die XMLDokumente vollständig portabel und standardkonform. XML als Kommunikationswerkzeug Neben diesen nützlichen Umformungsfähigkeiten können das gleiche XML-Dokument und seine Daten auch dazu verwendet werden, um Informationen zwischen Applikationen auszutauschen. Diese Kommunikation erreicht man ziemlich leicht, weil die XML-Daten nicht an irgendeinen Client-Typ gebunden sind, ja nicht einmal daran, überhaupt von einem Client verwendet zu werden. Außerdem ist XML eine sehr einfache Datenrepräsentation, die sich sehr leicht über ein Netzwerk übertragen läßt. Dieser Kommunikationsaspekt von XML ist wahrscheinlich das am häufigsten übersehene und unterschätzte Feature von XML-Dokumenten und Datenrepräsentationen. Um die Bedeutung von XML für Kommunikationen richtig verstehen zu können, müssen Sie zunächst Ihre Vorstellung von einem Applikations-Client erweitern. Als wir über Präsentationen gesprochen haben, sind wir immer davon ausgegangen, daß ein Client ein Benutzer ist, der einen Teil der Applikation ansehen will. Das ist aber in heutigen Applikationen eine ziemlich eingeschränkte Sichtweise, die wir hiermit verwerfen wollen. Nehmen Sie statt dessen an, daß ein Client irgend etwas (ja, irgend etwas!) ist, das in einer Applikation auf Daten oder Dienste zugreifen will. Clients können Benutzer mit Computern oder mobilen Geräten sein, andere http://www.oreilly.de/artikel/xml_einf.html (13 of 20) [6/10/2002 2:14:00 PM] Java and XSLT Applikationen, Datenspeichersysteme wie Datenbanken oder Verzeichnisdienste und manchmal sogar die Applikation selbst mittels Callbacks. Wenn Sie den Client-Begriff dermaßen erweitern, dann beginnen Sie zu sehen, was für einen Einfluß XML hier haben kann. Fassen Sie zunächst diese Client-Typen in zwei Gruppen zusammen: eine Gruppe, die eine Präsentationsschicht benötigt, und eine, die das nicht tut. Am Anfang ist diese Unterscheidung vielleicht nicht einfach. Manche Benutzer schauen sich vielleicht Daten als HTML oder WML (Wireless Markup Language) an, aber eine andere Applikation braucht die Daten möglicherweise in einem etwas anderen Format, möglicherweise müssen sicherheitskritische Inhalte weggelassen oder verschiedene Elementnamen benutzt werden. Es wird wahrscheinlich selten der Fall sein, daß ein Client die Daten nicht auf irgendeine Weise formatiert benötigt, die dem Zweck entspricht, zu dem der Client die Daten haben will. Diese Übung sollte Sie davon überzeugen, daß Daten fast immer umgeformt werden, oft sogar mehrfach. Denken Sie etwa an ein XML-Dokument, das mittels eines XSL-Stylesheets in ein für eine andere Applikation nutzbares Format konvertiert wird (siehe Abbildung 2). Das Ergebnis ist weiterhin XML. Diese Applikation kann dann die Daten verwenden, um eine neue Ergebnismenge zu ermitteln und ein neues XML-Dokument zu erzeugen. Die ursprüngliche Applikation braucht diese Information dann auch, also wird das neue XML-Dokument in das von der ersten Applikation verwendete Format zurückkonvertiert, obwohl es jetzt andere Daten enthält! Dieses Szenario kommt sehr häufig vor. Die Sicht der Applikation auf den Lebenszyklus eines XML-Dokuments Abbildung 2: XML/XSL-Transformationen zwischen Applikationen Dieser wiederholte Vorgang des Konvertierens eines Dokuments, bei dem immer wieder ein neues XML-Ergebnis herauskommt, macht XML erst zu so einem mächtigen Werkzeug für die Kommunikation. In jedem Schritt können die gleichen Regeln angewendet werden, die immer von XML ausgehen, eines oder mehrere XSL-Stylesheets auf eine oder mehrere Transformationen anwenden und am Ende immer noch XML herausbekommen, das immer noch mit den gleichen Werkzeugen verwendet werden kann, die das Dokument ursprünglich erzeugt hatten. Bedenken Sie auch, daß XML eine rein textuelle Repräsentation der Datei ist. Weil Text so eine leichtgewichtigte und leicht serialisierbare Datenrepräsentation ist, hat man mit XML eine schnelle Möglichkeit, Daten über ein Netzwerk zu transportieren. Auch wenn manche binären Datenformate sehr effizient übertragen werden können, stellen sich textuelle NetzwerkÜbertragungen üblicherweise als das schnellere Kommunikationsverfahren heraus. http://www.oreilly.de/artikel/xml_einf.html (14 of 20) [6/10/2002 2:14:00 PM] Java and XSLT XML-RPC XML-RPC ist eine der Spezifikationen, die sich mit der Verwendung von XML für Kommunikationsaufgaben beschäftigen. Bei XML-RPC geht es nicht um die Kommunikation zwischen Applikationen, sondern um die Kommunikation zwischen Komponenten innerhalb einer Applikation oder mit einer gemeinsamen Menge von Diensten, die mehreren Applikationen dienen. RPC steht für Remote Procedure Calls, einem der wichtigsten Vorläufer der Remote Method Invocation (RMI). RPC wird für prozedurale Aufrufe über ein Netzwerk und zum Empfangen einer Antwort, ebenfalls über das Netzwerk, verwendet. Beachten Sie, daß das etwas ganz anderes ist als RMI, wo ein Client Methoden eines Objekts über Stubs und Skeletons (Skelette) aufrufen kann, die über das Netzwerk geladen werden. Der Hauptunterschied besteht darin, daß RPC eine entfernte Antwort erzeugt und diese über das Netzwerk zurückgeschickt wird; der Client interagiert nie direkt mit dem entfernten Objekt, sondern verwendet die RPCSchnittstellen, um einen Methodenaufruf anzufordern. Bei RMI kann ein Client direkt mit einem entfernten Objekt interagieren; es sind keine Proxies dazwischengeschaltet. Eine vollständigere Beschreibung von XML-RPC finden Sie unter http://www.xml-rpc.com. Was an RPC und speziell an XML-RPC besonders bemerkenswert ist, ist die Tatsache, daß diese nun eine gangbare Option für Aufrufe entfernter Dienste geworden sind. RPC ist wegen der Schwierigkeiten, ein standardisiertes Anfrage-Antwort-Modell bereitzustellen, in JavaApplikationen kaum zu finden und durch RMI ersetzt worden. Es gibt aber oft Situationen, in denen das Laden entfernter Stubs und Skeletons über das Netzwerk zu einer schlechteren Performance führt als das Senden und Empfangen textueller Daten. Das alte Problem von RPC war immer das Repräsentieren komplexer Objekte mit rein textuellen Informationen, und zwar sowohl für Anfragen als auch für Antworten. XML hat dieses Problem gelöst, was RPC wieder zu einer gangbaren Alternative macht, wenn es um das Kommunizieren von eige ntlich nicht zusammengehörigen Systemen geht. Mit einem Standard für das Repräsentieren beliebiger Datentypen in Textdokumenten kann eine XML-RPC-Engine die Instanzparameter eines Objekts auf XML-Elemente abbilden und diesen Objekt-"Graphen" am Server einfach dekodieren. Eine Antwort kann generiert und wiederum einfach in einen XML-"Graphen" umgewandelt und an den Client zurückgegeben werden (siehe Abbildung 3). Weitere Informationen zu XML-RPC finden Sie in Kapitel 10, XML-RPC, in Java und XML und in Programming Web Services with XML-RPC. Abbildung 3: XML-RPC-Kommunikation und -Messaging Business-to-Business Der letzte Einsatzbereich von XML für Kommunikationszwecke ist eigentlich kein anderer und keine andere Spezifikation als die, über die wir bereits gesprochen haben, aber das Auftreten des http://www.oreilly.de/artikel/xml_einf.html (15 of 20) [6/10/2002 2:14:00 PM] Java and XSLT Begriffs "Business-to-Business"-Handel und -Kommunikation ist doch erwähnenswert. Man meint damit die Kommunikation nicht nur zwischen verschiedenen Anwendungen, sondern auch zwischen verschiedenen Firmen und manchmal sogar zwischen verschiedenen Industrien. In diesen Fällen leistet XML wirklich einen wertvollen Dienst, der in der Vergangenheit nur den allergrößten Firmen zur Verfügung stand: die Kommunikation zwischen geschlossenen Systemen. Denken Sie beispielsweise an einen kleineren oder mittleren lokalen TelekomProvider. Wenn dieser eine Netzwerk-Leitung wie DSL oder T1 an einen Kunden verkauft, muß eine Reihe von Dingen passieren (siehe Abbildung 4). Der Provider der Leitung selbst, etwa UUNet, muß über die Anforderung einer neuen Leitung informiert werden. Der Provider muß einen Router konfigurieren, und dessen Einstellung muß mit dem Internet-Provider abgesprochen werden. Dann wird die Installation vorgenommen, was möglicherweise wiederum von einer weiteren Firma ausgeführt wird. Dieser relativ häufig vorkommende und einfache Verkauf einer Netzwerkleitung berührt bereits drei Firmen! Fügen Sie dazu noch den technischen Support des Router-Herstellers, den Telefon-Provider für die anderen Kommunikationsdienste des Kunden und das NIC zum Registrieren der Domain hinzu, und Sie sehen, was da alles dazugehört. Abbildung 4: Eine Netzwerkleitung zu einem Kunden mit proprietären Systemen einrichten Dieser etwas einschüchternde Vorgang kann mit XML extrem einfach gestaltet werden (wie in Abbildung 5 zu sehen ist). Stellen Sie sich vor, daß die erste Bestellung einer Leitung in ein System eingegeben wird, das die Bestellung in ein XML-Dokument umwandelt. Dieses Dokument wird dann mittels XSL in ein Format umgewandelt, das der Leitungslieferant, in unserem Beispiel UUNet, verstehen kann. UUNet fügt dann leitungsspezifische Informationen hinzu und konvertiert die Bestellung in ein weiteres XML-Dokument, das an den Provider zurückgegeben wird. Dieses neue Dokument wird dann unter Hinzufügen der Information, wo sich der Kunde befindet, an die Firma weitergeleitet, die die Installation vornimmt. Nach der Installation wird ein Vermerk, ob diese erfolgreich war oder nicht, an das Dokument angefügt, dieses wieder mittels XSL konvertiert und an den Provider zurückgeschickt. Das Schöne an dieser Lösung ist, daß nicht verschiedene Systeme mit jeweils herstellerspezifischen Formatierungen verwendet werden müssen, sondern in jedem Schritt die gleichen XML-APIs benutzt werden können, wodurch man eine Standardschnittstelle zu XML-Daten über Applikationen, Systeme und sogar Firmen hinweg hat. http://www.oreilly.de/artikel/xml_einf.html (16 of 20) [6/10/2002 2:14:00 PM] Java and XSLT Abbildung 5: Eine Netzwerkleitung zu einem Kunden mit XML-basierten Daten einrichten XML in der Konfiguration Ein letzter wichtiger, schon heute aktueller Anwendungsbereich von XML in Applikationen und Java-Technologien ist die Ebene der Applikationsserver. Die Enterprise Java Beans (EJB) 1.1Spezifikation verlangt, daß die Deployment-Deskriptoren für Enterprise JavaBeans, die das Verhalten von und andere Informationen über EJBs definieren, XML-basiert sind. Diese ersetzen die vorher verwendeten serialisierten Deployment-Deskriptoren. Diese Änderung wurde im EJBBereich sehr begrüßt, weil die Deployment-Deskriptoren damit nicht mehr herstellerspezifisch sind. Indem man verlangt, daß die Deployment-Deskriptoren alle einer vordefinierten DTD gehorchen, wird die Portabilität von EJB verbessert. XML wird auch in der Konfiguration der Version 2.2 der Servlet-API verwendet. Eine XMLDatei, die die zu verwendenden Connector-Parameter, die zu startenden Servlet-Kontexte und weitere Engine-spezifische Details spezifiziert, konfiguriert die Servlet-Engine selbst. XMLKonfigurationsdateien werden auch dazu verwendet, die einzelnen Servlets zu konfigurieren, was initiale Argumente, Aliasnamen für Servlets und das Vergleichen von URLs für bestimmte Servlet-Kontexte ermöglicht. Obwohl sowohl die EJB 1.1-Spezifikation als auch die Tomcat-Servlet-Engine in der Java-Welt ziemlich neu sind, kann man an deren Verwendung von XML für die Konfiguration der KernFunktionalität doch sehen, daß Sun beabsichtigt, XML auch weiterhin für solche Zwecke zu verwenden. In dem Maße, in dem XML-Parser immer einfacher verfügbar werden und vermarktbar sind, werden XML-basierte Konfigurationsdateien bei allen Server-Herstellern und Typen einschließlich nicht-Java-basierten Servern wie HTTP- und Datenbank-Servern verwendet werden. XML-Unterstützung In der zweiten Hälfte des Jahres 1999 nahm die Unterstützung von XML auf breiter Front zu, insbesondere im Java-Bereich. XML-Parser, XSLT-Prozessoren, Publishing Frameworks, XMLhttp://www.oreilly.de/artikel/xml_einf.html (17 of 20) [6/10/2002 2:14:00 PM] Java and XSLT Editoren und IDEs und eine Vielzahl verwandter Werkzeuge stehen jetzt zur Verfügung und werden sogar allmählich stabil und schnell. Obwohl das Thema dieses Buches die Java-APIs für die direkte Manupulation von XML sind, sind die Parser, Prozessoren und anderen Komponenten natürlich auf jeden Fall ein Bestandteil des gesamten XML-Prozesses, weswegen wir hier eine Reihe verfügbarer Komponenten auflisten. Weil sich die XML-Technologie so schnell verändert und die Hersteller immer mehr Zeit und Energie auf diesen Bereich verwenden, geben wir hier keine Versionsnummern an. Parser Eine der wichtigsten Schichten in einer XML-fähigen Applikation ist der XML-Parser. Diese Komponente hat die äußerst wichtige Aufgabe, das rohe XML-Dokument als Eingabe zu verarbeiten und irgend etwas Nützliches daraus zu machen; sie stellt sicher, daß das Dokument wohlgeformt ist, und wenn eine DTD oder ein Schema referenziert wird, kann sie möglicherweise auch überprüfen, ob das Dokument gültig ist. Das Ergebnis des Parsens eines XML-Dokuments ist typischerweise eine Datenstruktur, in unserem Fall eine Java-basierte, die einfach von anderen XML-Werkzeugen oder Java-APIs manipuliert und bearbeitet werden kann. Wir werden hier nicht detailliert auf diese Datenstrukturen eingehen. Es sei erst einmal nur festgestellt, daß der Parser eine der zentralen Komponenten bei der Verwendung von XMLDaten ist. Das Auswählen eines XML-Parsers ist keine einfache Aufgabe. Es gibt keine festen Regeln, aber üblicherweise wendet man zwei Kriterien an. Das erste ist die Geschwindigkeit des Parsers. Wenn XML-Dokumente immer öfter verwendet werden und immer größer werden, dann bekommt die Geschwindigkeit des XML-Parsers einen extrem großen Einfluß auf die GesamtPerformance der Applikation. Der zweite Faktor ist die Konformität zur XML-Spezifikation. Weil die Performance oft wichtiger ist als manche obskuren XML-Features, beachten manche Parser möglicherweise einige der speziellen Punkte der XML-Spezifikation nicht, um eine höhere Geschwindigkeit zu erzielen. Sie müssen selbst wissen, was Ihnen wichtiger ist, und eine angemessene Balance zwischen diesen beiden Punkten finden. Außerdem validieren manche XML-Parser, was bedeutet, daß sie optional Ihren XML-Code anhand einer DTD überprüfen, während andere das nicht tun. Stellen Sie sicher, daß Sie einen validierenden Parser verwenden, wenn Sie diese Eigenschaft in Ihren Applikationen benötigen. Hier folgt eine Liste der am häufigsten verwendeten XML-Parser. Aus dieser Liste geht nicht hervor, welche dieser Parser validieren und welche nicht, weil die Fähigkeit zur Validierung derzeit zu einer Reihe von Parsern hinzugefügt wird, die das noch nicht können. Die Liste enthält keine Bewertung, auch keine implizite, aber auf den einzelnen Web-Seiten zu den Parsern finden Sie sehr viele Informationen: ● ● ● ● ● ● ● ● Apache Xerces: http://xml.apache.org IBMs XML Parser for Java: http://alphaworks.ibm.com/tech/xml4j James Clarks XP: http://www.jclark.com/xml/xp Oracle XML Parser: http://technet.oracle.com/tech/xml Sun Microsystems Crimson: http://xml.apache.org/crimson Tim Brays Lark und Larval: http://www.textuality.com/Lark The Mind Electric's Electric XML: http://www.themindelectric.com/products/xml/xml.html Microsofts Parser MXSML: http://msdn.microsoft.com/xml/default.asp ACHTUNG: Ich habe Microsofts Parser MXSML in diese Liste aufgenommen in Anerkennung ihrer Bemühungen um Einhaltung der Standarts bei den neueren Versionen. Trotzdem tendiert der Parser immer noch dazu, "sein eigenes Ding zu machen". Verwenden Sie ihn, wenn sie ihn brauchen, aber seien Sie sich bewußt, daß diese Entscheidung zu zusätzlicher Arbeit führt. http://www.oreilly.de/artikel/xml_einf.html (18 of 20) [6/10/2002 2:14:00 PM] Java and XSLT Prozessoren Nachdem ein XML-Dokument geparst worden ist, wird es fast immer umgeformt. Diese Umformung geschieht, wie wir bereits besprochen haben, mittels XSLT. Ähnlich wie beim Parsen gibt es auch bei dieser Komponente des XML-Prozesses eine Reihe von Optionen. Auch hier sind die beiden Hauptkriterien wieder die Geschwindigkeit der Umformung und die Konformität mit den XSL- und XSLT-Spezifikationen. Die Web-Seiten zu den einzelnen Prozessoren liefern die besten Informationen hinsichtlich Konformität und PerformanceBenchmarks. ● ● ● ● ● Apache Xalan: http://xml.apache.org James Clarks XT: http://www.jclark.com/xml/xp/index.html Lotus XSL Processor: http://www.alphaworks.ibm.com/tech/LotusXSL Oracle XSL Processor: http://technet.oracle.com/tech/xml Michael Kays SAXON: http://saxon.sourceforge.net Publishing Frameworks XML-Publishing Framework ist ein etwas nebulöser Begriff und auf jeden Fall keine formale Definition. Für dieses Buch sei ein Publishing Framework für XML eine Sammlung von XMLWerkzeugen, die das Parsen, Umformen und möglicherweise weitere Optionen zur Verwendung von XML in Applikationen ermöglichen. Obwohl das Parsen und Umformen üblicherweise durch eines der bereits erwähnten Werkzeuge geschieht, bindet ein Publishing Framework diese Werkzeuge mittels Java-APIs zusammen und stellt so ein standardisiertes Interface für die Verwendung des Frameworks zur Verfügung. Fortgeschrittenere Frameworks erlauben sowohl das Verarbeiten von statischen XML-Dokumenten als auch von Java-Applikationen generiertem XML-Code, und manche enthalten sogar XML-Editoren und Komponenten-Editoren, um sicherzustellen, daß der erzeugte XML-Code den Beschränkungen des Frameworks gehorcht. Weil es keine Spezifikation gibt, wie sich eine XML-Applikation oder ein Framework verhalten sollte, gibt es gewaltige Unterschiede zwischen den hier genannten Frameworks. Jedes hat aber Vorteile, die es rechtfertigen, daß Sie ein wenig Zeit damit zubringen, die einzelnen Frameworks zu untersuchen und zu verwenden. Außerdem sind manche dieser Frameworks Open-SourceSoftware (OSS) und damit nicht nur leicht erhältlich, sondern auch offen in der Hinsicht, daß Sie genau sehen können, wie die Ergebnisse erreicht werden. ● ● ● ● Apache Cocoon: http://xml.apache.org Enhydra Application Server: http://www.enhydra.org Bluestone XML Server: http://www.bluestone.com/xml SAXON: http://saxon.sourceforge.net XML-Editoren und IDEs Es gibt viele gute XML-Parser und -Prozessoren, aber lange Zeit konnte man das gleiche nicht über XML-Editoren sagen. Viele Entwicklern verwenden Texteditoren wie vi, Emacs oder Notepad, inzwischen gibt es aber auch eine Reihe von speziellen XML-Editoren. Sie finden unter http://www.xmlsoftware.com eine exzellente, kommentierte Liste von XML- Editoren, mit der Sie sich über die neueste Software informieren können. O'Reilly Home | O'Reilly-Partnerbuchhandlungen | Bestellinformationen Kontakt | Über O'Reilly | Datenschutz http://www.oreilly.de/artikel/xml_einf.html (19 of 20) [6/10/2002 2:14:00 PM] Java and XSLT © 2001, O'Reilly Verlag http://www.oreilly.de/artikel/xml_einf.html (20 of 20) [6/10/2002 2:14:00 PM]
