Einleitung

Einleitungskapitel sind üblicherweise ziemlich leicht zu schreiben. In den meisten Büchern gibt man einen Überblick über die behandelte Technologie, erklärt einige Grundlagen und versucht, das Interesse des Lesers zu wecken. Allerdings ist es mit dieser zweiten Auflage von Java und XML nicht ganz so einfach. Zur Zeit der ersten Auflage gab es noch eine Menge Leute, für die XML neu war, oder Skeptiker, die sehen wollten, ob diese neue Art Auszeichnungssprache wirklich so gut war wie der Wirbel, der darum veranstaltet wurde. Ein gutes Jahr später verwenden alle XML auf zig Arten. In diesem Sinne brauchen Sie wahrscheinlich gar keine Einleitung. Aber ich gebe Ihnen einen Überblick über das, was hier behandelt wird, und sage Ihnen, warum es eine Rolle spielt und was Sie benötigen, um es ans Laufen zu bekommen.

XML spielt eine wichtige Rolle

Lassen Sie mich als erstes einfach sagen, daß XML eine bedeutende Rolle spielt. Ich weiß, das klingt wie der Beginn eines Selbsthilfeseminars, aber es hat einen Sinn, damit anzufangen. Es gibt noch immer eine Menge von Entwicklern, Managern und Vorgesetzten, die Angst vor XML haben. Sie haben Angst vor der Feststellung, daß XML der Nabel der Welt ist, und auch vor dem schnellen Wandel, dem XML unterworfen ist. (Das hier ist schon die zweite Auflage, nur ein Jahr später, oder? Hat sich so vieles geändert?) Sie haben Angst vor den Kosten, die das Anheuern von Leuten wie Ihnen und mir verursacht, um mit XML zu arbeiten. Und vor allem haben sie Angst davor, noch ein weiteres Steinchen zu ihrem Anwendungspuzzle hinzuzufügen.

Um zu versuchen, diese Ängste ein wenig abzubauen, möchte ich schnell die Hauptgründe dafür aufzählen, warum Sie noch heute anfangen sollten, mit XML zu arbeiten. Erstens ist XML portierbar. Zweitens ermöglicht es einen noch nie dagewesenen Grad der Zusammenwirkung. Und drittens spielt XML eine wichtige Rolle... weil es keine Rolle spielt! Wenn Sie das völlig verwirrt, dann lesen Sie weiter, denn schon bald wird es einen Sinn ergeben.

XML ist portierbar. Wenn Sie schon länger mit Java zu tun haben oder sogar schon einmal während der JavaOne-Konferenz durch das Moscone Center gewandert sind, dann haben Sie das Java-Mantra gehört: »portierbarer Code«. Kompilieren Sie Java-Code, installieren Sie die .class- oder .jar-Dateien unter einem beliebigen Betriebssystem, und der Code läuft. Alles, was Sie brauchen, ist ein Java Runtime Environment (JRE) oder eine Java Virtual Machine (JVM), und das war’s. Dies ist schon immer einer der größten Vorteile von Java gewesen, weil Entwickler so auf Windows- oder Linux-Workstations arbeiten können und ihr Code dann auf Sparc-Rechnern, E4000-Systemen, HP-UX oder irgend etwas anderem einsetzbar ist.

Im Ergebnis verdient XML mehr als nur einen flüchtigen Blick. Da XML einfach nur Text ist, kann es logischerweise zwischen verschiedenen Plattformen hin- und herbewegt werden. Was noch wichtiger ist: XML muß einer Spezifikation genügen, die vom World Wide Web-Konsortium (W3C) unter http://www.w3.org definiert wurde. Das bedeutet, daß XML einen Standard darstellt. Wenn Sie XML losschicken, genügt es diesem Standard; wenn eine andere Anwendung es empfängt, genügt das XML noch immer diesem Standard. Die Empfängeranwendung kann sich darauf verlassen.

Das ist im wesentlichen das, was auch Java bietet: Jede JVM weiß, was sie zu erwarten hat, und solange der Code diesen Erwartungen genügt, wird er laufen. Durch die Verwendung von XML erhalten Sie portierbare Daten. Sie könnten sogar in letzter Zeit in bezug auf die Kombination von Java und XML den Satz »portierbarer Code, portierbare Daten« gehört haben. Das ist gut ausgedrückt, weil es sich (anders als die meisten Werbesprüche) bewahrheitet.

Zweitens erlaubt XML eine erheblich bessere Interoperabilität (Zusammenwirkung) als alles, was wir je bei Enterprise-Anwendungen gesehen haben. Einige von Ihnen denken vielleicht, daß dies bloß eine weitere Art der Portierbarkeit ist, aber es ist mehr als das. Denken Sie daran, daß XML für Extensible Markup Language (etwa: erweiterbare Auszeichnungssprache) steht. Und genau diese Erweiterbarkeit ist besonders wichtig für das Zusammenwirken von professionellen Anwendungen. Betrachten Sie zum Beispiel einmal HTML, die Hypertext Markup Language. HTML ist ein Standard. Es ist einfach nur Text. Also ist es in dieser Hinsicht genauso portierbar wie XML.

In der Tat können alle Benutzer unterschiedlicher Browser unter verschiedenen Betriebssystemen HTML mehr oder weniger identisch betrachten. Allerdings ist HTML speziell auf Präsentation ausgerichtet. Sie könnten HTML nicht benutzen, um ein Möbelverzeichnis oder ein Rechnungsformular darzustellen. Das liegt daran, daß der Standard sehr enge Grenzen bezüglich erlaubter Tags, Formate und allem anderen in HTML setzt. Dies ermöglicht es HTML, auf Präsentation spezialisiert zu bleiben, was sowohl ein Vorteil als auch ein Nachteil ist.

Im Gegensatz dazu macht XML nur wenige Vorgaben über die Elemente und Inhalte eines Dokuments. Statt dessen konzentriert es sich auf die Struktur eines Dokuments; die Elemente müssen einen Anfang und ein Ende haben, jedes Attribut benötigt genau einen Wert, und so weiter. Der Inhalt des Dokuments und die Elemente und Attribute, die verwendet werden, sind Ihre Sache. Sie können Ihre eigenen Dokumentformate, Inhalte und angepaßten Spezifikationen für die Darstellung Ihrer Daten entwickeln. Und das ermöglicht Zusammenwirkung.

Die verschiedenen Möbelhausketten könnten sich auf einen bestimmten Satz von Richtlinien für XML einigen und dann Daten in diesen Formaten austauschen; sie könnten alle Vorteile von XML nutzen (wie etwa die Portierbarkeit) und zusätzlich die Fähigkeit gewinnen, ihr berufliches Wissen auf die ausgetauschten Daten anzuwenden, um ihnen Bedeutung zu verleihen. Ein Rechnungsstellungssystem könnte ein angepaßtes Format für Rechnungsformulare beinhalten, es könnte dieses Format verbreiten, und es könnte Rechnugen aus anderen Rechnungsstellungssystemen importieren oder in deren Formate exportieren. Die Erweiterbarkeit von XML macht es für plattformübergreifendes Arbeiten perfekt geeignet.

Sogar noch faszinierender ist die Vielzahl vertikaler Standards1, die entwickelt werden. Sehen Sie sich etwa das ebXML-Projekt unter http://www.ebxml.org an, wenn Sie wissen möchten, was machbar ist. Hier arbeiten Unternehmen zusammen, um Standards zu entwickeln, die auf XML aufbauen und globalen elektronischen Handel ermöglichen. Die Telekommunikationsindustrie hat ähnliche Anstrengungen unternommen. Bald werden sich vertikale Märkte überall auf der Welt auf Standards für den Datenaustausch geeinigt haben, die alle auf XML basieren.

XML ist wichtig, weil es zu einem verläßlichlichen, in sich selbst aber unwichtigen Teil Ihrer Anwendung wird. Beschreiben Sie Ihre Anforderungen, codieren Sie Ihre Daten in XML – und vergessen Sie es. Dann können Sie mit den wichtigen Dingen weitermachen; der komplexen Branchenlogik und ihrer Darstellung, die Wochen und Monate des Nachdenkens und der harten Arbeit benötigt. Währenddessen wird XML Ihre Daten fröhlich vor sich hin darstellen, ohne mit der Wimper zu zucken (zugegeben, jetzt werde ich ein bißchen dramatisch, aber Sie verstehen, was ich meine).

Wenn Sie also bisher Angst vor XML hatten oder skeptisch waren, sollten Sie jetzt an Bord kommen. Es könnte die wichtigste Entscheidung sein, die Sie je getroffen haben, und noch dazu mit den wenigsten unerwünschten Nebenwirkungen. Der Rest dieses Buches hilft Ihnen, APIs, Transportprotokolle und allerlei weiteren Kram einwandfrei ans Laufen zu bringen.

Was ist wichtig?

Nachdem Sie erkannt haben, daß XML Ihnen weiterhelfen kann, ist die nächste Frage, welchen Teil davon Sie benötigen. Wie bereits erwähnt, gibt es buchstäblich Hunderte von XML-Anwendungen, und die richtige zu finden ist keine leichte Aufgabe. Ich muß aus diesen Hunderten zwölf oder dreizehn Schlüsselthemen herausgreifen und es schaffen, Sie Ihnen alle schmackhaft zu machen; auch keine leichte Aufgabe! Glücklicherweise hatte ich nun ein Jahr Zeit, um Feedback zur ersten Auflage dieses Buches zu sammeln, und ich arbeite bereits seit weit über zwei Jahren mit XML in praktischen Anwendungen. Das bedeutet, daß ich zumindest eine Grundidee davon habe, was interessant und wichtig ist. Wenn man einmal die gesamte XML-Landschaft zusammenfaßt, läuft alles auf einige wenige Kategorien hinaus.

Eine API ist eine Schnittstelle für die Anwendungsprogrammierung (Application Programming Interface). Eine Low-Level-API ermöglicht Ihnen den unmittelbaren Umgang mit dem Inhalt eines XML-Dokuments. Mit anderen Worten: Es findet wenig bis gar keine Vorverarbeitung (engl. preprocessing) statt, und Sie erhalten XML-Inhalt im Rohzustand, mit dem Sie arbeiten können. Dies ist die effizienteste Art, mit XML zu arbeiten, und auch die wirkungsvollste. Gleichzeitig erfordert sie das meiste Wissen über XML und die meiste Arbeit, um aus einem Dokumenteninhalt etwas Sinnvolles zu machen.

Die beiden gebräuchlichsten Low-Level-APIs sind derzeit SAX, die Simple API for XML, und DOM, das Document Object Model. Zusätzlich hat JDOM (was weder ein Akronym noch eine Erweiterung von DOM ist) in letzter Zeit eine Menge Aufmerksamkeit erregt. Alle drei sind auf eine bestimmte Art standardisiert (SAX als De-facto-Standard, DOM als W3C-Standard und JDOM von Sun), und es ist wahrscheinlich, daß sie recht langlebige Technologien sein werden. Alle drei bieten Ihnen in unterschiedlicher Form Zugriff auf ein XML-Dokument, und Sie können mit ihrer Hilfe so ziemlich alles mit dem Dokument anstellen. Ich werde eine ganz schön lange Zeit mit der Behandlung dieser APIs verbringen, weil sie die Basis für alles andere darstellen, was Sie mit XML tun können. Ich habe ein weiteres Kapitel JAXP gewidmet, Suns Java-API für die XML-Bearbeitung, die eine dünne Abstraktionsschicht oberhalb von SAX und DOM zur Verfügung stellt.

High-Level-APIs sind die nächste Stufe auf der Leiter. Anstatt den direkten Zugriff auf ein Dokument zu bieten, verlassen sie sich auf Low-Level-APIs, die diese Aufgabe für sie erledigen. Zusätzlich stellen diese APIs das Dokument anders dar, entweder benutzerfreundlicher oder auf eine bestimmte Weise aufbereitet oder in einer anderen Form als der zugrundeliegenden XML-Dokumentstruktur. Während diese APIs oftmals einfacher zu verwenden sind und die Entwicklung beschleunigen, könnten sie Sie zusätzliche Rechenzeit für die Konvertierung Ihrer Daten in ein anderes Format kosten. Außerdem werden Sie eine gewisse Zeit benötigen, die API zu erlernen, wahrscheinlich zusätzlich zu einigen Low-Level-APIs.

In diesem Buch ist das Hauptbeispiel einer High-Level-API die XML-Datenbindung. Eine Datenbindung ermöglicht es, ein XML-Dokument zu übernehmen und als Java-Objekt zur Verfügung zu stellen. Kein Baum-basiertes Objekt wohlgemerkt, sondern ein selbstdefiniertes Java-Objekt. Wenn Sie etwa Elemente namens »person« und »vorname« hätten, dann ergäbe sich ein Objekt mit Methoden wie getPerson() und setVorname(). Dies ist offenbar eine einfache Art, schnell mit XML loszulegen; es ist kaum irgendwelches tiefergehende Wissen erforderlich! Allerdings können Sie nicht einfach die Struktur des Dokuments ändern (etwa, indem Sie aus dem Element »person« das Element »angestellter« machen), deshalb ist die Datenbindung nur für manche Anwendungen angebracht. Im Kapitel Content-Syndication können Sie alles über Datenbindung erfahren.

Zusätzlich zu den APIs, die speziell für die Arbeit mit einem Dokument oder seinem Inhalt entwickelt wurden, gibt es eine Reihe von Anwendungen, die auf XML aufbauen. Diese Anwendungen verwenden direkt oder indirekt XML, konzentrieren sich aber auf eine bestimmte Aufgabe wie z.B. die Darstellung stilisierter Webinhalte oder die Kommunikation zwischen Anwendungen. All das sind Beispiele für XML-basierte Anwendungen, die XML als Teil ihrer eigentlichen Funktion verwenden. Einige erfordern gründliche XML-Kenntnisse, andere benötigen keine; aber alle gehören in die Besprechung von Java und XML. Ich habe die häufigsten und nützlichsten herausgesucht, die dann hier besprochen werden.

Als erstes werde ich Web-Publishing-Frameworks behandeln, die verwendet werden, um XML aufzunehmen und es als HTML, WML (Wireless Markup Language) oder in binären Formaten wie Adobe PDF (Portable Document Format) zu formatieren. Diese Frameworks werden üblicherweise verwendet, um komplexe, in hohem Maße angepaßte Web-Anwendungen an Clients auszuliefern. Als nächstes betrachte ich XML-RPC, das eine XML-Variante der Remote Procedure Calls bietet. Es ist das erste in der Erläuterung einer ganzen Reihe von Werkzeugen für die Kommunikation zwischen Anwendungen.

Ich werde das auf XML-RPC aufbauende SOAP beschreiben, das Simple Object Access Protocol, und zeigen wie es über das hinausgeht, was XML-RPC zu bieten hat. Anschließend werden Sie in einem Business-to-Business-Kapitel die Neuentwicklungen im Bereich der Webdienste zu sehen bekommen, indem wir UDDI (Universal Discovery, Description and Integration) und WSDL (Web Services Descriptor Language) untersuchen. Wenn Sie all diese Werkzeuge in Ihre Werkzeugkiste stecken, dann werden Sie nicht nur hervorragend für XML gerüstet sein, sondern für jede Enterprise-Anwendungsumgebung.

Und am Schluß werde ich im Kapitel Ausblick in meine Kristallkugel schauen und darauf hinweisen, was sich in den kommenden Monaten und Jahren durchsetzen könnte, und ich werde versuchen, Ihre Aufmerksamkeit auf Dinge zu lenken, die Sie im Auge behalten sollten. Dies sollte Sie an der Spitze des Feldes halten, wo alle guten Entwickler sein sollten.

Was Sie benötigen

Nun sind Sie bereit zu lernen, wie Sie Java und XML am besten verwenden können. Was brauchen Sie? Ich werde dieses Thema anreißen, Ihnen einige Hinweise geben und Sie dann den Rest selbst erledigen lassen.

Ich sage das fast mit ein wenig Ironie; wenn Sie erwarten, ohne Betriebssystem und ohne Java-Installation dieses Buch zu überstehen, dann könnte es ein wenig zu hoch für Sie sein. Dennoch ist es gut, wenn Sie wissen, was ich erwarte. Ich habe die erste Hälfte dieses Buches und die Beispiele für diese Kapitel auf einem Windows 2000-Rechner geschrieben, auf dem die JDK-Versionen 1.2 und 1.3 (sowie 1.3.1) liefen. Ich habe meistens unter Cygwin (von Cygnus) kompiliert, so daß ich meist in einem Unix-artigen Umfeld arbeite. Die zweite Hälfte dieses Buches wurde auf meinem (seinerzeit) neuen Macintosh G4 unter MacOS X geschrieben. Dieses System wird mit JDK 1.3 geliefert und ist ein Juwel, falls Sie neugierig sein sollten.

In jedem Fall sollten alle Beispiele ohne Änderungen mit Java 1.2 oder höher laufen; ich habe keine Features des JDK 1.3 verwendet. Allerdings habe ich diesen Code nicht so geschrieben, daß er sich unter Java 1.1 kompilieren läßt, weil ich der Meinung war, daß die Verwendung der Java 2-Collection-Klassen wichtig sei. Außerdem werden Sie für die Arbeit mit XML sehr intensiv über ein Update Ihres JDK nachdenken müssen, wenn Sie noch 1.1 verwenden (ich weiß, daß einige von Ihnen keine Wahl haben). Wenn Sie auf eine 1.1-JVM angewiesen sind, dann können Sie die Collection-Klassen von Sun erhalten (http://java.sun.com), einige kleinere Anpassungen vornehmen und sind wieder auf dem laufenden.

Sie benötigen einen XML-Parser. Einer der wichtigsten Bestandteile jeder Anwendung, die mit XML zu tun hat, ist der XML-Parser. Diese Komponente erledigt die wichtige Aufgabe, aus einem eingegebenen XML-Dokument im Rohzustand etwas Sinnvolles zu machen; der Parser stellt sicher, daß das Dokument wohlgeformt ist, und wenn auf eine DTD oder ein Schema zugegriffen wird, kann er sicherstellen, daß das Dokument gültig ist. Das Ergebnis eines vom Parser bearbeiteten Dokuments ist üblicherweise eine Datenstruktur, die durch andere XML-Werkzeuge oder durch Java-APIs manipuliert und bearbeitet werden kann. Ich hebe mir die detaillierte Diskussion dieser APIs für spätere Kapitel auf. Seien Sie sich im Moment einfach der Tatsache bewußt, daß der Parser einer der Kernbestandteile der Verwendung von XML-Daten ist.

Die Auswahl eines XML-Parsers ist keine leichte Aufgabe. Es gibt keine festgelegten, schnellen Regeln, aber zwei Hauptkriterien werden normalerweise zugrundegelegt. Das erste ist die Geschwindigkeit des Parsers. Wenn XML-Dokumente häufiger verwendet werden und ihre Komplexität zunimmt, wird die Geschwindigkeit des XML-Parsers für die Gesamtperformance einer Anwendung extrem wichtig. Der zweite Faktor ist der Grad der Übereinstimmung mit der XML-Spezifikation.

Da Performance oft eine höhere Priorität hat als einige verborgene Features von XML, kann es sein, daß manche Parser in einigen Feinheiten nicht der XML-Spezifikation entsprechen, um zusätzliche Geschwindigkeit herauszukitzeln. Sie müssen sich je nach den Bedürfnissen Ihrer Anwendung für eine passende Balance zwischen diesen Faktoren entscheiden. Zusätzlich können die meisten XML-Parser Validierungen durchführen, aber manche nicht. Die Validierung bietet Ihnen die Möglichkeit, die Übereinstimmung Ihres XML-Codes mit einer DTD oder einem XML Schema zu überprüfen. Stellen Sie sicher, daß Sie einen Parser mit Validierung verwenden, wenn diese Fähigkeit in Ihren Anwendungen benötigt wird.

Hier sehen Sie eine Liste der am häufigsten verwendeten XML-Parser. Die Liste gibt nicht an, ob ein Parser eine Validierung durchführt oder nicht, weil zur Zeit Bemühungen stattfinden, um diejenigen Parser, die noch keine besitzen, mit eben dieser Fähigkeit auszustatten. Hier wird keine Rangfolge vorgegeben, aber es gibt es eine Menge Informationen auf den Webseiten zu jedem Parser:

• Apache Xerces: http://xml.apache.org
• IBM XML4J: http://alphaworks.ibm.com/tech/xml4j
• XP von James Clark: http://www.jclark.com/xml/xp
• Oracle XML Parser: http://technet.oracle.com/tech/xml
• Crimson von Sun Microsystems: http://xml.apache.org/crimson
• Lark and Larval von Tim Bray: http://www.textuality.com/Lark
• Electric XML von The Mind Electric: http://www.themindelectric.com/products/xml/xml.html
• Der MXSML-Parser von Microsoft: https://msdn.microsoft.com/en-us/library/ms763742.aspx

Das ganze Buch hindurch tendiere ich dazu, Apache Xerces zu verwenden, weil es Open Source ist. Dies ist für mich ein großer Pluspunkt, deshalb würde ich Ihnen empfehlen, Xerces auszuprobieren, wenn Sie noch keinen Parser ausgewählt haben.

Wenn Sie erst den Parser-Anteil des Problems gelöst haben, benötigen Sie die verschiedenen (Low-Level- und High-Level-) APIs, über die ich noch sprechen werde. Manche davon werden bei Ihrem Parser-Download dabei sein, wärend andere zu Fuß heruntergeladen werden müssen. Ich erwarte, daß Sie diese APIs entweder zur Hand haben, oder daß Sie in der Lage sind, sie von einer Website im Internet zu erhalten. Also stellen Sie sicher, daß Sie Zugang zum Web haben, bevor Sie zu tief in irgendein Kapitel einsteigen.

Zuerst die Low-Level-APIs: Wir verwenden SAX, DOM, JDOM und JAXP. SAX und DOM sollten bei jedem Parser enthalten sein, den Sie herunterladen, denn diese APIs sind Interface-basiert und werden innerhalb des Parsers implementiert. Mit den meisten Parsern erhalten Sie auch JAXP, obwohl Sie so an eine ältere Version geraten könnten; hoffentlich unterstützen die meisten Parser beim Erscheinen dieses Buches voll JAXP 1.1 (die neueste öffentliche Version). JDOM ist momentan als separates Paket zum Download verfügbar, und Sie können es von der Website http://www.jdom.org herunterladen.

Was die High-Level-APIs angeht, behandle ich eine Reihe von Alternativen in dem Kapitel über Datenbindung. Ich werde einen kurzen Überblick über Castor und Quick geben, die online unter http://castor.codehaus.org bzw. http://sourceforge.net/projects/jxquick verfügbar sind. Ich nehme mir auch ein wenig Zeit, um Zeus zu behandeln, das unter http://zeus.enhydra.org heruntergeladen werden kann. All diese Pakete enthalten alle notwendigen Abhängigkeiten innerhalb der Download-Archive.

Der letzte Punkt in dieser Liste sind die Myriaden von spezifischen Technologien, über die ich in den folgenden Kapiteln sprechen werde. Zu diesen Technologien gehören solche Dinge wie SOAP-Toolkits, WSDL-Validatoren, das Cocoon Web-Publishing-Framework und so weiter. Anstatt hier jedes einzelne zu behandeln, werde ich die spezielleren Anwendungen in den passenden Kapiteln ansprechen, etwa woher Sie die Pakete erhalten können und welche Versionen benötigt werden. Daneben erhalten Sie Installationshinweise und alles andere, das Sie wissen müssen, um die Pakete zum Laufen zu bekommen. Ich kann Ihnen hier all die gräßlichen Details ersparen und nur die unter Ihnen langweilen, die sich langweilen lassen (nur ein Witz! Ich werde versuchen, unterhaltsam zu bleiben). In jedem Fall können Sie mir folgen und alles lernen, was Sie wissen sollten.

In manchen Fällen baue ich auf Beispiele aus früheren Kapiteln auf. Wenn Sie zum Beispiel anfangen, das Kapitel DOM für Fortgeschrittene zu lesen, bevor Sie das Kapitel DOM durchgehen, werden Sie sich wahrscheinlich etwas verloren vorkommen. Wenn das passiert, gehen Sie einfach ein Kapitel zurück und schauen Sie, woher der unverständliche Code stammt. Wie ich bereits erwähnte, können Sie das Kapitel Einstieg in XML über die XML-Grundlagen schnell überfliegen, aber ich empfehle Ihnen, den Rest des Buches in der richtigen Reihenfolge durchzuarbeiten, da ich versuche, die Konzepte und das Wissen logisch aufzubauen.

Und was kommt jetzt?

Jetzt sind Sie wahrscheinlich bereit loszulegen. Im Kapitel Einstieg in XML gebe ich Ihnen einen Crashkurs in XML. Wenn XML für Sie neu ist oder wenn Sie unsicher bezüglich der Grundlagen sind, schließt dieses Kapitel die Lücken. Wenn Sie ein alter Hase in Sachen XML sind, empfehle ich Ihnen, das Kapitel kurz zu überfliegen, und dann gleich mit dem Code im Kapitel SAX fortzufahren. In jedem Fall können Sie sich bereit machen, in Java und XML einzutauchen, ab jetzt wird es spannend.

1)

Ein vertikaler Standard oder auch vertikaler Markt bezeichnet einen Standard oder einen Markt einer bestimmten Branche. Statt horizontaler Bewegung (bei der gleiche Funktionalität verlangt wird) besteht der Schwerpunkt hier in der vertikalen Bewegung, also in der Bereitstellung von Funktionalität für eine bestimmte Zielgruppe wie Schuhfabrikanten oder Gitarrenbauer.

• << zurück
• vor >>